Delta Table在資料群組織最佳化上的設計 - MaxCompute

本文為您介紹Delta Table在資料群組織最佳化服務上的架構設計。

背景介紹

Delta Table是MaxCompute推出的增量資料表格式，支援分鐘級近即時增量資料匯入，高流量情境下可能會存在增量小檔案數量膨脹，過多的中間狀態冗餘等問題。為了降低儲存壓力和計算成本，提高分析執行和資料讀寫速度，MaxCompute提供了三種最佳化服務，包括小檔案合并Clustering（小檔案合并）、資料COMPACTION和資料回收。

Clustering（小檔案合并）

面臨挑戰

Delta Table支援分鐘級近即時增量資料匯入，高流量情境下可能會導致增量小檔案數量膨脹。這種情況會引發以下問題：

儲存成本高、訪問壓力大。
大量的小檔案還會引發Meta更新。
分析執行速度變慢，資料讀寫I/O效率低下。

因此需要設計合理的小檔案合并服務，即Clustering服務來自動最佳化此類情境。

解決方案

Clustering服務主要由MaxCompute內部的Storage Service來負責執行，專門解決小檔案合并的問題。Clustering並不會改變任何資料的歷史中間狀態，即不會消除任何一條記錄資料的中間歷史狀態。

工作流程

Clustering服務的整體操作流程如圖所示。

分層次合并
Clustering策略的制定主要基於典型的讀寫業務情境，會周期性地根據資料檔案的大小、數量等多個維度綜合評估，並進行分層次的合并。
1. Level 0 → Level 1：原始寫入的、最小的DeltaFile（圖中藍色資料檔案）被合并成中等大小的DeltaFile（圖中黃色資料檔案）。
2. Level 1 → Level 2：當中等大小的DeltaFile達到一定規模後，會觸發更高層級的合并，產生更大的最佳化檔案（圖中橙色資料檔案）。
避免讀寫放大
1. 大檔案隔離：體積超過一定大小的資料檔案（如Bucket3中的T8檔案）會被專門隔離處理並排除在合并之外。
2. 時間跨度限制：時間跨度過大的檔案也不會被合并，避免在進行Time Travel或者增量查詢時讀取大量不屬於此次查詢時間範圍的歷史資料。
3. 自動觸發執行：每次執行Clustering至少需要讀寫一遍資料，消耗計算和I/O資源，存在一定的讀寫放大問題。為了確保Clustering服務的高效執行，當前MaxCompute引擎能夠根據系統狀態自動觸發執行。
並發與事務性
1. 並發執行：由於資料按照BucketIndex來切分儲存，因此Clustering服務會以Bucket粒度來並發執行，大幅縮短整體已耗用時間。
2. 事務保證：Clustering服務會與Meta Service進行互動，以擷取待處理的表或分區列表。完成操作後，會將新舊資料檔案的資訊傳入Meta Service。Meta Service在此過程中起到關鍵作用，它負責進行事務衝突檢測，協調新舊檔案Meta資訊的無縫更新以及安全地回收舊資料檔案。

Compaction

面臨挑戰

Delta Table支援UPDATE和DELETE操作。這些操作通過寫入新的記錄來標記舊記錄的狀態，而非原地修改。大量此類操作會導致：

資料冗餘：中間狀態的冗餘記錄過多，增加儲存和計算成本。
查詢效率降低

因此需要設計合理的Compaction服務，以消除中間狀態並最佳化此類情境。

解決方案

Compaction會把選中的資料檔案，包含BaseFile和DeltaFile，將其中同一主鍵的多條記錄合并，消除資料的UPDATE和DELETE中間狀態，只保留最新狀態的一行記錄，最後產生新的只包含INSERT類型資料的資料檔案BaseFile。

工作流程

Compaction服務的整體操作流程如下所示。

合并DeltaFile
1. t1~t3時間段，新寫入的一批DeltaFile觸發Compaction操作，以Bucket粒度並發執行，合并產生了新的BaseFile，每個Bucket會產生新的BaseFile。
2. t4和t6時間段，又寫入了一批新的DeltaFile，再次觸發Compaction操作，將當前存在的BaseFile和新增的DeltaFile一起合并，重建一個新的BaseFile。
事務保證
Compaction服務還需要與Meta Service進行互動。其流程與Clustering類似，需要擷取需要執行此操作的表或分區的列表。執行結束後，將新舊資料檔案的資訊傳入Meta Service。其中，Meta Service負責Compaction操作的事務衝突檢測、新舊檔案Meta資訊的原子更新以及舊資料檔案的回收等工作。
執行頻率
Compaction服務通過消除記錄的歷史狀態以節省計算和儲存資源，提升全量快照查詢的效率。然而，頻繁執行Compaction需要大量計算和I/O資源，並可能導致新BaseFile佔用額外儲存，歷史DeltaFile檔案可能會被用於Time Travel查詢，不能立即刪除，將繼續產生儲存成本。
因此，應根據具體業務需求和資料特性來決定Compaction操作的執行頻率。在Update和Delete操作頻繁以及全量查詢需求高的情況下，可以考慮增加Compaction的頻率以最佳化查詢速度。

資料回收

由於Time Travel和增量查詢都會查詢資料的歷史狀態，因此Delta Table會在一定時間內保留資料的歷史版本。

回收策略：可通過表屬性acid.data.retain.hours來配置資料保留的時間範圍。如果歷史狀態資料存在的時間早於配置值，系統會開始自動回收清理，一旦清理完成，該歷史版本將無法再通過Time Travel查詢到。回收的資料主要包含動作記錄和資料檔案。
說明
對於Delta Table，如果使用者一直寫入新的DeltaFile，那永遠也刪除不了任何一個DeltaFile，因為其他的DeltaFile可能對它有狀態依賴。只有執行COMPACTION或者InsertOverwrite操作後，之後產生的資料檔案對之前的那些DeltaFile就沒有依賴了，如果超過Time Traval可查詢的時間周期後，就可以被刪除了。
強制清理：在特殊情境下，可通過PURGE命令來手動觸發強制的歷史資料清理。
自動機制：為避免因長期不執行Compaction而導致歷史資料無限增長的極端情況，MaxCompute引擎側也做了一些最佳化。後台系統會周期性地對超過Time Travel時間的BaseFile或者DeltaFile進行自動Compaction，以確保回收機制的正常運行。