DeltaLake簡介

Delta Lake 是 DataBricks 公司開源的、用於構建湖倉架構的儲存框架。能夠支援 Spark，Flink，Hive，PrestoDB，Trino 等查詢/計算引擎。作為一個開放格式的儲存層，它在提供了批流一體的同時，為湖倉架構提供可靠的，安全的，高效能的保證。

Delta Lake 關鍵特性：

1. ACID事務：通過不同等級的隔離策略，Delta Lake 支援多個 pipeline 的併發讀寫；
2. 資料版本管理：Delta Lake 通過 Snapshot 等來管理、審計資料及後設資料的版本，並進而支援 time-travel 的方式查詢歷史版本資料或回溯到歷史版本；
3. 開原始檔格式：Delta Lake 通過 parquet 格式來儲存資料，以此來實現高效能的壓縮等特性；
4. 批流一體：Delta Lake 支援資料的批量和流式讀寫；
5. 後設資料演化：Delta Lake 允許使用者合併 schema 或重寫 schema，以適應不同時期資料結構的變更；

6. 豐富的DML：Delta Lake 支援 Upsert，Delete 及 Merge 來適應不同場景下使用者的使用需求，比如 CDC 場景；

檔案結構

湖表較於普通 Hive 表一個很大的不同點在於：湖表的後設資料是自管理的，儲存於檔案系統。下圖為 Delta Lake 表的檔案結構。

Delta Lake 的檔案結構主要有兩部分組成：

• _delta_log目錄：儲存 deltalake 表的所有後設資料資訊，其中：

• 每次對錶的操作稱一次 commit，包括資料操作（Insert/Update/Delete/Merge）和後設資料操作（新增新列/修改表配置），每次 commit 都會生成一個新的 json 格式的 log 檔案，記錄本次 commit 對錶產生的行為（action），如新增檔案，刪除檔案，更新後的後設資料資訊等；

• 預設情況下，每10次 commit 會自動合併成一個 parquet 格式的 checkpoint 檔案，用於加速後設資料的解析，及支援定期清理歷史的後設資料檔案；

• 資料目錄/檔案：除 _delta_log 目錄之外的即為實際儲存表資料的檔案；需要注意：

• DeltaLake 對分割槽表的資料組織形式同普通的 Hive 表，分割槽欄位及其對應值作為實際資料路徑的一部分；
• 並非所有可見的資料檔案均為有效的；DeltaLake 是以 snapshot 的形式組織表，最新 snopshot 所對應的有效資料檔案在 _delta_log 後設資料中管理；

後設資料機制

Delta Lake 通過 snapshot 來管理表的多個版本，並且支援對歷史版本的 Time-Travel 查詢。不管是查詢當前最新的 snapshot 還是歷史某版本的 snapshot 資訊，都需要先解析得到對應 snapshot 的後設資料資訊，主要涉及到：

• 當前 DeltaLake 的讀寫版本協議（Protocol）；
• 表的欄位資訊和配置資訊（Metadata）;
• 有效的資料檔案列表；這一點通過一組新增檔案（AddFile）和刪除檔案（RemoveFile）來描述；

那在載入具體 snopshot 時，為了加速載入流程，先嚐試找到小於或等於該版本的 checkpoint 檔案，然後結合其後直到當前版本的 log 檔案，共同解析得到後設資料資訊。

EMR DeltaLake

阿里雲EMR團隊從19年就開始跟進 DeltaLake 社群，並將其落地在 EMR 的商業產品中的。期間，在迭代功能，優化效能，融合生態，降低易用性，場景落地等方面，不斷打磨升級 DeltaLake，使之更好的融入 EMR 產品，方便客戶使用。

以下表格彙總了 EMR DeltaLake 較開源 DeltaLake（社群1.1.0）對比的主要自研特性。

特別說明：

DeltaLake1.x 版本僅支援 Spark3，且繫結具體 Spark 版本，導致部分新功能/優化不能在老的版本及 Spark2 上使用，而 EMR DeltaLake 保持 Spark2 的 DeltaLake（0.6）和 Spark3 的 DeltaLake（1.x）的功能特性同步；

與 DLF 的深度整合

DLF（Data Lake Formation）是一款全託管的快速幫助使用者構建雲上資料湖及 LakeHouse 的服務，為客戶提供了統一的後設資料管理、統一的許可權與安全、便捷的資料入湖能力以及一鍵式資料探索能力，無縫對接多種計算引擎，打破資料孤島，洞察業務價值。

EMR DeltaLake 與 DLF 深度整合，使 DeltaLake 表建立寫入後自動完成後設資料同步到 DLF 的 metastore，避免了像開源版本那樣，需要使用者再自行建立 Hive 外表關聯 DeltaLake 表的操作。同步後，使用者可以直接通過 Hive、Presto、Impala，甚至阿里雲MaxCompute 及 Hologres 查詢，無需任何其他額外操作。

同樣 DLF 具備成熟的入湖能力，使用者可以通過產品端的配置將 Mysql、RDS、Kafka 的資料直接同步生成 DeltaLake 表。

在 DLF 的產品側，湖格式 DeltaLake 作為第一公民，DLF 也將在接下來的迭代中針對性的提供易用的視覺化展示，和湖表管理的能力，幫助使用者更好的維護湖表。

G-SCD 解決方案

Slowly Changing Dimension（SCD）即緩慢變化維，被認為是跟蹤維度變化的關鍵ETL任務之一。在數倉場景下，通常使用星型模型來關聯事實表和維度表。如果維度表中的某些維度隨時間更新，那麼如何儲存和管理當前和歷史的維度值呢？是直接忽略，還是直接覆蓋，亦或者其他的處理方式，如永久儲存歷史所有的維度值。根據不同的處理方式，SCD 定義了多種型別，其中 SCD Type2 通過增加新記錄的方式保留所有的歷史值。

在實際的生產環境中，我們可能不需要關注所有的歷史維度值，而關注在固定的時間段內最新的值，比如以天或者小時為粒度，關注在每一天或者小時內某個維度的值。因此實際的場景可以轉化為基於固定粒度（或業務快照）的緩慢變化維（ Based-Granularity Slowly Changing Dimension，G-SCD ）。

在傳統數倉基於 Hive 表的實現，有幾種方式可選，以下列舉兩個解決方案：

• 流式構建T+1時刻的增量資料表，和離線表的T時刻分割槽資料做合併，生成離線表T+1分割槽。其中T表示粒度或業務快照。不難想象該方案每個分割槽儲存了全量的資料，會造成大量的儲存資源浪費；

• 儲存離線的基礎表，每個業務時刻的增量資料獨立儲存，在查詢資料時合併基礎表和增量表。該方案會降低查詢效率。

通過對 DeltaLake 自身的升級，結合對 SparkSQL，Spark Streaming 的適配，我們實現了 SCD Type2 場景。架構如下：

同樣對接上游的 Kafka 的資料，在 Streaming 端按照配置的業務快照粒度將 Batch資料進行切分，分別 commit，並附帶業務快照的值。DeltaLake 在接收到資料後，儲存當前 snapshot 和業務快照的關係。並在下一個業務快照到達時，對前一個 snapshot 做 savepoint，永久保留該版本。使用者查詢時，通過指定的業務快照的具體值，識別到具體的 snapshot，然後通過 time-travel 的方式實現查詢。

G-SCD on DeltaLake 方案優勢：

• 流批一體：不需要增量表和基礎表兩張表；
• 儲存資源：藉助 Delta Lake 本身的 data versioning 能力，實現增量變化維度的管理，不需要按時間粒度保留歷史全量資料；
• 查詢效能：藉助 Delta Lake 的後設資料 checkpoint，資料的 Optimize、Zorder 及 DataSkipping 的能力，提升查詢效率；
• 保留原實現的 SQL 語句：使用者依然可以像用分割槽實現快照的方式一樣，使用類似的分割槽欄位執行要查詢的業務時間粒度內的快照資料。

CDC 解決方案

在當前的數倉架構下，我們往往將資料分層為 ODS，DWD，DWS，ADS 等方便管理。原始資料如儲存在 Mysql 或者 RDS，我們可以消費其 binlog 資料實現對 ODS 表的增量更新。但，從 ODS 到 DWD，從 DWD 到 DWS 層資料呢？由於 Hive 表本身不具備生成類似 binlog 資料的能力，因此我們無法實現下游各鏈路的增量更新。而讓湖表具備生成類似 binlog 資料的能力，又是構建實時增量數倉的關鍵。

阿里雲EMR 基於 DeltaLake 實現了將其作為 Streaming Source 的 CDC 能力。開啟後，對所有的資料操作將同時生成 ChangeData 並持久化，以便下游 Streaming 讀取；同時支援 SparkSQL 語法查詢。如下圖所示：

ODS 層 Delta 表 user_city_table 接收 Source 資料執行 Merge 操作，同時將變更的資料持久化儲存；DWS 層按 city 聚合的 city_cnt_table 表讀取 user_city_table表的 ChangeData 資料，對 cnt 聚合欄位實現更新。

後續規劃

DeltaLake 作為 EMR 主推的湖格式，得到了很多客戶的信任和選擇，並落地到各自的實際生產環境，對接了多種場景。後續會繼續加強在 DeltaLake 的投入，深度發掘和 DLF 的整合，豐富湖表運維管理能力，降低使用者入湖成本；持續優化讀寫效能，完善與阿里雲大資料體系的生態建設，推進客戶湖倉一體架構的建設。