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

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

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

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

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

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

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

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

對于這類業(yè)務(wù)場景的解決方案，如果使用單一的MaxCompute離線批量處理鏈路，為了計算的高效性，需要將用戶各種復(fù)雜的一些鏈路和處理邏輯轉(zhuǎn)化成T+1的批次處理，鏈路復(fù)雜度增加，也可能產(chǎn)生冗余的計算和存儲成本，且時效性也較差。但如果使用單一的實時系統(tǒng)，資源消耗的成本比較高，性價比也較低，并且大規(guī)模數(shù)據(jù)批處理的穩(wěn)定性也不足。因此當前比較典型的解決方案是Lambda架構(gòu)，全量批處理使用MaxCompute鏈路，時效性要求比較高的增量處理使用實時系統(tǒng)鏈路，但該架構(gòu)也存在大家所熟知的一些固有缺陷，比如多套處理和存儲引擎引發(fā)的數(shù)據(jù)不一致問題，多份數(shù)據(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ā)的離線近實時增量處理一體化架構(gòu)，同樣是為了解決這些問題而設(shè)計，不僅僅具備分鐘級的增全量數(shù)據(jù)讀寫以及數(shù)據(jù)處理的業(yè)務(wù)需求，也能提供Upsert，Timetravel等一系列實用功能，可大幅擴展業(yè)務(wù)場景，并且有效的節(jié)省數(shù)據(jù)計算，存儲和遷移成本，切實提高用戶體驗。下文就將介紹該技術(shù)架構(gòu)的一些典型的功能和設(shè)計。

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

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

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

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

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

圖片

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

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

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

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

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

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

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

寫入并發(fā)度可通過前面提及的表屬性write.bucket.num來配置，因此寫入速度可水平擴展。對同一張表或分區(qū)的數(shù)據(jù)，寫入數(shù)據(jù)會按pk值對數(shù)據(jù)進行切分，相同pk值會落在同一個bucket桶中。此外，數(shù)據(jù)分桶的好處還有利于數(shù)據(jù)優(yōu)化管理操作例如小文件clustering，compaction等都可以桶的粒度來并發(fā)計算，提高執(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ù)據(jù)如返回成功就代表寫入數(shù)據(jù)查詢可見，滿足讀寫快照隔離級別，如返回失敗，數(shù)據(jù)需要重新寫入。

3、SQL批量寫入

圖片

批量導(dǎo)入主要通過SQL進行操作。為了方便用戶操作，實現(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ù)計算寫入完成之后，會由Meta Service來原子性更新Meta信息，此外，也做了大量改造來支持完整的事務(wù)機制保證讀寫隔離、事務(wù)沖突檢測等等。

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

圖片

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

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

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

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

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

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

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

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

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

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

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

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

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

6、事務(wù)管理

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

圖片

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

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

7、TimeTravel查詢

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

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

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

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

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

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

8、增量查詢

圖片

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

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

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

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

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

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

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

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

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

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

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

11、特點

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

• 統(tǒng)一的存儲、元數(shù)據(jù)、計算引擎一體化設(shè)計，做了非常深度和高效的集成，具備存儲成本低，數(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ù)場景，可以減少遷移、存儲、計算成本。
• 完全自動化管理數(shù)據(jù)文件，保證更好的讀寫穩(wěn)定性和性能，自動優(yōu)化存儲效率和成本。
• 基于MaxCompute平臺完全托管，用戶可以開箱即用，沒有額外的接入成本，功能生效只需要創(chuàng)建一張新類型的表即可。
• 作為完全自研的架構(gòu)，需求開發(fā)節(jié)奏完全自主可控。

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

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

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

2、未來規(guī)劃

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

• 持續(xù)完善SQL的整體功能支持，降低用戶接入門檻；完善Schema Evolution支持。
• 更加豐富的數(shù)據(jù)接入工具的開發(fā)支持，持續(xù)優(yōu)化特定場景的數(shù)據(jù)寫入效率。
• 開發(fā)增量查詢小任務(wù)分鐘級別的pipeline自動執(zhí)行調(diào)度框架，極大的簡化用戶增量處理鏈路業(yè)務(wù)的開發(fā)難度，完全自動根據(jù)任務(wù)執(zhí)行狀態(tài)觸發(fā)pipeline任務(wù)調(diào)度，并自動讀取增量數(shù)據(jù)進行計算。
• 持續(xù)繼續(xù)優(yōu)化SQL查詢效率，以及數(shù)據(jù)文件自動優(yōu)化管理。
• 擴展生態(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)入的場景，推薦每個bucket的數(shù)據(jù)量不要超過1G，在近實時增量導(dǎo)入場景，也要根據(jù)Tunnel的可用資源以及QPS流量情況來決定bucket數(shù)量。對于commit的間隔雖然支持分鐘級數(shù)據(jù)可見，但如果數(shù)據(jù)規(guī)模較大，bucket數(shù)量較多，我們推薦間隔最好在五分鐘以上，也需要考慮結(jié)合 Flink Connector的checkpoint機制來聯(lián)動設(shè)置commit頻率，以支持Exactly Once語義，流量不大的話，5~10分鐘間隔是推薦值。Compaction間隔跟業(yè)務(wù)場景相關(guān)，它有很大的計算成本，也會引入額外的base file存儲成本，如果對查詢效率要求比較高且比較頻繁，compaction需要考慮設(shè)置合理的頻率，如果不設(shè)置，隨著delta files和update記錄的不斷增加，查詢效率會越來越差。

Q2：會不會因為commit太快，compaction跟不上？

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

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

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

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

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