隨着當前數據處理業務場景日趨複雜，對於大數據處理平臺基礎架構的能力要求也越來越高，既要求數據湖的大存儲能力，也要求具備海量數據高效批處理能力，同時還可能對延時敏感的近實時鏈路有強需求，本文主要介紹基於 MaxCompute 的離線近實時一體化新架構如何來支持這些綜合的業務場景，提供近實時增全量一體的數據存儲和計算（Transaction Table2.0）解決方案。
業務背景和現狀
當前典型的數據處理業務場景中，對於時效性要求低的大規模數據全量批處理的單一場景，直接使用 MaxCompute 足以很好的滿足業務需求。但隨着 MaxCompute 承載的業務無論是規模，還是使用場景，都越來越豐富，在處理好大規模離線批處理鏈路的同時，用戶對近實時和增量處理鏈路也有很多的需求，下圖展示了部分業務場景。
比如近實時數據導入鏈路，依賴平臺引擎具備事務隔離，小文件自動合併等能力，又比如增全量數據合併鏈路，還依賴增量數據存儲和讀寫，主鍵等能力。MaxCompute以前不具備新架構能力之前，要支持這些複雜的綜合業務場景，只能通過下圖所示的三種解決方案，但無論使用單一引擎或者聯邦多引擎都存在一些無法解決的痛點。
方案一，只使用單一的MaxCompute離線批處理解決方案，對於近實時鏈路或者增量處理鏈路通常需要轉化成T+1的批處理鏈路，會一定程度上增加業務邏輯複雜度，且時效性也較差，存儲成本也可能較高。方案二，只使用單一的實時引擎，那資源成本會較高，性價比較低，且對於大規模數據批處理鏈路的穩定性和靈活性也存在一些瓶頸。方案三，使用典型的Lambda架構，全量批處理使用MaxCompute鏈路，時效性要求比較高的增量處理使用實時引擎鏈路，但該架構也存在大家所熟知的一些固有缺陷，比如多套處理和存儲引擎引發的數據不一致問題，多份數據冗餘存儲和計算引入的額外成本，架構複雜以及開發週期長等問題。這些解決方案在成本，易用性，低延時，高吞吐等方面互相制約，很難同時具備較好的效果，這也驅動着MaxCompute有必要開發新的架構既能滿足這些業務場景需求，也能提供較低的成本和較好的用戶體驗。
近幾年在大數據開源生態中，針對這些問題已經形成了一些典型的解決方案，最流行的就是Spark/Flink/Trino開源數據處理引擎，深度集成Hudi / Delta Lake / Iceberg / Paimon開源數據湖，踐行開放統一的計算引擎和統一的數據存儲思想來提供解決方案，解決Lamdba架構帶來的一系列問題。同時MaxCompute近一年多在離線批處理計算引擎架構上，自研設計了離線&近實時數倉一體化架構，在保持經濟高效的批處理優勢下，同時具備分鐘級的增量數據讀寫和處理的業務需求，另外，還可提供Upsert，Time travel等一系列實用功能來擴展業務場景，可有效地節省數據計算，存儲和遷移成本，切實提高用戶體驗。
離線&近實時增全量一體化業務架構
上圖所示即爲MaxCompute高效支持上述綜合業務場景的全新業務架構。寫入端會融合多種數據集成工具將豐富的數據源近實時增量或批量導入到統一的MaxCompute表存儲中，存儲引擎的表數據管理服務會自動優化編排數據存儲結構來治理小文件等問題；使用統一的計算引擎支持近實時增量和大規模離線批量分析處理鏈路；由統一的元數據服務支持事務機制和海量文件元數據管理。統一的新架構帶來的優勢也是非常顯著，可有效解決純離線系統處理增量數據導致的冗餘計算和存儲、時效低等問題，也能避免實時系統高昂的資源消耗成本，同時可消除Lambda架構多套系統的不一致問題，減少冗餘多份存儲成本以及系統間的數據遷移成本。簡言之，一體化新架構既可以滿足增量處理鏈路的計算存儲優化以及分鐘級的時效性，又能保證批處理的整體高效性，還能有效節省資源使用成本。
目前新架構已支持了部分核心能力，包括主鍵表，Upsert實時寫入，Time travel查詢，增量查詢，SQL DML操作，表數據自動治理優化等，更詳細的架構原理和相關操作指導請參考官網架構原理和用戶操作文檔。
業務場景實踐
本章節重點介紹新架構如何支持一些典型的業務鏈路以及產生的優化效果。
表存儲和數據治理優化
本章節主要介紹建表操作和關鍵表屬性的含義，以及根據業務場景如何設置表屬性值以達到最佳效果，也會簡單描述一下存儲引擎後臺如何自動優化表數據。
建表
首先，一體化新架構需要設計統一的表格式來存儲不同格式的數據以支撐不同業務場景的數據讀寫，這裏稱爲Transaction Table2.0，簡稱TT2，可以同時支持既有的批處理鏈路，以及近實時增量等新鏈路的所有功能。
建表語法參考官網，簡單示例:
createtable tt2 (pk bigint notnullprimarykey, val string) tblproperties ("transactional"="true");
createtable par_tt2 (pk bigint notnullprimarykey, val string)
partitioned by (pt string) tblproperties ("transactional"="true");
只需要設置主鍵Primary Key(PK)，以及表屬性transactional爲true，就可以創建一張TT2。PK用來保障數據行的unique屬性，transactional屬性用來配置ACID事務機制，滿足讀寫快照隔離。
關鍵的表屬性配置
詳細屬性配置參考官網，簡單示例:
createtable tt2 (pk bigint notnullprimarykey, val string)
tblproperties ("transactional"="true", "write.bucket.num" = "32", "acid.data.retain.hours"="48");
表屬性: write.bucket.num
此屬性非常重要，表示每個partition或者非分區表的分桶數量，默認值爲16，所有寫入的記錄會根據PK值對數據進行分桶存儲，相同PK值的記錄會落在同一個桶中。非分區表不支持修改，分區表可修改，但只有新分區生效。
數據寫入和查詢的併發度可通過bucket數量來水平擴展，每個併發可至少處理一個桶數據。但桶數量並不是越多越好，對於每個數據文件只會歸屬一個桶，因此桶數量越多，越容易產生更多的小文件，進一步可能增加存儲成本和壓力，以及讀取效率。因此需要結合數據寫入的吞吐，延時，總數據的大小，分區數，以及讀取延時來整體評估合理的桶數量。
此外，數據分桶存儲也非常有助於提升點查場景性能，如果查詢語句的過濾條件爲具體的PK值，那查詢時可進行高效的桶裁剪和數據文件裁剪，極大減少查詢的數據量。
評估桶數量建議
- 對於非分區表，如果數據量小於1G，桶數量建議設置爲4-16; 如果總數據量大於1G，建議按照128M-256M作爲一個桶數據的大小，如果希望查詢的併發度更多的話，可以進一步調小桶數據量大小; 如果總數據量大於1T，建議按照500M-1G作爲一個桶數據的大小; 但目前能夠設置的最大桶數量是4096，因此對於更大的數據量，單個桶的數據量也只能越來越大，會進一步影響查詢效率，後續平臺也會考慮是否可放開更大的限制。
- 對於分區表，設置的桶數量是針對每個分區的，並且每個分區的桶數量可以不同。每個分區的桶數量設置原則可以參考上面非分區表的配置建議。對於存在海量分區的表，並且每個分區的數據量又較小的話，比如在幾十M以內，建議每個分區的桶數量儘可能少，配置在1-2個即可，避免產生過多的小文件。
表屬性: acid.data.retain.hours
此屬性也很重要，代表time travel查詢時可以讀取的歷史數據實踐範圍，默認值是1天，最大支持7天。
建議用戶按真實的業務場景需求來設置合理的時間週期，設置的時間越長，保存的歷史數據越多，產生的存儲費用就越多，而且也會一定程度上影響查詢效率，如果用戶不需要time travel查詢歷史數據，建議此屬性值設置爲0，代表關掉time travel功能，這樣可以有效節省數據歷史狀態的存儲成本。
Schema Evolution操作
TT2支持完整的Schema Evolution操作，包括增加和刪除列。在time travel查詢歷史數據時，會根據歷史數據的Schema來讀取數據。另外PK列不支持修改。
詳細DDL語法參考官網，簡單示例:
altertable tt2 add columns (val2 string);
altertable tt2 drop columns val;
表數據自動治理優化
存在的問題
TT2典型場景之一是支持分鐘級近實時增量數據導入，因此可能導致增量小文件數量膨脹，尤其是桶數量較大的情況，從而引發存儲訪問壓力大、成本高，數據讀寫IO效率低下，文件元數據分析慢等問題，如果Update/Delete格式的數據較多，也會造成數據中間狀態的冗餘記錄較多，進一步增加存儲和計算的成本，查詢效率降低等問題。
爲此，後臺存儲引擎配套支持了合理高效的表數據服務對存儲數據進行自動治理和優化，降低存儲和計算成本，提升分析處理性能。
表數據組織格式
如上圖所示，展示了分區表的數據結構，先按照分區對數據文件進行物理隔離，不同分區的數據在不同的目錄之下; 每個分區內的數據按照桶數量來切分數據，每個桶的數據文件單獨存放; 每個桶內的數據文件類型主要分成三種:
- Delta Data File：每次事務寫入或者小文件合併後生成的增量數據文件，會保存每行記錄的中間歷史狀態，用於滿足近實時增量讀寫需求。
- Compacted Data File：Delta File經過Compact執行生成的數據文件，會消除數據記錄的中間歷史狀態，PK值相同的記錄只會保留一行，按照列式壓縮存儲，用來支撐高效的數據查詢需求。
- Delta CDC Log: 按照時序存儲的CDC格式增量日誌 (目前還未對外推出)。
數據自動治理優化
如上圖所示，TT2的表數據服務主要分成Auto Sort / Auto Merge / Auto Compact / Auto Clean四種，用戶無需主動配置，存儲引擎後臺服務會智能的自動收集各個維度的數據信息，配置合理的策略自動執行。
- Auto Sort: 自動將實時寫入的行存avro文件轉換成aliorc列存文件，節省存儲成本和提升讀取效率。
- Auto Merge: 自動合併小文件，解決小文件數量膨脹引發的各種問題。主要策略是週期性地根據數據文件大小/文件數量/寫入時序等多個維度進行綜合分析，進行分層次的合併。但它並不會消除任何一條記錄的中間歷史狀態，主要用於time travel查詢歷史數據。
- Auto Partial Compact: 自動合併文件並消除記錄的歷史狀態，降低update/delete記錄過多帶來的額外存儲成本，以及提升讀取效率。主要策略是週期性地根據增量的數據大小/寫入時序/time travel時間等多個維度進行綜合分析來執行compact操作。該操作只針對超過time travel可查詢時間範圍的歷史記錄進行compact。
- Auto Clean: 自動清理無效文件，節省存儲成本。Auto Sort / Auto Merge / Auto Partial Compact操作執行完成後，會生成新的數據文件，所以老的數據文件其實沒什麼作用了，會被即時自動刪除，及時節省存儲成本。
如果用戶對於查詢性能的要求非常高，也可嘗試手動執行全量數據的major compact操作，每個桶的所有數據會消除所有的歷史狀態，並且額外生成一個新的Aliorc列存數據文件，用於高效查詢，但也會產生額外的執行成本，以及新文件的存儲成本，因此非必要儘量不執行。
詳細語法參考官網，簡單示例:
set odps.merge.task.mode=service;
altertable tt2 compact major;
數據寫入場景業務實踐
本章節主要介紹部分典型的寫入場景業務實踐。
分鐘級近實時 Upsert 寫入鏈路
MaxCompute離線架構一般在小時或天級別批量導入增量數據到一張新表或者新分區中，然後配置對應的離線ETL處理鏈路，將增量數據和存量表數據執行Join Merge操作，生成最新的全量數據，此離線鏈路的延時較長，計算和存儲也會消耗一定的成本。
使用新架構的upsert實時導入鏈路基本可以保持數據從寫入到查詢可見的延時在5-10分鐘，滿足分鐘級近實時業務需求，並且不需要複雜的ETL鏈路來進行增全量的Merge操作，節省相應的計算和存儲成本。
實際業務數據處理場景中，涉及的數據源豐富多樣，可能存在數據庫、日誌系統或者其他消息隊列等系統，爲了方便用戶數據寫入TT2， MaxCompute深度定製開發了開源Flink Connector工具，針對高併發、容錯、事務提交等場景做了定製化的設計及開發優化，以滿足延時低、正確性高等要求，同時也能很好的對接融合Flink生態。具體使用細節可以參考官網產品說明
上圖簡單展示了整體寫入的流程，可總結如下主要關鍵點:
- 基本大部份可融合flink生態的引擎或者工具都可通過flink任務，結合MaxCompute flink connector實時寫入數據進TT2表。
- 寫入併發可以橫向擴展，滿足低延時高吞吐需求。寫入流量吞吐跟flink sink併發數，TT2桶數量等參數配置相關，可根據各自的業務場景進行合理配置。特別說明，針對TT2桶數量配置爲Flink sink併發數的整數倍的場景，系統進行了高效優化，寫入性能最佳。
- 滿足數據分鐘級可見，支持讀寫快照隔離
- 結合Flink的Checkpoint機制處理容錯場景，保障exactly_once語義。
- 支持上千分區同時寫入，滿足海量分區併發寫入場景需求。
- 流量吞吐上限可參考單個桶1MB/s的處理能力進行評估，不同環境不同配置都可能影響吞吐。如果對寫入延時比較敏感，需要相對穩定的吞吐量，可考慮申請獨享的數據傳輸資源，但需要額外收費。如果默認使用共享的公共數據傳輸服務資源組的話，在資源競搶嚴重的情況下，可能保障不了穩定的寫入吞吐量，並且可使用的資源量也有上限。
部分列增量更新鏈路
該鏈路可用來優化將多張增量表的數據列拼接到一張大寬表的場景，比較類似多流join的業務場景。
如上圖所示，左邊展示了MaxCompute的離線ETL鏈路處理此類場景，將多張增量表按照比較固定的時間來對齊數據，通常小時/天級別，然後觸發一個join任務，把所有表的數據列拼接起來生成大寬表，如果有存量數據，還需要執行類似upsert的ETL鏈路。因此整體ETL鏈路延時較長，流程複雜，也比較消耗計算和存儲資源，數據也容易遇到無法對齊的場景。
右邊展示了通過TT2表支持部分列更新的能力，只需要將各個表的數據列實時增量更新到TT2大寬表中即可，TT2表的後臺Compact服務以及查詢時，會自動把相同PK值的數據行拼接成一行數據。該鏈路基本完全解決了離線鏈路遇到的問題，延時從小時/天級別降低到分鐘級，而且鏈路簡單，幾乎是ZeroETL，也能成倍節省計算和存儲成本。
目前支持以下兩種方式進行部分列更新，功能還在灰度上線中，還未發佈到官網(預計兩個月內在公共雲發佈)。
- 通過SQL Insert進行增量寫入部分列：
createtable tt2 (pk bigint notnullprimarykey, val1 string, val2 string, val3 string) tblproperties ("transactional"="true");
insertinto tt2 (pk, val1) select pk, val1 from table1;
insertinto tt2 (pk, val2) select pk, val2 from table2;
insertinto tt2 (pk, val3) select pk, val3 from table3;
- 通過Flink Connector實時寫入部分列。
SQL DML / Upsert 批處理鏈路
爲了方便用戶操作TT2表，MaxCompute計算引擎對SQL全套的數據查詢DQL語法和數據操作DML語法進行了支持，保障離線鏈路的高可用和良好的用戶體驗。SQL引擎的內核模塊包括Compiler、Optimizer、Runtime等都做了專門適配開發以支持相關功能和優化，包括特定語法的解析，特定算子的Plan優化，針對pk列的去重邏輯，以及runtime upsert併發寫入等。
數據處理完成之後，會由Meta Service來執行事務衝突檢測，原子更新數據文件元信息等，保障讀寫隔離和事務一致性。
SQL DML具體語法可參考官網文檔，對於Insert / Update / Delete / Merge Into都有詳細的介紹和示例。
對於Upsert批式寫入能力，由於TT2表後臺服務或者查詢時會自動根據PK值來合併記錄，因此對於Insert + Update場景，不需要使用複雜的Update/Merge Into語法，可統一使用Insert into插入新數據即可，使用簡單，並且能節省一些讀取IO和計算資源。
數據查詢場景業務實踐
本章節主要介紹部分典型的查詢場景業務實踐。
Time travel查詢
基於TT2，計算引擎可高效支持Time travel查詢的典型業務場景，即查詢歷史版本的數據，可用於回溯業務數據的歷史狀態，或數據出錯時，用來恢復歷史狀態數據進行數據糾正。
詳細語法參考官網，簡單示例：
//查詢指定時間戳的歷史數據
select * from tt2 timestampasof'2024-04-01 01:00:00';
//查詢5分鐘之間的歷史數據
select * from tt2 timestampasofcurrent_timestamp() - 300;
//查詢截止到最近第二次Commit寫入的歷史數據
select * from tt2 timestampasof get_latest_timestamp('tt2', 2);
可查詢的歷史數據時間範圍，可通過表屬性acid.data.retain.hours來配置，配置策略上文已介紹，配置參數詳解參考官網。
Time travel查詢處理過程簡介
SQL引擎接收到用戶側輸入的time travel查詢語法後，會先從Meta服務中解析出來要查詢的歷史數據版本，然後過濾出來要讀取的Compacted file和Delta file，進行合併merge輸出，Compacted file可極大提升讀取效率。
結合上圖示例進一步描述查詢細節：
- 圖中TT2 Schema包含一個pk列和一個val列。左邊圖展示了數據變化過程，t1 - t5代表了5個事務的時間版本，分別執行了5次數據寫入操作，生成了5個Delta file，在t2和t4時刻分別執行了Compact操作，生成了兩個Compacted File: c1和c2，可見c1已經消除了中間狀態歷史記錄（2,a），只保留最新狀態的記錄（2,b）。
- 如查詢t1時刻的歷史數據，只需讀取Delta file (d1) 進行輸出; 如查詢t2時刻，只需讀取Compacted file (c1) 輸出其三條記錄。如查詢t3時刻，就會包含Compacted file (c1)以及Delta file (d3) 進行合併merge輸出，可依此類推其他時刻的查詢。可見，Compacted file文件雖可用來加速查詢，但需要觸發較重的Compact操作，用戶需要結合自己的業務場景主動觸發major compact，或者由後臺系統自動觸發compact操作。
- Time travel查詢設置的事務版本，支持時間版本和ID版本兩種形態，SQL語法上除了可直接指定一些常量和常用函數外，還額外開發了get_latest_timestamp和get_latest_version兩個函數，第二個參數代表它是最近第幾次commit，方便用戶獲取MaxCompute內部的數據版本進行精準查詢，提升用戶體驗。
增量查詢
TT2表支持增量寫入和存儲，最重要的一個考慮就是支持增量查詢以及增量計算鏈路，爲此，也專門設計開發了新的SQL增量查詢語法來支持近實時增量處理鏈路。用戶通過增量查詢語句可靈活構建增量數倉業務鏈路，近期正在規劃開發支持增量物化視圖來進一步簡化使用門檻，提升用戶體驗，降低用戶成本。
支持兩種增量查詢語法：
- 用戶指定時間戳或者版本查詢增量數據，詳細語法參考官網，簡單示例：
//查詢2024-04-0101:00:00-01:10:00之間十分鐘的增量數據
select * from tt2 timestampbetween'2024-04-01 01:00:00'and'2024-04-01 01:10:00';
//查詢前10分鐘到前5分鐘之間的增量數據
select * from tt2 timestampbetweencurrent_timestamp() - 601andcurrent_timestamp() - 300;
//查詢最近一次commit的增量數據
select * from tt2 timestampbetween get_latest_timestamp('tt2', 2) and get_latest_timestamp('tt2');
- 引擎自動管理數據版本查詢增量數據，不需要用戶手動指定查詢版本, 非常適合週期性的增量計算鏈路 (功能灰度發佈中，以官網發佈爲準)。簡單示例：
//綁定一個stream對象到tt2表上
create stream tt2_stream ontable tt2;
insertinto tt2 values (1, 'a'), (2, 'b');
//自動查詢出來新增的兩條記錄(1, 'a'), (2, 'b'), 並把下一次的查詢版本更新到最新的數據版本
insert overwrite dest select * from tt2_stream;
insertinto tt2 values (3, 'c'), (4, 'd');
//自動查詢出來新增的兩條記錄(3, 'c'), (4, 'd')
insert overwrite dest select * from tt2_stream;
增量查詢處理過程簡介
SQL引擎接收到用戶側輸入的增量查詢語法後，會先從Meta服務中解析出來要查詢的歷史增量數據版本，然後過濾出來要讀取的Delta file列表，進行合併merge輸出。
結合上圖示例進一步描述查詢細節：
- 圖中表tt2 Schema包含一個pk列和一個val列。左邊圖展示了數據變化過程，t1 - t5代表了5個事務的時間版本，分別執行了5次數據寫入操作，生成了5個Delta file，在t2和t4時刻分別執行了Compact操作，生成了兩個Compacted File: c1和c2。
- 在具體的查詢示例中，例如，begin是t1-1，end是t1，只需讀取t1時間段對應的Delta file (d1)進行輸出; 如果end是t2，會讀取兩個Delta files (d1, d2)；如果begin是t1，end是t2-1，即查詢的時間範圍爲（t1, t2），這個時間段是沒有任何增量數據插入的，會返回空行。
- Compact / Merge服務生成的數據(c1, c2)不會作爲新增數據重複輸出。
PK 點查 DataSkipping 優化
上文提到，TT2表的數據分佈和索引基本是按照PK列值進行構建的，因此如果對TT2表進行點查，並指定了PK值進行過濾的話，將會極大減少要讀取的數據量和讀取耗時，資源消耗可能也會成百上千倍的減少。比如，TT2表總的數據記錄是1億，經過過濾後真正從數據文件中讀取的數據記錄可能只有一萬條。
主要的DataSkipping優化包括:
- 先進行Bucket裁剪，只讀取包含指定PK值的一個bucket即可；
- 在Bucket內部進行數據文件裁剪，只讀取包含指定PK值的文件即可；
- 在文件內部進行Block裁剪，根據Block的PK值域範圍進行過濾，只讀取包含指定PK值的block即可。
遵循常規的SQL查詢語法，簡單示例:
select * from tt2 where pk = 1;
SQL查詢分析Plan優化
由於TT2表數據按照PK值進行分桶分佈的，並且桶內部數據查詢出來具備Unique屬性和Sort有序性，因此SQL Optimizer利用這些屬性可以做大量的優化。
比如圖中示例的SQL語句 (假設tt2_t1和tt2_t2的桶數量相同)，SQL Optimizer可做的主要優化如下:
- Distinct的PK列本身具備的Unique屬性，因此可以消除去重算子；
- Join on key和PK列相同，因此直接使用Bucket Local Join即可，消除資源消耗很重的Shuffle過程；
- 由於每個桶讀取出來的數據本身有序，因此可以直接使用MergeJoin算法，消除前置的Sort算子。
這些消除的算子都極爲消耗資源，因此這些優化可整體讓性能提升1倍以上。
遵循常規的SQL查詢語法，簡單示例：
select * from (selectdistinct pk from tt2_t1) t
join (selectdistinct pk from tt2_t2) t2 on t.pk = t2.pk;
數據庫整庫實時同步寫入 MaxCompute
當前數據庫和大數據處理引擎都有各自擅長的數據處理場景，部分複雜的業務場景同時需要OLTP/OLAP/離線分析引擎對數據進行分析處理，因此數據也需要在各個引擎之間流動。將數據庫的單表或者整庫的變更記錄實時同步到MaxCompute進行分析處理是目前比較典型的業務鏈路。
如上圖所示，左邊流程是之前MaxCompute支持此類場景的典型ETL處理鏈路，按照小時/天級別讀取數據庫的變更記錄寫入到MaxCompute一張臨時的增量表中，然後將臨時表和存量的全量表進行Join Merge處理，生成新的全量數據。此鏈路較複雜，並且延時較長，也會消耗一定的計算和存儲成本。
右邊流程則是使用新架構支持該場景，直接按照分鐘級別實時讀取數據庫的變更記錄upsert寫入到TT2表即可。鏈路極簡單，數據可見降低到分鐘級，只需要一張TT2表即可，計算和存儲成本降到最低。
目前MaxCompute集成了兩種方式支持該鏈路：
- 通過DataWorks數據集成的整庫/單表增全量實時同步任務，在頁面進行任務配置即可。
優勢
MaxCompute離線&近實時數倉一體化新架構會盡量覆蓋部分近實時數據湖(HUDI/ICEBERG等)的通用功能，此外，作爲完全自研設計的新架構，在低成本，功能，性能，穩定性，集成等方面也具備很多獨特亮點：
- 用MaxCompute較低的成本來支持近實時以及增量鏈路，具備很高的性價比。
- 統一的存儲、元數據、計算引擎一體化設計，做了非常深度和高效的集成，具備存儲成本低，數據文件管理高效，查詢效率高，並且Time travel / 增量查詢可複用MaxCompute批量查詢的大量優化規則等優勢。
- 通用的全套SQL語法支持所有功能，非常便於用戶使用。
- 深度定製優化的數據導入工具，高性能支持很多複雜的業務場景。
- 無縫銜接MaxCompute現有的業務場景，可以減少遷移、存儲、計算成本。
- 表數據後臺智能自動化治理和優化，保證更好的讀寫穩定性和性能，自動優化存儲效率和成本。
- 基於MaxCompute平臺完全託管，用戶可以開箱即用，沒有額外的接入成本，功能生效只需要創建一張TT2表即可。
- 作爲完全自研的架構，需求開發節奏完全自主可控。
本文爲阿里雲原創內容，未經允許不得轉載。