一、MaxCompute湖倉一體發(fā)展進(jìn)程

MaxCompute作為阿里云自研的海量大數(shù)據(jù)處理平臺(tái)已經(jīng)有十幾年的發(fā)展歷史，在規(guī)模和擴(kuò)展性方面一直表現(xiàn)比較優(yōu)秀。其依托阿里云飛天分布式操作系統(tǒng)，能夠提供快速，完全托管的EB級(jí)數(shù)據(jù)倉庫及數(shù)據(jù)湖解決方案，可經(jīng)濟(jì)高效的處理海量數(shù)據(jù)。目前，其承擔(dān)著阿里集團(tuán)絕大部分離線數(shù)據(jù)存儲(chǔ)和計(jì)算力，是阿里云產(chǎn)品矩陣中最重要的自研核心平臺(tái)之一。

MaxCompute發(fā)展之初，主要聚焦數(shù)倉方面的大數(shù)據(jù)處理業(yè)務(wù)場景，并且處理的數(shù)據(jù)源主要為格式化數(shù)據(jù)。隨著數(shù)據(jù)處理場景的多樣化和業(yè)界數(shù)據(jù)湖架構(gòu)的興起，加上阿里集團(tuán)內(nèi)部本身數(shù)據(jù)也非常多，支持多樣化數(shù)據(jù)源也就成為了一個(gè)必選項(xiàng)。因此MaxCompute設(shè)計(jì)了完善的外表機(jī)制，可以讀取存儲(chǔ)在外部的多種格式的數(shù)據(jù)對象，例如Hadoop開源體系，OSS半結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)，為此也盡可能設(shè)計(jì)開發(fā)統(tǒng)一的元數(shù)據(jù)處理架構(gòu)，此階段MaxCompute在湖倉一體化解決方案中邁出了重要一步，極大的擴(kuò)展了數(shù)據(jù)處理的業(yè)務(wù)場景，有效的打破數(shù)據(jù)孤島，聯(lián)動(dòng)各方面的數(shù)據(jù)進(jìn)行綜合分析來挖掘整體數(shù)據(jù)價(jià)值。但時(shí)效性不足，通常是T+1離線場景。

隨著用戶數(shù)和數(shù)據(jù)規(guī)模不斷增加，很多業(yè)務(wù)場景也越加復(fù)雜，需要更加完善綜合的整體解決方案。其中的關(guān)鍵環(huán)節(jié)之一就是數(shù)據(jù)需要更加高效的流轉(zhuǎn)起來，為此MaxCompute進(jìn)一步設(shè)計(jì)完善開放存儲(chǔ)和計(jì)算架構(gòu)，更好的去融合生態(tài)，讓數(shù)據(jù)可流暢的進(jìn)得來也出得去。此外，還有一個(gè)重要的業(yè)務(wù)場景是大規(guī)模批量處理和高時(shí)效高效率增量處理一體化解決方案，為簡化用戶數(shù)據(jù)處理鏈路，節(jié)省不同系統(tǒng)之間的數(shù)據(jù)遷移成本以及冗余計(jì)算和存儲(chǔ)成本，我們設(shè)計(jì)開發(fā)了MaxCompute離線和近實(shí)時(shí)增量處理的一體化架構(gòu)?？傮w來說，現(xiàn)階段以及未來會(huì)基于統(tǒng)一的存儲(chǔ)、統(tǒng)一的元數(shù)據(jù)、統(tǒng)一的計(jì)算引擎有效支撐湖倉一體的整體技術(shù)架構(gòu)，讓數(shù)據(jù)能夠開放互通高效流轉(zhuǎn)，并且計(jì)算和存儲(chǔ)成本持續(xù)優(yōu)化。

二、MaxCompute近實(shí)時(shí)增量處理技術(shù)架構(gòu)簡介

1、MaxCompte離線 & 近實(shí)時(shí)增量處理業(yè)務(wù)系統(tǒng)架構(gòu)現(xiàn)狀

隨著當(dāng)前數(shù)據(jù)處理的業(yè)務(wù)場景日趨復(fù)雜，對于時(shí)效性要求低的大規(guī)模數(shù)據(jù)全量批處理的場景，直接使用MaxCompute足以很好的滿足業(yè)務(wù)需求，對于時(shí)效性要求很高的秒級(jí)實(shí)時(shí)數(shù)據(jù)處理或者流處理，則需要使用實(shí)時(shí)系統(tǒng)或流系統(tǒng)來滿足需求。

但其實(shí)對于大部份業(yè)務(wù)場景，并不要求秒級(jí)數(shù)據(jù)更新可見，更多的是分鐘級(jí)或者小時(shí)級(jí)的增量數(shù)據(jù)處理場景，并且疊加海量數(shù)據(jù)批處理場景。

對于這類業(yè)務(wù)場景的解決方案，如果使用單一的MaxCompute離線批量處理鏈路，為了計(jì)算的高效性，需要將用戶各種復(fù)雜的一些鏈路和處理邏輯轉(zhuǎn)化成T+1的批次處理，鏈路復(fù)雜度增加，也可能產(chǎn)生冗余的計(jì)算和存儲(chǔ)成本，且時(shí)效性也較差。但如果使用單一的實(shí)時(shí)系統(tǒng)，資源消耗的成本比較高，性價(jià)比也較低，并且大規(guī)模數(shù)據(jù)批處理的穩(wěn)定性也不足。因此當(dāng)前比較典型的解決方案是Lambda架構(gòu)，全量批處理使用MaxCompute鏈路，時(shí)效性要求比較高的增量處理使用實(shí)時(shí)系統(tǒng)鏈路，但該架構(gòu)也存在大家所熟知的一些固有缺陷，比如多套處理和存儲(chǔ)引擎引發(fā)的數(shù)據(jù)不一致問題，多份數(shù)據(jù)冗余存儲(chǔ)和計(jì)算引入的額外成本，架構(gòu)復(fù)雜以及開發(fā)周期長等。

針對這些問題近幾年大數(shù)據(jù)開源生態(tài)也推出了各種解決方案，最流行的就是Spark/Flink/Presto開源數(shù)據(jù)處理引擎，深度集成開源數(shù)據(jù)湖Hudi、Delta Lake和Iceberg三劍客，來綜合提供解決方案，解決Lamdba架構(gòu)帶來的一系列問題，而MaxCompute近一年自研開發(fā)的離線近實(shí)時(shí)增量處理一體化架構(gòu)，同樣是為了解決這些問題而設(shè)計(jì)，不僅僅具備分鐘級(jí)的增全量數(shù)據(jù)讀寫以及數(shù)據(jù)處理的業(yè)務(wù)需求，也能提供Upsert，Timetravel等一系列實(shí)用功能，可大幅擴(kuò)展業(yè)務(wù)場景，并且有效的節(jié)省數(shù)據(jù)計(jì)算，存儲(chǔ)和遷移成本，切實(shí)提高用戶體驗(yàn)。下文就將介紹該技術(shù)架構(gòu)的一些典型的功能和設(shè)計(jì)。

2、MaxCompute近實(shí)時(shí)增量處理技術(shù)架構(gòu)

MaxCompute近實(shí)時(shí)增量處理整體架構(gòu)的設(shè)計(jì)改動(dòng)主要集中在五個(gè)模塊：數(shù)據(jù)接入、計(jì)算引擎、數(shù)據(jù)優(yōu)化服務(wù)，元數(shù)據(jù)管理，數(shù)據(jù)文件組織。其他部份直接復(fù)用MaxCompute已有的架構(gòu)和計(jì)算流程，比如數(shù)據(jù)的分布式存儲(chǔ)直接集成了阿里云基礎(chǔ)設(shè)施盤古服務(wù)。

• 數(shù)據(jù)接入主要支持各種數(shù)據(jù)源全量和近實(shí)時(shí)增量導(dǎo)入功能。MaxCompute聯(lián)合相關(guān)產(chǎn)品定制開發(fā)多種數(shù)據(jù)接入工具，例如MaxCompute定制開發(fā)的Flink Connector，DataWorks的數(shù)據(jù)集成等，用來支持高效的近實(shí)時(shí)增量數(shù)據(jù)導(dǎo)入。這些工具會(huì)對接MaxCompute的數(shù)據(jù)通道服務(wù)Tunnel Server，主要支持高并發(fā)分鐘級(jí)增量數(shù)據(jù)寫入。此外，也支持MaxCompute SQL，以及其它一些接口用于支持全量數(shù)據(jù)高效寫入。
• 計(jì)算引擎主要包含MC自研的SQL引擎，負(fù)責(zé)Timetravel和增量場景下的SQL DDL/DML/DQL的語法解析,優(yōu)化和執(zhí)行鏈路。此外，MaxCompute內(nèi)部集成的Spark等引擎也在設(shè)計(jì)開發(fā)支持中。
• 數(shù)據(jù)優(yōu)化服務(wù)主要由MaxCompute的Storage Service來負(fù)責(zé)智能的自動(dòng)管理增量數(shù)據(jù)文件，其中包括小文件合并Clustering，數(shù)據(jù)Compaction，數(shù)據(jù)排序等優(yōu)化服務(wù)。對于其中部分操作，Storage Service會(huì)根據(jù)數(shù)據(jù)特征，時(shí)序等多個(gè)維度綜合評(píng)估，自動(dòng)執(zhí)行數(shù)據(jù)優(yōu)化任務(wù)，盡可能保持健康高效的數(shù)據(jù)存儲(chǔ)和計(jì)算狀態(tài)。
• 元數(shù)據(jù)管理主要負(fù)責(zé)增量場景下數(shù)據(jù)版本管理，Timetravel管理，事務(wù)并發(fā)沖突管理，元數(shù)據(jù)更新和優(yōu)化等。
• 數(shù)據(jù)文件組織主要包含對全量和增量數(shù)據(jù)文件格式的管理以及讀寫相關(guān)的模塊。

三、核心設(shè)計(jì)解剖

1、統(tǒng)一的數(shù)據(jù)文件組織格式

圖片

要支持全量和增量處理一體化架構(gòu)首先需要設(shè)計(jì)統(tǒng)一的表類型以及對應(yīng)的數(shù)據(jù)組織格式，這里稱為Transactional Table2.0，簡稱TT2，基本可以支持普通表的所有功能，同時(shí)支持增量處理鏈路的新場景，包括timetravel查詢、upsert操作等。

TT2要生效只需要在創(chuàng)建普通表時(shí)額外設(shè)置主鍵primary key(PK)，以及表屬性transactional為true即可。PK列用于支持Upsert鏈路功能，PK值相同的多行記錄在查詢或者Compaction會(huì)merge成一行數(shù)據(jù)，只保留最新狀態(tài)。transactional屬性則代表支持ACID事務(wù)機(jī)制，滿足讀寫快照隔離，并且每行數(shù)據(jù)會(huì)綁定事務(wù)屬性，比如事務(wù)timestamp，用來支持timetravel查詢，過濾出正確數(shù)據(jù)版本的記錄。此外TT2的tblproperties還可以設(shè)置其他的一些可選的表屬性，比如write.bucket.num用來配置數(shù)據(jù)寫入的并發(fā)度，acid.data.retain.hours用來配置歷史數(shù)據(jù)的有效查詢時(shí)間范圍等。

TT2表數(shù)據(jù)文件存在多種組織格式用來支持豐富的讀寫場景。其中base file數(shù)據(jù)文件不保留Update/Delete中間狀態(tài)，用來支撐全量批處理的讀寫效率，delta file增量數(shù)據(jù)文件會(huì)保存每行數(shù)據(jù)的中間狀態(tài)，用于滿足近實(shí)時(shí)增量讀寫需求。

為了進(jìn)一步優(yōu)化讀寫效率，TT2支持按照BucketIndex對數(shù)據(jù)進(jìn)行切分存儲(chǔ)，BucketIndex數(shù)據(jù)列默認(rèn)復(fù)用PK列，bucket數(shù)量可通過配置表屬性write.bucket.num指定，數(shù)據(jù)寫入的高并發(fā)可通過bucket數(shù)量水平擴(kuò)展，并且查詢時(shí)，如果過濾條件為PK列，也可有效的進(jìn)行Bucket裁剪查詢優(yōu)化。數(shù)據(jù)文件也可按照PK列進(jìn)行排序，可有效提升MergeSort的效率，并有助于DataSkipping查詢優(yōu)化。數(shù)據(jù)文件會(huì)按照列式壓縮存儲(chǔ)，可有效減少存儲(chǔ)的數(shù)據(jù)量，節(jié)省成本，也可有效的提升IO讀寫效率。

2、數(shù)據(jù)近實(shí)時(shí)流入

前面介紹了統(tǒng)一的數(shù)據(jù)組織格式，接下來需要考慮數(shù)據(jù)如何高效寫入TT2。

數(shù)據(jù)流入主要分成近實(shí)時(shí)增量寫入和批量寫入兩種場景。這里先描述如何設(shè)計(jì)高并發(fā)的近實(shí)時(shí)增量寫入場景。用戶的數(shù)據(jù)源豐富多樣，可能存在數(shù)據(jù)庫，日志系統(tǒng)或者其他消息隊(duì)列等系統(tǒng)中，為了方便用戶遷移數(shù)據(jù)寫入TT2， MaxCompute定制開發(fā)了Flink Connector、Dataworks數(shù)據(jù)集成以及其它開源工具，并且針對TT2表做了很多專門的設(shè)計(jì)開發(fā)優(yōu)化。這些工具內(nèi)部會(huì)集成MaxCompute數(shù)據(jù)通道服務(wù)Tunnel提供的客戶端SDK，支持分鐘級(jí)高并發(fā)寫入數(shù)據(jù)到Tunnel Server，由它高并發(fā)把數(shù)據(jù)寫入到每個(gè)Bucket的數(shù)據(jù)文件中。

寫入并發(fā)度可通過前面提及的表屬性write.bucket.num來配置，因此寫入速度可水平擴(kuò)展。對同一張表或分區(qū)的數(shù)據(jù)，寫入數(shù)據(jù)會(huì)按pk值對數(shù)據(jù)進(jìn)行切分，相同pk值會(huì)落在同一個(gè)bucket桶中。此外，數(shù)據(jù)分桶的好處還有利于數(shù)據(jù)優(yōu)化管理操作例如小文件clustering，compaction等都可以桶的粒度來并發(fā)計(jì)算，提高執(zhí)行效率。分桶對于查詢優(yōu)化也非常有好處，可支持bucket裁剪、shuffle move等查詢優(yōu)化操作。

Tunnel SDK提供的數(shù)據(jù)寫入接口目前支持upsert和delete兩種數(shù)據(jù)格式，upsert包含insert / update兩種隱含語義，如數(shù)據(jù)行不存在就代表insert，如已存在就代表update。commit接口代表原子提交這段時(shí)間寫入的數(shù)據(jù)如返回成功就代表寫入數(shù)據(jù)查詢可見，滿足讀寫快照隔離級(jí)別，如返回失敗，數(shù)據(jù)需要重新寫入。

3、SQL批量寫入

圖片

批量導(dǎo)入主要通過SQL進(jìn)行操作。為了方便用戶操作，實(shí)現(xiàn)了操作TT2所有的DDL / DML語法。SQL引擎內(nèi)核模塊包括Compiler、Optimizer、Runtime等都做了大量改造開發(fā)以支持相關(guān)功能，包括特定語法的解析，特定算子的Planner優(yōu)化，針對pk列的去重邏輯，以及runtime構(gòu)造Upsert格式數(shù)據(jù)寫入等。數(shù)據(jù)計(jì)算寫入完成之后，會(huì)由Meta Service來原子性更新Meta信息，此外，也做了大量改造來支持完整的事務(wù)機(jī)制保證讀寫隔離、事務(wù)沖突檢測等等。

4、小數(shù)據(jù)文件合并

圖片

由于TT2本身支持分鐘級(jí)近實(shí)時(shí)增量數(shù)據(jù)導(dǎo)入，高流量場景下可能會(huì)導(dǎo)致增量小文件數(shù)量膨脹，從而引發(fā)存儲(chǔ)訪問壓力大、成本高，并且大量的小文件還會(huì)引發(fā)meta更新以及分析執(zhí)行慢，數(shù)據(jù)讀寫IO效率低下等問題，因此需要設(shè)計(jì)合理的小文件合并服務(wù), 即Clustering服務(wù)來自動(dòng)優(yōu)化此類場景。

Clustering服務(wù)主要由MaxCompute 內(nèi)部的Storage Service來負(fù)責(zé)執(zhí)行，專門解決小文件合并的問題，需要注意的是，它并不會(huì)改變?nèi)魏螖?shù)據(jù)的歷史中間狀態(tài)，即不會(huì)消除數(shù)據(jù)的Update/Delete中間狀態(tài)。

結(jié)合上圖可大概了解Clustering服務(wù)的整體操作流程。Clustering策略制定主要根據(jù)一些典型的讀寫業(yè)務(wù)場景而設(shè)計(jì)，會(huì)周期性的根據(jù)數(shù)據(jù)文件大小，數(shù)量等多個(gè)維度來綜合評(píng)估，進(jìn)行分層次的合并。Level0到Level1主要針對原始寫入的Delta小文件（圖中藍(lán)色數(shù)據(jù)文件）合并為中等大小的Delta文件(圖中黃色數(shù)據(jù)文件)，當(dāng)中等大小的Delta文件達(dá)到一定規(guī)模后，會(huì)進(jìn)一步觸發(fā)Level1到Level2的合并，生成更大的Delta文件（圖中橙色數(shù)據(jù)文件）。

對于一些超過一定大小的數(shù)據(jù)文件會(huì)進(jìn)行專門的隔離處理，不會(huì)觸發(fā)進(jìn)一步合并，避免不必要的讀寫放大問題，如圖中Bucket3的T8數(shù)據(jù)文件。超過一定時(shí)間跨度的文件也不會(huì)合并，因?yàn)闀r(shí)間跨度太大的數(shù)據(jù)合并在一起的話，當(dāng)TimeTravel或者增量查詢時(shí)，可能會(huì)讀取大量不屬于此次查詢時(shí)間范圍的歷史數(shù)據(jù)，造成不必要的讀放大問題。

由于數(shù)據(jù)是按照BucketIndex來切分存儲(chǔ)的，因此Clustering服務(wù)會(huì)以bucket粒度來并發(fā)執(zhí)行，大幅縮短整體運(yùn)行時(shí)間。

Clustering服務(wù)需要和Meta Service進(jìn)行交互，獲取需要執(zhí)行此操作的表或分區(qū)的列表，執(zhí)行結(jié)束之后，會(huì)把新老數(shù)據(jù)文件的信息傳入Meta Service，它負(fù)責(zé)Clustering操作的事務(wù)沖突檢測，新老文件meta信息原子更新、老的數(shù)據(jù)文件回收等。

Clustering服務(wù)可以很好的解決大文件數(shù)量膨脹引發(fā)的一系列效率低下的讀寫問題，但不是頻率越高越好，執(zhí)行一次也會(huì)消耗計(jì)算和IO資源，至少數(shù)據(jù)都要全部讀寫一遍，存在一定的讀寫放大問題。因此執(zhí)行策略的選擇尤其重要，所以目前暫時(shí)不會(huì)開放給用戶手動(dòng)執(zhí)行，而是引擎根據(jù)系統(tǒng)狀態(tài)智能自動(dòng)觸發(fā)執(zhí)行，可保障Clustering服務(wù)執(zhí)行的高效率。

5、數(shù)據(jù)文件Compaction

除了小文件膨脹問題需要解決外，依然還有一些典型場景存在其它問題。TT2支持update、delete格式的數(shù)據(jù)寫入，如果存在大量此格式的數(shù)據(jù)寫入，會(huì)造成中間狀態(tài)的冗余記錄太多，引發(fā)存儲(chǔ)和計(jì)算成本增加，查詢效率低下等問題。因此需要設(shè)計(jì)合理的數(shù)據(jù)文件compaction服務(wù)優(yōu)化此類場景。

Compaction服務(wù)主要由MaxCompute 內(nèi)部的Storage Service來負(fù)責(zé)執(zhí)行，既支持用戶手動(dòng)執(zhí)行SQL語句觸發(fā)、也可通過配置表屬性按照時(shí)間頻率、Commit次數(shù)等維度自動(dòng)觸發(fā)。此服務(wù)會(huì)把選中的數(shù)據(jù)文件，包含base file和delta file，一起進(jìn)行Merge，消除數(shù)據(jù)的Update / Delete中間狀態(tài)，PK值相同的多行記錄只保留最新狀態(tài)的一行記錄，最后生成新的只包含Insert格式的base file。

結(jié)合上圖可大概了解Compaction服務(wù)的整體操作流程。t1到t3時(shí)間段，一些delta files寫入進(jìn)來，觸發(fā)compaction操作，同樣會(huì)以bucket粒度并發(fā)執(zhí)行，把所有的delta files進(jìn)行merge，然后生成新的base file。之后t4和t6時(shí)間段，又寫入了一批新的delta files，再觸發(fā)compaction操作，會(huì)把當(dāng)前存在的base file和新增的delta files一起做merge操作，重新生成一個(gè)新的base file。

Compaction服務(wù)也需要和Meta Service進(jìn)行交互，流程和Clustering類似，獲取需要執(zhí)行此操作的表或分區(qū)的列表，執(zhí)行結(jié)束之后，會(huì)把新老數(shù)據(jù)文件的信息傳入Meta Service，它負(fù)責(zé)Compaction操作的事務(wù)沖突檢測，新老文件meta信息原子更新、老的數(shù)據(jù)文件回收等。

Compaction服務(wù)通過消除數(shù)據(jù)中間歷史狀態(tài)，可節(jié)省計(jì)算和存儲(chǔ)成本，極大加速全量快照查詢場景的效率，但也不是頻率越高越好，首先執(zhí)行一次也要讀取一遍全量數(shù)據(jù)進(jìn)行Merge，極大消耗計(jì)算和IO資源，并且生成的新base file也會(huì)占據(jù)額外的存儲(chǔ)成本，而老的delta file文件可能需要用于支持timetravel查詢，因此不能很快刪除，依然會(huì)有存儲(chǔ)成本，所以Compaction操作需要用戶根據(jù)自己的業(yè)務(wù)場景和數(shù)據(jù)特征來合理選擇執(zhí)行的頻率，通常來說，對于Update / Delete格式的記錄較多，并且全量查詢次數(shù)也較多的場景，可以適當(dāng)增加compaction的頻率來加速查詢。

6、事務(wù)管理

以上主要介紹了典型的數(shù)據(jù)更新操作，而它們的事務(wù)并發(fā)管理都會(huì)統(tǒng)一由Meta Service進(jìn)行控制。

圖片

上面表格詳細(xì)展示了各個(gè)具體操作并發(fā)執(zhí)行的事物沖突規(guī)則。Meta服務(wù)采用了經(jīng)典的MVCC模型來滿足讀寫快照隔離，采用OCC模型進(jìn)行樂觀事務(wù)并發(fā)控制。對于一些高頻的操作單獨(dú)設(shè)計(jì)優(yōu)化了事務(wù)沖突檢測和重試機(jī)制，如clustering操作和insert into 并發(fā)執(zhí)行，即使事務(wù)Start和Commit時(shí)間出現(xiàn)交叉也不會(huì)沖突失敗，都能成功執(zhí)行，即使在原子提交Meta信息更新時(shí)出現(xiàn)小概率失敗也可在Meta層面進(jìn)行事務(wù)重試，代價(jià)很低，不需要數(shù)據(jù)重新計(jì)算和讀寫。

此外，各種數(shù)據(jù)文件信息以及快照版本也需要有效的管理，其中包含數(shù)據(jù)版本、統(tǒng)計(jì)信息、歷史數(shù)據(jù)、生命周期等等。對于TimeTravel和增量查詢，Meta層面專門進(jìn)行了設(shè)計(jì)開發(fā)優(yōu)化，支持高效的查詢歷史版本和文件信息。

7、TimeTravel查詢

基于TT2，計(jì)算引擎可高效支持典型的業(yè)務(wù)場景TimeTravel查詢，即查詢歷史版本的數(shù)據(jù)，可用于回溯歷史狀態(tài)的業(yè)務(wù)數(shù)據(jù)，或數(shù)據(jù)出錯(cuò)時(shí)，用來恢復(fù)歷史狀態(tài)數(shù)據(jù)進(jìn)行數(shù)據(jù)糾正，當(dāng)然也支持直接使用restore操作恢復(fù)到指定的歷史版本。

對于TimeTravel查詢，會(huì)首先找到要查詢的歷史數(shù)據(jù)版本之前最近的base file，再查找后面的delta files，進(jìn)行合并輸出，其中base file可以用來加速查詢讀取效率。

這里結(jié)合上圖進(jìn)一步描述一些具體的數(shù)據(jù)查詢場景。比如創(chuàng)建一TT2表，schema包含一個(gè)pk列和一個(gè)val列。左邊圖展示了數(shù)據(jù)變化過程，在t2和t4時(shí)刻分別執(zhí)行了compaction操作，生成了兩個(gè)base file: b1和b2。b1中已經(jīng)消除了歷史中間狀態(tài)記錄（2,a），只保留最新狀態(tài)的記錄 (2,b)。

如查詢t1時(shí)刻的歷史數(shù)據(jù)，只需讀取delta file (d1)進(jìn)行輸出; 如查詢t2時(shí)刻，只需讀取base file (b1) 輸出其三條記錄。如查詢t3時(shí)刻，就會(huì)包含base file ( b1)加上delta file (d3)進(jìn)行合并輸出，可依此類推其他時(shí)刻的查詢。

可見，base文件雖可用來加速查詢，但需要觸發(fā)較重的compaction操作，用戶需要結(jié)合自己的業(yè)務(wù)場景選擇合適的觸發(fā)策略。

TimeTravel可根據(jù)timestamp和version兩種版本形態(tài)進(jìn)行查詢，除了直接指定一些常量和常用函數(shù)外，我們還額外開發(fā)了get_latest_timestamp和get_latest_version兩個(gè)函數(shù)，第二個(gè)參數(shù)代表它是最近第幾次commit，方便用戶獲取我們內(nèi)部的數(shù)據(jù)版本進(jìn)行精準(zhǔn)查詢，提升用戶體驗(yàn)。

8、增量查詢

圖片

此外，SQL增量查詢也是重點(diǎn)設(shè)計(jì)開發(fā)的場景，主要用于一些業(yè)務(wù)的近實(shí)時(shí)增量處理鏈路，新增SQL語法采用between and關(guān)鍵字，查詢的時(shí)間范圍是左開右閉，即begin是一個(gè)開區(qū)間，必須大于它，end是一個(gè)閉區(qū)間。

增量查詢不會(huì)讀取任何base file，只會(huì)讀取指定時(shí)間區(qū)間內(nèi)的所有delta files，按照指定的策略進(jìn)行Merge輸出。

通過上訴表格可進(jìn)一步了解細(xì)節(jié)，如begin是t1-1，end是t1，只讀取t1時(shí)間段對應(yīng)的delta file (d1)進(jìn)行輸出, 如果end是t2，會(huì)讀取兩個(gè)delta files (d1和d2)；如果begin是t1，end是t2-1，即查詢的時(shí)間范圍為(t1, t2)，這個(gè)時(shí)間段是沒有任何增量數(shù)據(jù)插入的，會(huì)返回空行。

對于Clustering和Compaction操作也會(huì)產(chǎn)生新的數(shù)據(jù)文件，但并沒有增加新的邏輯數(shù)據(jù)行，因此這些新文件都不會(huì)作為新增數(shù)據(jù)的語義，增量查詢做了專門設(shè)計(jì)優(yōu)化，會(huì)剔除掉這些文件，也比較貼合用戶使用場景。

9、歷史版本數(shù)據(jù)回收

由于Timetravel和增量查詢都會(huì)查詢數(shù)據(jù)的歷史狀態(tài)，因此需要保存一定的時(shí)間，可通過表屬性acid.data.retain.hours來配置保留的時(shí)間范圍。如果歷史狀態(tài)數(shù)據(jù)存在的時(shí)間早于配置值，系統(tǒng)會(huì)開始自動(dòng)回收清理，一旦清理完成，TimeTravel就查詢不到對應(yīng)的歷史狀態(tài)了。回收的數(shù)據(jù)主要包含操作日志和數(shù)據(jù)文件兩部分。

同時(shí)，也會(huì)提供purge命令，用于特殊場景下手動(dòng)觸發(fā)強(qiáng)制清除歷史數(shù)據(jù)。

10、數(shù)據(jù)接入生態(tài)集成現(xiàn)狀

初期上線支持接入TT2的工具主要包括：

• DataWorks數(shù)據(jù)集成：支持?jǐn)?shù)據(jù)庫等豐富的數(shù)據(jù)源表全量以及增量的同步業(yè)務(wù)。
• MaxCompute Flink Connector：支持近實(shí)時(shí)的upsert數(shù)據(jù)增量寫入，這一塊還在持續(xù)優(yōu)化中，包括如何確保Exactly Once語義，如何保障大規(guī)模分區(qū)寫入的穩(wěn)定性等，都會(huì)做深度的設(shè)計(jì)優(yōu)化。
• MaxCompute MMA：支持大規(guī)模批量 Hive數(shù)據(jù)遷移。很多業(yè)務(wù)場景數(shù)據(jù)遷移可能先把存在的全量表導(dǎo)入進(jìn)來，之后再持續(xù)近實(shí)時(shí)導(dǎo)入增量數(shù)據(jù)，因此需要有一些批量導(dǎo)入的工具支持。
• 阿里云實(shí)時(shí)計(jì)算Flink版Connector：支持近實(shí)時(shí)Upsert數(shù)據(jù)增量寫入，功能還在完善中。
• MaxCompute SDK：直接基于SDK開發(fā)支持近實(shí)時(shí)導(dǎo)入數(shù)據(jù)，不推薦
• MaxCompute SQL：通過SQL批量導(dǎo)入數(shù)據(jù)

對其它一些接入工具，比如Kafka等，后續(xù)也在陸續(xù)規(guī)劃支持中。

11、特點(diǎn)

作為一個(gè)新設(shè)計(jì)的架構(gòu)，我們會(huì)盡量去覆蓋開源數(shù)據(jù)湖(HUDI / Iceberg)的一些通用功能，有助于類似業(yè)務(wù)場景的用戶進(jìn)行數(shù)據(jù)和業(yè)務(wù)鏈路遷移。此外，MaxCompute離線 & 近實(shí)時(shí)增量處理一體化架構(gòu)還具備一些獨(dú)特的亮點(diǎn)：

• 統(tǒng)一的存儲(chǔ)、元數(shù)據(jù)、計(jì)算引擎一體化設(shè)計(jì)，做了非常深度和高效的集成，具備存儲(chǔ)成本低，數(shù)據(jù)文件管理高效，查詢效率高，并且Timetravel / 增量查詢可復(fù)用MaxCompute批量查詢的大量優(yōu)化規(guī)則等優(yōu)勢。
• 全套統(tǒng)一的SQL語法支持，非常便于用戶使用。
• 深度定制優(yōu)化的數(shù)據(jù)導(dǎo)入工具，支持一些復(fù)雜的業(yè)務(wù)場景。
• 無縫銜接MaxCompute現(xiàn)有的業(yè)務(wù)場景，可以減少遷移、存儲(chǔ)、計(jì)算成本。
• 完全自動(dòng)化管理數(shù)據(jù)文件，保證更好的讀寫穩(wěn)定性和性能，自動(dòng)優(yōu)化存儲(chǔ)效率和成本。
• 基于MaxCompute平臺(tái)完全托管，用戶可以開箱即用，沒有額外的接入成本，功能生效只需要?jiǎng)?chuàng)建一張新類型的表即可。
• 作為完全自研的架構(gòu)，需求開發(fā)節(jié)奏完全自主可控。

四、應(yīng)用實(shí)踐與未來規(guī)劃

1、離線 & 近實(shí)時(shí)增量處理一體化業(yè)務(wù)架構(gòu)實(shí)踐

基于新架構(gòu)，MaxCompute可重新構(gòu)建離線 & 近實(shí)時(shí)增量處理一體化的業(yè)務(wù)架構(gòu)，即可以解決大部分的Lambda架構(gòu)的痛點(diǎn)，也能節(jié)省使用單一離線或者實(shí)時(shí)系統(tǒng)架構(gòu)帶來的一些不可避免的計(jì)算和存儲(chǔ)成本。各種數(shù)據(jù)源可以方便的通過豐富的接入工具實(shí)現(xiàn)增量和離線批量導(dǎo)入，由統(tǒng)一的存儲(chǔ)和數(shù)據(jù)管理服務(wù)自動(dòng)優(yōu)化數(shù)據(jù)編排，使用統(tǒng)一的計(jì)算引擎支持近實(shí)時(shí)增量處理鏈路和大規(guī)模離線批量處理鏈路，而且由統(tǒng)一的元數(shù)據(jù)服務(wù)支持事務(wù)和文件元數(shù)據(jù)管理。它帶來的優(yōu)勢非常顯著，可有效避免純離線系統(tǒng)處理增量數(shù)據(jù)導(dǎo)致的冗余計(jì)算和存儲(chǔ)，也能解決純實(shí)時(shí)系統(tǒng)高昂的資源消耗成本，也可消除多套系統(tǒng)的不一致問題和減少冗余多份存儲(chǔ)成本以及系統(tǒng)間的數(shù)據(jù)遷移成本，其他的優(yōu)勢可以參考上圖，就不一一列舉了?？傮w而言，就是使用一套架構(gòu)既可以滿足增量處理鏈路的計(jì)算存儲(chǔ)優(yōu)化以及分鐘級(jí)的時(shí)效性，又能保證批處理的整體高效性，還能有效節(jié)省資源使用成本。

2、未來規(guī)劃

最后再看一下未來一年內(nèi)的規(guī)劃：

• 持續(xù)完善SQL的整體功能支持，降低用戶接入門檻；完善Schema Evolution支持。
• 更加豐富的數(shù)據(jù)接入工具的開發(fā)支持，持續(xù)優(yōu)化特定場景的數(shù)據(jù)寫入效率。
• 開發(fā)增量查詢小任務(wù)分鐘級(jí)別的pipeline自動(dòng)執(zhí)行調(diào)度框架，極大的簡化用戶增量處理鏈路業(yè)務(wù)的開發(fā)難度，完全自動(dòng)根據(jù)任務(wù)執(zhí)行狀態(tài)觸發(fā)pipeline任務(wù)調(diào)度，并自動(dòng)讀取增量數(shù)據(jù)進(jìn)行計(jì)算。
• 持續(xù)繼續(xù)優(yōu)化SQL查詢效率，以及數(shù)據(jù)文件自動(dòng)優(yōu)化管理。
• 擴(kuò)展生態(tài)融合，支持更多的第三方引擎讀寫TT2。

五、Q & A

Q1：Bucket數(shù)量的設(shè)置與commit間隔以及compaction間隔設(shè)置的最佳推薦是什么？

A1：Bucket數(shù)量與導(dǎo)入的數(shù)據(jù)量相關(guān)，數(shù)據(jù)量越大，建議設(shè)置的bucket數(shù)量多一些，在批量導(dǎo)入的場景，推薦每個(gè)bucket的數(shù)據(jù)量不要超過1G，在近實(shí)時(shí)增量導(dǎo)入場景，也要根據(jù)Tunnel的可用資源以及QPS流量情況來決定bucket數(shù)量。對于commit的間隔雖然支持分鐘級(jí)數(shù)據(jù)可見，但如果數(shù)據(jù)規(guī)模較大，bucket數(shù)量較多，我們推薦間隔最好在五分鐘以上，也需要考慮結(jié)合 Flink Connector的checkpoint機(jī)制來聯(lián)動(dòng)設(shè)置commit頻率，以支持Exactly Once語義，流量不大的話，5~10分鐘間隔是推薦值。Compaction間隔跟業(yè)務(wù)場景相關(guān)，它有很大的計(jì)算成本，也會(huì)引入額外的base file存儲(chǔ)成本，如果對查詢效率要求比較高且比較頻繁，compaction需要考慮設(shè)置合理的頻率，如果不設(shè)置，隨著delta files和update記錄的不斷增加，查詢效率會(huì)越來越差。

Q2：會(huì)不會(huì)因?yàn)閏ommit太快，compaction跟不上？

A2：Commit頻率和Compaction頻率沒有直接關(guān)系，Compaction會(huì)讀取全量數(shù)據(jù)，所以頻率要低一些，至少小時(shí)或者天級(jí)別，而Commit寫入增量數(shù)據(jù)的頻率是比較快的，通常是分鐘級(jí)別。

Q3：是否需要專門的增量計(jì)算優(yōu)化器？

A3：這個(gè)問題很好，確實(shí)需要有一些特定的優(yōu)化規(guī)則，目前只是復(fù)用我們現(xiàn)有的SQL優(yōu)化器，后續(xù)會(huì)持續(xù)規(guī)劃針對一些特殊的場景進(jìn)行增量計(jì)算的設(shè)計(jì)優(yōu)化。

Q4：剛剛說會(huì)在一兩個(gè)月邀測MaxCompute新架構(gòu)，讓大家去咨詢。是全部替換為新的架構(gòu)還是上線一部分的新架構(gòu)去做些嘗試，是要讓用戶去選擇嗎？還是怎樣？

A4：新技術(shù)架構(gòu)對用戶來說是透明的，用戶可以通過MaxCompute無縫接入使用，只需要?jiǎng)?chuàng)建新類型的表即可。針對有這個(gè)需求的新業(yè)務(wù)或者之前處理鏈路性價(jià)比不高的老業(yè)務(wù)，可以考慮慢慢切換到這條新鏈路嘗試使用。