本文介紹Append Delta Table在資料群組織最佳化服務上的架構設計。
概述
Append Delta Table創新表格式的資料群組織底層採用Range Clustering結構，預設使用Row_ID作為Cluster Key，Bucket數量會隨著使用者資料增長動態分配。在使用者指定Cluster Key之後，後台Clustering作業會對資料執行增量Reclustering，從而保證資料的整體有序性。
Append Delta Table在複雜業務情境上表現優秀，顯著的效能提升也反映出資料存放區格式的技術最佳化在巨量資料分析情境下的核心價值。其技術價值及效能最佳化總結如下：
資料自治：通過Merge、Compaction、Reclustering等背景工作，實現儲存效率與查詢效能的動態平衡。
彈性擴充：動態Bucketing 與 Auto-Split/Merge策略，支援從TB到EB級資料的無縫擴充。
即時Clustering：增量Reclustering在ODS層實現毫秒級資料新鮮度與Clustering查詢加速。
動態Bucket最佳化（Dynamic Bucketing）
面臨挑戰
在建立Range/Hash Cluster表時，使用者需要提前評估對應業務的資料規模，以此為依據設定合適的Bucket數量和Cluster key。完成Cluster表建立後，MaxCompute通過Clustering演算法將資料按照Cluster Key路由到各自對應的Bucket中。
這可能會導致出現如下兩種情況：
資料扭曲：當資料量太多而Bucket數量太少時，會導致單個Bucket內資料量過大，在執行查詢時，對資料的裁剪效果不佳。
資料片段：反之，如果設定的Bucket數量遠遠大於業務資料量所需要的範圍，會導致每個Bucket內資料量太少而產生大量片段檔案，也會影響查詢效能。
因此，在建立表時顯示指定Bucket數量會抬升使用者的使用門檻。根據業務的資料量預設合適的Bucket數量，要求使用者同時對業務本身的使用模式和MaxCompute底層表格式都有一定的理解，然後才能夠正確使用Clustering的相關能力並最大化查詢效能收益：
面對大規模資料移轉情境，使用者需要評估每一張表的潛在業務使用規模。如果表的數量比較少，評估工作還可能通過專項推進；但是當面對成千上萬張表時，評估每一張表的資料規模會變得非常難以執行。
即使使用者對錶的資料規模在當下做了準確的評估，但是隨著業務自身的演化，實際的資料規模也會持續變化，之前適用的Bucket數量設定在未來也可能不再適用。
綜上所述，靜態Bucket數量配置無論是在大規模資料移轉情境，還是在業務快速變化的日常使用環境中，都難以做出有效支撐。更合理的方式，是平台根據使用者實際資料量大小，動態地設定所需要的Bucket數量。使用者無需感知底層的Bucket數量，一方面降低使用者的學習和使用門檻，另一方面更好地適應不斷變化的資料規模。
解決方案
Append DeltaTable表格式在設計之初就支援Bucket的動態分配，所有儲存在表中的資料都被自動劃分為Bucket，每一個Bucket都是一個邏輯上連續的儲存單元，包含500MB左右的資料。
使用者在建立和寫入資料之前，並不需要在表層面指定Bucket的數量，隨著使用者資料的持續寫入，會自動按需建立出新的Bucket。使用者並不需要擔心隨著資料量的增加或者減少，導致Bucket內資料量過大或者過小導致的資料扭曲和資料片段問題。
工作流程圖如下：
增量重聚簇（Incremental Reclustering）
面臨挑戰
Clustering是資料領域最常見的資料最佳化手段之一，Cluster Key是使用者指定的表屬性，通過排序並連續儲存使用者指定的資料欄位，當使用者查詢Cluster Key時，可以通過下推、裁剪等最佳化方式，縮小資料掃描的範圍，從而達到提升查詢效率的目的。
MaxCompute之前提供了Range/Hash Clustering兩種Clustering能力，支援通過Range或者Hash兩種方式對資料分桶，並對單個桶內的資料排序，通過對查詢過程中Bucket和單個桶內資料的裁剪，達到查詢加速的效果。如下圖所示：
問題1：資料追加代價大
Range/Hash Clustering的表能力存在一個限制是，資料必須在寫入過程中就完成資料的分桶與排序，從而達到全域有序的狀態。因此限制了資料寫入的方式，要求資料必須以插入或覆寫資料（INSERT INTO | INSERT OVERWRITE）的形式一次性寫入，在寫入完成後，如果需要再進一步追加資料，則需要將表中原有的資料全部讀取，與新增資料並集（UNION）之後再次寫入，資料追加代價非常大，效率很低。
一般來說，業務通常不會對ODS層的資料表使用Clustering，原因在於ODS層的資料比較接近原始的業務資料，通常是通過外部的採集鏈路持續匯入的，對資料匯入的效能有很高的要求，而原有Clustering表代價巨大的寫入模式無法滿足低延遲高吞吐的寫入要求。
問題2：DW層資料新鮮度延遲
因此業務側往往傾向於在DW層的表中設定Cluster Key，前一個業務日期完成資料匯入的ODS表，會在資料清洗後，匯入到新的資料相對穩定的DW層，進而加速後續的查詢業務效能。
但是這種方案帶來的問題在於，DW層資料的新鮮度上會存在一定的延遲，為了避免反覆更新DW層帶來的讀寫放大，DW層的更新通常在ODS 層資料穩定後才進行，這導致通過DW層查詢到的資料在業務日期上是存在滯後的。然而在有些情境中，業務方對查詢效能和資料新鮮度都有著非常極致的要求，希望能夠在ODS層之間實現Clustering，加速查詢ODS表資料，擷取即時資訊。
因此，原本MaxCompute提供的在寫入資料時同步執行Clustering的方案無法在資料的即時性上滿足使用者訴求。
解決方案
Append DeltaTable的增量Clustering能力，通過後台資料服務非同步執行增量Clustering，在資料匯入效能、資料即時性以及資料查詢效能上做到了最大限度的平衡。
如下圖所示，使用者通過Streaming寫入方式將資料匯入MaxCompute。寫入階段為了最大限度保障寫入延遲與吞吐，資料直接以未排序的方式落盤，被分配到Bucket中。此時由於新寫入到Bucket的資料沒有執行Clustering操作，新增Bucket在資料範圍上會和其他已經完成Clustering的 Bucket產生重疊。在執行查詢任務時，SQL 引擎對Clustered Bucket執行Bucket 裁剪，對增量Bucket則執行掃描。
MaxCompute後台資料服務持續對Bucket Overlap Depth監控，當Overlap達到特定閾值後觸發增量Reclustering，對新寫入的Bucket執行 Reclustering操作，確保使用者資料的主體部分始終維持在一個有序狀態，從而確保了整體查詢效能的穩定。