前言

本文翻譯自大數據技術公司 Databricks 針對數據湖 Delta Lake 系列技術文章。眾所周知，Databricks 主導著開源大數據社區 Apache Spark、Delta Lake 以及 ML Flow 等眾多熱門技術，而 Delta Lake 作為數據湖核心存儲引擎方案給企業帶來諸多的優勢。

此外，阿里雲和 Apache Spark 及 Delta Lake 的原廠 Databricks 引擎團隊合作，推出了基於阿里雲的企業版全託管 Spark 產品——Databricks 數據洞察，該產品原生集成企業版 Delta Engine 引擎，無需額外配置，提供高性能計算能力。有興趣的同學可以搜索` Databricks 數據洞察`或`阿里雲 Databricks `進入官網，或者直接訪問 https://www.aliyun.com/product/bigdata/spark 瞭解詳情。

譯者：韓宗澤（棕澤），阿里雲計算平臺事業部技術專家，負責開源大數據生態企業團隊的研發工作。

Delta Lake技術系列 - 基礎和性能（Fundamentals and Performance）

——使用Delta Lake為機器學習和商業智能提供可靠的數據保障

Chapter-01 Delta Lake 基礎：為什麼可靠性和性能很重要？
Chapter-02 深入理解事務日誌（Transaction Log）
Chapter-03 如何使用 Schema 約束（Schema Enforcement）和演變（Schema Evolution）
Chapter-04 Delta Lake DML 語法
Chapter-05 在 Delta Lake 中使用 Data Skipping 和 Z-Ordering 來快速處理PB級數據

本文介紹內容

Delta Lake 系列電子書由 Databricks 出版，阿里雲計算平臺事業部大數據生態企業團隊翻譯，旨在幫助領導者和實踐者瞭解 Delta Lake 的全部功能以及它所處的場景。在本文中，Delta Lake 系列-基礎和性能（Fundamentals and performance），重點介紹 Delta Lake 的基礎及性能。

後續

讀完本文後，您不僅可以瞭解 Delta Lake 提供了什麼特性，還可以理解這些的特性是如何帶來實質性的性能改進的。

什麼是 Delta Lake？

Delta Lake 是一個統一的數據管理系統，為雲上數據湖帶來數據可靠性和快速分析。 Delta Lake 運行在現有數據湖之上，並且與 Apache Spark 的 API 完全兼容。

在 Databricks，我們看到了 Delta Lake 如何為數據湖帶來可靠性、性能和生命週期管理。我們的客戶已經證明，Delta Lake 解決了以下難題：從複雜的數據格式中提取數據的挑戰、刪除數據以實現法規遵從性的困難、以及為數據捕獲進行修改數據所帶來的問題。

使用 Delta Lake，您可以加快高質量數據導入數據湖的速度，團隊也可以在雲服務上快速使用這些數據，安全且可擴展。

Chapter-01 Delta Lake 基礎：為什麼可靠性和性能很重要？

提到數據可靠性，性能（程序運行的速度）是其中最重要的指標。由於 Delta Lake 提供的 ACID 事務性保護，您可以獲得所需的可靠性和性能。

使用 Delta Lake，您可以同時進行流式和批處理作業（我們稱為批流一體）、執行 CRUD（對數據的增刪改查）操作，從而節省您的資金——因為您現在使用的 vm 相比之前更少了。通過使用批流一體架構，使得維護您數據工程的 data pilelines 會變得非常輕鬆。

Delta Lake 是一個存儲層，它通過在寫操作間進行樂觀鎖控制和快照隔離技術，來提供 ACID 事務性，從而為基於 HDFS 和雲對象存儲（如阿里雲 OSS、AWS S3）的數據湖帶來可靠性，進而在寫操作期間可以實現一致性的數據讀取。Delta Lake 還提供了內置的數據版本控制，以方便回滾和復現。

在本章中，我們將分享數據湖的一些常見挑戰，以及 Delta Lake 是如何解決這些挑戰的。

數據湖的挑戰

數據湖是現代數據體系結構中的一個常見元素。它們通常充當大量數據的存儲中心和接收點，以使公司對數據進行收集並挖掘數據的價值。雖然隨著數據湖的演進在領域內有所發展，但數據湖通常會有以下幾點問題：

數據湖中數據的讀寫是不可靠的（Reading and writing into data lakes is not reliable）。數據工程師經常遇到這樣的問題：不安全地寫入數據湖，這會導致如果讀取數據過程中同時又有數據寫入，那麼將會產生垃圾數據。那邊必須構建其他額外的方法，來保證數據同時讀寫情況的數據一致性。

數據湖中的數據質量較低（The data quality in data lakes is low）。將非結構化數據轉儲到數據湖通常都很容易，但這是以犧牲數據質量為代價的。由於沒有任何機制來驗證Schema和數據，數據湖中的數據質量通常都會很差。那麼這會導致那些試圖挖掘這些數據的分析項目也隨之失敗了（由於數據質量低）。

持續增長的數據規模導致性能很差（Poor performance with increasing amounts of data）。隨著存儲到數據湖中的數據持續增加，文件和目錄的數量也會隨之增加。大數據作業和查詢引擎將會花費大量時間來處理元數據——這個問題在流作業或處理許多併發批處理作業的情況下更為明顯。

在數據湖中修改、更新或者刪除記錄非常困難（Modifying, updating or deleting records in data lakes is hard ）。工程師需要構建複雜的Pipeline來讀取整個分區或表，修改數據並將其寫回。這種Pipeline效率很低，而且難以維護。

由於數據湖的上述這些挑戰，許多大數據項目未能實現其願景，甚至有時項目會完全失敗。我們需要一個解決方案，使得數據從業者能夠利用好他們現有的數據湖，同時可以確保數據的質量。

Delta Lake的核心能力

Delta Lake 簡化了構建數據湖的方式，並解決了上述問題。Delta Lake提供以下關鍵功能：

ACID 事務性：Delta Lake 在多個寫操作之間提供 ACID 事務性。每一次寫操作都是一個事務操作，事務日誌（Transaction Log）中記錄的寫操作都有一個順序序列。事務日誌（Transaction Log）跟蹤了文件級別的寫操作，並使用了樂觀鎖進行併發控制，這非常適用於數據湖，因為嘗試修改相同文件的多次寫操作的情況並不經常發生。當發生衝突時，Delta Lake 會拋出一個併發修改異常，拋給供用戶處理並重試其作業。Delta Lake 還提供了最高級別的隔離（可序列化隔離），允許工程師不斷地向目錄或表寫入數據，而使用者不斷地從同一目錄或表讀取數據，讀取數據時會看到數據的最新快照。

Schema 管理（Schema management）：Delta Lake 會自動驗證正在寫入的 DataFrame 的 Schema 是否與表的 Schema 兼容。若表中存在但 DataFrame 中不存在的列則會被設置為 null。如果 DataFrame 中有額外的列不在表中，那麼該操作將會拋出異常。Delta Lake 具有 DDL（數據定義語言）顯式添加新列的功能，並且能夠自動更新 Schema。

可伸縮的元數據（Metadata）處理：Delta Lake 將表或目錄的元數據信息存儲在事務日誌（Transaction Log）中，而不是元數據 Metastore 中。這使得 Delta Lake 夠在固定時間內列出大目錄中的文件，並且在讀取數據時效率很高。

數據版本控制和時間旅行（Time Travel）：Delta Lake 允許用戶讀取表或目錄的歷史版本快照。當文件在寫入過程中被修改時，Delta Lake 會創建文件的新的版本並保留舊版本。當用戶想要讀取表或目錄的較舊版本時，他們可以向 Apach Spark 的 read API 提供時間戳或版本號，Delta Lake 根據事務日誌（Transaction Log）中的信息來構建該時間戳或版本的完整快照。這非常方便用戶來複現實驗和報告，如果需要，還可以將表還原為舊版本。

統一批流一體：除了批處理寫入之外，Delta Lake 還可以作為 Apache Spark 的結構化流的高效流接收器（Streaming Sink）。與 ACID 事務和可伸縮元數據處理相結合，高效的流接收器（Streaming Sink）支持大量近實時的分析用例，而無需維護複雜的流和批處理管道。

記錄更新和刪除：Delta Lake 將支持合併、更新和刪除的DML（數據管理語言）命令。這使得工程師可以輕鬆地在數據湖中插入和刪除記錄，並簡化他們的變更數據捕獲和 GDPR（一般數據保護條例）用例。由於 Delta Lake 在文件級粒度上進行跟蹤和修改數據，因此它比讀取和覆蓋整個分區或表要高效得多。

數據期望（Data expectations，即將推出）：Delta Lake 還將支持一個新的 API 來設置表或目錄的數據期望。工程師將能夠指定一個布爾條件並調整參數以處理數據的期望。當 Apache Spark 作業寫入表或目錄時，Delta Lake 將自動驗證記錄，當發生衝突時，它將根據提供的嚴重性處理記錄。

Chapter-02 深入理解事務日誌（Transaction Log）

事務日誌（Transaction Log）是理解 Delta Lake 的關鍵，因為它是許多最重要功能的基礎，包括 ACID 事務、可伸縮的元數據處理、時間旅行等等。Delta Lake 事務日誌是自 Delta Lake 表創建以來在其上執行的所有事務的有序記錄。

Delta Lake 構建在 Apache Spark 之上，允許用戶在特定的表上同時進行併發的讀寫操作。為了隨時向用戶顯示正確的數據視圖，事務日誌（Transaction Log）充當了唯一的真實來源：跟蹤用戶對錶所做的所有更改的中央存儲。

當用戶第一次讀取 Delta Lake 表或對自上次讀取以來已修改的表運行新查詢時，Spark將檢查事務日誌（Transaction Log），以查看哪些新事務已發佈到該表。然後，Spark 用這些新的更改來更新最終用戶的表。這可以確保用戶版本的表始終與主記錄在最近一次查詢時保持同步，並且用戶不能對錶進行有分歧的、有衝突的更改。

在本章中，我們將探討 Delta Lake 事務日誌（Transaction Log）如何為多個併發讀寫的問題提供一個優雅的解決方案。

實現原子性以保證操作的完全性

原子性是 ACID 事務的四個屬性之一，它保證對數據湖執行的操作（如插入或更新數據）要麼完全完成，要麼根本不完成。如果沒有這個屬性，硬件故障或軟件錯誤很容易導致數據只部分寫入表，從而導致數據混亂或損壞。

事務日誌（Transaction Log）是 Delta Lake 提供原子性保證的機制。不管怎麼說，事務日誌中不存在的記錄，它就永遠不會發生。Delta Lake 事務日誌（Transaction Log）只記錄完全執行的事務，並將該記錄用作唯一的真實來源，因此用戶可以在 PB 級的數據進行推理，並確保基本的數據可信度。

處理多個併發讀寫

但是Delta Lake如何處理多個併發讀寫呢？由於 Delta Lake 是由 Apache Spark 提供支持的，因此需要能夠支持讓多個用戶同時修改一個表——這是所期待的的能力。為了處理這些情況，Delta Lake 採用了樂觀鎖併發控制。

樂觀鎖併發控制是一種處理併發事務的方法，它假定了不同用戶對錶所做的更改可以在不發生衝突的情況下完成。它的速度非常快，因為在處理數 PB 級別數據時，用戶很可能同時處理著數據的不同部分，從而允許他們同時完成不衝突的事務。

當然，即使使用樂觀併發控制，有時用戶也會嘗試同時修改數據的相同部分。幸運的是，Delta Lake 有一個協議，Delta Lake 通過實施互斥規則來處理這些 case，然後它試圖樂觀地解決任何衝突。

這個協議允許 Delta Lake 提供 ACID 隔離原則，這確保了在多個併發寫操作之後，表的結果狀態與這些寫操作彼此隔離地連續發生時的狀態相同。

由於在 Delta Lake 表上進行的所有事務都直接存儲到磁盤上，因此這個過程滿足 ACID 的耐用性屬性，這意味著即使在系統發生故障的情況下，它也將持續存在。

時間旅行（Time travel）、數據沿襲（Data Lineage）和調試（Debugging）

每個表都是 Delta Lake 事務日誌（Transaction Log）中記錄的所有提交的總和的結果——不多也不少。事務日誌（Transaction Log）提供了一個分步指導，詳細說明了如何從表的原始狀態到當前狀態。

因此，我們可以從原始表開始，在任何時間點重新創建表的狀態，並且只處理在該時間點之後進行的提交。這種強大的能力被稱為“時間旅行（Time travel）”，或數據版本控制，在很多情況下都可以成為救命稻草。有關更多信息，請參閱文章「為大規模數據湖引入 Delta 時間旅行」（https://databricks.com/blog/2019/02/04/introducing-delta-time-travel-for-large-scale-data-lakes.html）和「利用 Delta Lake 和 MLflow 為數據科學做好數據準備」（https://www.youtube.com/watch?v=hQaENo78za0&list=PLTPXxbhUt-YVPwG3OWNQ-1bJI_s_YRvqP&index=21&t=112s）。

Delta Lake 事務日誌（Transaction Log）是對錶所做的每一次更改的最終記錄，它為用戶提供了一個可驗證的數據譜系，對於治理、審計和法規遵從性非常有用。它還可以用於跟蹤管道中的意外更改或錯誤的根源，以找到導致錯誤的確切操作。用戶可以運行 DESCRIBE HISTORY 命令來查看所做更改的相關元數據信息。

想進一步瞭解 Delta Lake 的事務日誌嗎？您可以閱讀我們的博客（https://databricks.com/blog/2019/08/21/diving-into-delta-lake-unpacking-the-transaction-log.html），或者觀看我們的技術講座（https://databricks.com/discover/diving-into-delta-lake-talks/unpacking-transaction-log）。

Chapter-03 如何使用Schema約束（Schema Enforcement）和演變（Evolution）

隨著業務問題和需求的發展，數據的結構也在不斷變化。在 Delta Lake 中，合併新的列或對象是很容易的，用戶可以訪問簡單的語義來控制其表的 Schema。同時，重要的是要強調 Schema 約束的重要性，以防止用戶在 Schema 演變過程中意外地用錯誤或垃圾數據汙染他們的表，這使他們能夠自動添加新的數據列。

Schema 約束（Schema Enforcement）拒絕任何不兼容表的新增和修改操作。通過設置和維護這些更高的標準，分析師和工程師可以相信他們的數據具有最高級別的完整性，從而可以清晰地進行推理，使他們能夠做出更好的業務決策。

另一方面，Schem 演變（Schema Evolution）通過使預期的 Schema 更改易自動發生。畢竟，添加一個列應該不難。

Schema 約束（Schema Enforcement）和 Schema 演變（Schema Evolution）是互補的能力。當這些功能結合使用時，比以往任何時候都更容易得到好的效果。

理解表的 Schema

Apache Spark 中的每個 DataFrame 都包含一個 Schema——Schema 定義了數據的描述（如數據類型和列）和藍圖、以及元數據信息。在 Delta Lake 中，表的 Schema 以 JSON 格式保存在事務日誌中。

什麼是 Schema 約束（Schema Enforcement）？

Schema 約束（Schema enforcement，或 Schema validation）是 Delta Lake 中的一種保護措施，它通過拒絕對與表的 Schema 不匹配的寫入操作，來保證數據質量。

就像繁忙餐廳的前臺經理只接受預訂一樣，它檢查插入表中的每一列數據是否在其預期列的列表中（換句話說，每一列是否都有“預訂”），並拒絕任何不在列表中的列的寫入。

Schema 約束（Schema Enforcement）是如何工作的？

Delta Lake 使用寫時 Schema 校驗，這意味著在寫入時檢查對錶的所有新寫入是否與目標表的 Schema 兼容。如果 Schema 不兼容，Delta Lake 將完全取消事務，不寫入任何數據，並拋出異常以讓用戶知道表結構不匹配。

為了確定對錶的寫入是否兼容，Delta Lake 使用以下規則。要寫入的 DataFrame 不能包含：

目標表結構中不存在的任何其他列。相反，如果傳入的數據不包含表中的列，則沒有問題——這些列將被簡單地分配 null 值。

與目標表中的列數據類型不同的列數據類型。如果目標表的列包含 StringType 數據，但 DataFrame 中的相應列包含 IntegerType 數據，則架構強制將引發異常並阻止執行寫操作。

只有大小寫不同的列名。這意味著不能在同一個表中定義名為“Foo”和“foo”的列。雖然 Spark 可以在區分大小寫或不區分大小寫（默認）Schema 下使用，但是 Delta Lake 保留大小寫，但在存儲 Schema 時不區分大小寫。在存儲和返回列信息時，Parquet 區分大小寫。為了避免潛在的錯誤、數據損壞或丟失問題（這是我們在 Databricks 親身經歷的），我們決定添加這個限制。

Delta Lake 不是自動添加新的列，而是強制執行 Schema，並停止寫入。為了幫助識別導致不匹配的列，Spark 打印出堆棧來跟蹤兩個 Schema 以進行比較。

Schema 約束起到什麼作用呢？

因為這是一個非常嚴格的檢查，所以 Schema 約束是一個很好的工具，可以用作一個乾淨的、完全轉換的數據集的網關，該數據集可以用於生產或消費。通常在結果數據的表上強制執行：

機器學習算法
BI 儀表盤
數據分析和可視化工具
任何需要高度結構化、強類型、語義 Schema 的生產系統

為了為這最後一個障礙準備數據，許多用戶採用了一種簡單的多跳架構，該架構可以逐步地向表中添加結構。要了解更多信息，請查看「基於 Delta Lake 的機器學習」（https://databricks.com/blog/2019/08/14/productionizing-machine-learning-with-delta-lake.html）。

什麼是 Schema 演變？

Schema 演變是一種允許用戶輕鬆更改表的當前 Schema 以適應隨時間變化的數據的功能。最常見的是，在執行追加或覆蓋操作時使用它來自動調整 Schema 以包含一個或多個新增列。

Schema 演變是如何工作的？

繼上一節中的示例之後，開發人員可以輕鬆地使用 Schema 演變來添加以前由於 Schema 不匹配而被拒絕的新列。通過使用 Spark .write 或 . writeStream 命令的 .option（'mergeSchema'，'true'） ，可以觸發 Schema 演變，如下例所示。

#Add the mergeSchema option 
loans.write.format(“delta”) \ 
.option(“mergeSchema”, “true”) \ 
.mode(“append”) \ 
.save(DELTALAKE_SILVER_PATH)

通過在查詢中包含 mergeSchema 選項，DataFrame 中存在但目標表中不存在的任何列都會作為寫事務的一部分自動添加到 Schema 的末尾。也可以添加嵌套字段，這些字段也將添加到各自結構列的末尾。

數據工程師和科學家可以使用這個選項向他們現有的 ML 生產表中添加新的列（可能是一個新跟蹤的指標，或者本月銷售數據的一列），且不會破壞依賴於舊列的現有模型。

在表追加或覆蓋期間，以下類型的架構更改符合 Schema 演變的條件：

添加新列（這是最常見的場景）
從 NullType->any other type 更改數據類型，或從 ByteType->ShortType->IntegerType 升級數據類型

其他不符合 Schema 演變條件的更改要求通過添加 .option（“overwriteSchema”，“true”） 覆蓋 Schema 和數據。這些變化包括：

刪除列
更改現有列的數據類型（就地）
重命名僅區分大小寫的列名（例如，“Foo”和“foo”）

最後，隨著 Spark 3.0 的發佈，完全支持顯式 DDL（使用ALTER TABLE），允許用戶對錶 Schema 執行以下操作：

添加列
更改列註釋
設置定義錶行為的表屬性，例如設置事務日誌的保留期限

Schema 演變起到什麼作用呢？

無論何時，只要您打算更改表的 Schema，就可以使用 Schema 演變（而不是意外地將不應該存在的列添加到 DataFrame 中）。這是遷移 Schema 的最簡單方法，因為它自動添加正確的列名和數據類型，而不必顯式聲明。

總結

Schema 約束拒絕與表不兼容的任何新列或其他 Schema 更改，通過設置和維護這些高標準，分析師和工程師可以相信他們的數據具有最高級別的完整性，並且可以清晰地進行推理，從而使他們能夠做出更好的業務決策。

另一方面，Schema 演變通過使預期的 Schema 更改輕鬆自動化。畢竟，添加一個列應該不難。

Schema 約束（Schema Enforcement）和 Schema 演變（Schema Evolution）是互補的能力。當這些功能結合使用時，比以往任何時候都更容易得到好的效果。

Chapter-04 Delta Lake DML（數據操作語言）

Delta Lake 支持數據操作語言（DML）命令，包括更新（UPDATE）、刪除（DELETE）和合並（MERGE）。這些命令簡化了數據變更（CDC）、審計和治理，以及GDPR/CCPA 等工作流程。

在本章中，我們將演示如何使用這些 DML 命令，來描述 Delta Lake 在幕後所做的工作，併為每一個命令提供一些性能調優技巧。

Delta Lake DML：UPDATE

可以使用 UPDATE 操作來有選擇地更新與過濾條件匹配（也稱為謂詞）的任何行。下面的代碼演示瞭如何將每種類型的謂詞用作來 UPDATE。請注意，Delta Lake 提供了 Python、Scala 和 SQL 的 API，但在本電子書中，我們只包含 SQL 代碼。

-- Update events
UPDATE events SET eventType=‘click’ WHERE buttonPress = 1

更新（UPDATE）：底層原理

Delta Lake 分兩步對錶執行 UPDATE：

查找並選擇包含與謂詞匹配的數據的文件，這些文件是需要更新的。Delta Lake 儘可能使用 Data Skipping 來加速這個過程。
將每個匹配文件讀入內存，更新相關行，並將結果寫入新的數據文件。

一旦 Delta Lake 成功地執行了 UPDATE 操作，它就會在事務日誌中添加一個 commit，表示從現在起將使用新的數據文件代替舊的數據文件。不過，舊數據文件並不會被刪除。相反，它只是簡單的“邏輯刪除”——會記錄為應用於表的舊版本的數據文件，而不是當前版本的數據文件。Delta Lake 能夠使用這個邏輯來提供數據版本控制（Version control）和時間旅行（Time travel）。

UPDATE + Delta Lake Time Travel = 易於Debugging

保留舊數據文件對於調試 debug 非常有用，因為您可以使用 Delta Lake “時間旅行”隨時返回並查詢表的早期版本。如果您錯誤地更新了表，並且想知道發生了什麼，您可以很容易地將一個表的兩個版本相互比較，以查看發生了什麼變化。

SELECT * FROM events VERSION AS OF 11 EXCEPT ALL SELECT
* FROM mytable VERSION AS OF 12

UPDATE：性能優化 tips

優化 Delta Lake 中 UPDATE 命令性能的主要方法是，添加更多謂詞以縮小搜索空間（精確更新數據的範圍）。搜索越具體，Delta Lake 需要掃描或修改的文件就越少。

Delta Lake DML：DELETE

可以使用 DELETE 命令根據謂詞（過濾條件）有選擇地刪除行。

DELETE FROM events WHERE date < ‘2017-01-01’

如果要還原意外的刪除操作，可以使用時間旅行將表回滾到原來的狀態。

刪除（DELETE）：底層原理

刪除（DELETE）如更新（UPDATE）原理類似。Delta Lake 對數據進行兩次掃描：第一次掃描是識別包含與謂詞條件匹配的行的任何數據文件，第二次掃描將匹配的數據文件讀入內存，此時 Delta Lake 會在將新的數據寫入磁盤之前刪除所選行。

Delta Lake 成功完成刪除操作後，舊數據文件不會被完全刪除——它們仍保留在磁盤上，但在 Delta Lake 事務日誌中記錄為“tombstoned”（不再是活動表的一部分）。

請記住，Delta Lake 不會立即刪除這些舊文件，因為您可能仍然需要它們時間旅行回到表的早期版本。如果要刪除超過某個時間段的文件，可以使用 VACUUM 命令。

刪除（DELETE）+ VACUUM：清理舊的數據文件

運行 VACUUM 命令將永久刪除以下所有數據文件：

已不再是當前表的部分數據，並且：
早於保留閾值，默認為7天

Delta Lake 不會自動清空舊文件——您必須自己運行命令清除，如下所示。如果要指定不同於默認七天的保留期，可以將其作為參數提供。

from delta.tables import * deltaTable.
# vacuum files older than 30 days(720 hours)
deltaTable.vacuum(720)

刪除（DELETE）：性能優化tips

與 UPDATE 命令一樣，優化 Delta Lake 上 DELETE 操作性能的主要方法是，添加更多謂詞以縮小搜索空間。Delta Lake 的 Databricks 管理版本（Databricks Runtime 企業版）還具有其他性能增強功能，如改進的 Data Skipping、bloom 過濾器和 Z-Order 優化（多維集群）。

Delta Lake DML: MERGE

Delta Lake MERGE 命令允許您執行 Upserts，這是更新（UPDATE）和插入（INSERT）的混合操作。要理解 Upserts，假設您有一個當前表（也稱為目標表）和一個源表，其中包含新記錄和對現有記錄的更新。

下面是 upsert 的工作原理：

當源表中的記錄與目標表中預先存在的記錄匹配時，Delta Lake 會更新該記錄。
如果沒有這樣的匹配，Delta Lake 將插入新記錄。

Delta Lake MERGE 命令極大地簡化了工作流程，這些工作流程與其他傳統數據格式（如Parquet）相比可能非常複雜和繁瑣。合併（MERGE）和升級（Upserts）帶來便利的常見場景包括更改數據捕獲、GDPR/CCPA 遵從性、會話化和記錄的重複數據消除。

MERGE：底層原理

Delta Lake 分兩步完成 MERGE 操作：

在目標表和源表之間執行內部聯接，以選擇所有匹配的文件。
在目標表和源表中的選定文件之間執行外部聯接，並寫出更新（UPDATE）/刪除（DELETE）/插入（INSERT）的數據。

這與更新或刪除不同的主要方式是，Delta Lake 使用連接（Join）來完成合並，這一事實允許我們在性能優化時使用一些獨特的策略。

MERGE：性能優化 tips

為了提高 MERGE 命令的性能，您需要確定組成合並的兩個連接中的哪一個限制了您的速度。如果內部連接是瓶頸（即，查找 Delta Lake 需要重寫的文件花費的時間太長），請嘗試以下策略：

添加更多謂詞以縮小搜索空間。
調整隨機分區。
調整廣播連接閾值。
壓縮表中的小文件（如果有很多），但不要壓縮

因為 Delta Lake 必須複製整個文件才能重寫它，所以將它們轉換為太大的文件。

在 Databricks 版本的 Delta Engine（企業版 Databricks Runtime）中，使用 Z-Ordering 優化來利用更新的位置。

另一方面，如果外部連接是瓶頸（即重寫實際文件本身花費的時間太長），請嘗試以下策略。

調整隨機分區。
通過在寫入前啟用自動重新分區來減少文件（在 Databricks Delta Lake 中優化寫入）。
調整廣播閾值。如果正在執行完全外部聯接，Spark 無法執行廣播聯接，但是如果正在執行正確的外部聯接，Spark 可以執行一個，並且可以根據需要調整廣播閾值。
緩存源表 / DataFrame。
緩存源表可以加快第二次掃描，但請確保不要緩存目標表，因為這可能導致緩存一致性問題。

Delta Lake 支持 DML 命令，包括 UPDATE、DELETE 和 MERGE-INTO，這大大簡化了許多常見大數據操作的工作流。在本章中，我們演示瞭如何在 Delta Lake 中使用這些命令，分享了關於每個命令的工作原理，並提供了一些性能調優技巧。

Chapter-05 Delta Lake如何使用Data Skipping和Z-Ording快速處理PB級別數據

Delta Lake 能夠在幾秒鐘內篩選出數 PB 級數據。這種速度主要歸功於兩個特性：（1）Data Skipping和（2）Z-Ordering。

結合這些特性有助於 Databricks 運行時顯著減少需要掃描的數據量，以針對大型 Delta表的選擇性查詢，這通常轉化為運行時的顯著改進和成本節約。

使用 Delta Lake 內置的 Data Skipping 過和 Z-Ordering 集群功能，通過跳過與查詢無關的文件，可以在幾秒鐘內查詢到大型雲上數據湖數據。例如，在一個網絡安全分析用例中，對於典型的查詢，504TB數據集中93.2%的記錄被跳過，從而將查詢時間減少了兩個數量級。換句話說，Delta Lake 可以將您的查詢速度提高100倍之多。

想了解 Data Skipping 和 Z-Ordering 的實際應用嗎？

Apple 的 Dominique Brezinski 和 Databricks 的 Michael Armbrust 演示瞭如何在網絡安全監控和威脅應對的背景下，將 Delta Lake 作為數據工程和數據科學的統一解決方案。瞭解他們的主題演講：「 Threat Detection and Response at Scale」（https://databricks.com/session/keynote-from-apple）。

使用 Data Skipping 和 Z-Ordering

Data Skipping 和 Z-Ordering 被用來提升對大規模數據集的查詢性能。Data Skipping 過是 Delta Lake 的一項自動化功能，每當您的 SQL 查詢或數據集操作包含“column op literal”形式的過濾器時，就會自動跳過，其中：

column 是一些 Delta Lake 表的一個屬性，無論是頂級的還是嵌套的，其數據類型為string/numeric/date/timestamp
op 是一個二進制比較運算符，StartsWith/LIKE pattern%'，或 IN
literal 是與列具有相同數據類型的顯式（列表）值

AND/OR/NOT 以及“literal op column”謂詞也受支持。即使 Data Skipping 過在滿足上述條件時起作用，它也未必總是有效的。但是，如果有一些列是您經常篩選的，並且希望確保快速篩選，則可以通過運行以下命令顯式優化數據佈局，以跳過有效性：

OPTIMIZE [WHERE ]

ZORDER BY ( [, ...])

探索細節

除了分區裁剪之外，數據倉庫世界中使用的另一種常見技術（ Spark 目前缺乏這種技術）是基於小型物化聚合的I/O裁剪。簡言之，其思想是跟蹤與I/O粒度相關的簡單統計信息，例如特定粒度下的最小值和最大值。我們希望在查詢規劃時利用這些統計信息，以避免不必要的I/O。

這是 Delta Lake 的 Data Skipping 功能所涉及的內容。在將新數據插入 Delta Lake 表時，將收集受支持類型的所有列（包括嵌套列）的文件級最小/最大統計信息。然後，當對錶進行查找查詢時，Delta Lake 首先查詢這些統計信息，以便確定哪些文件可以安全地跳過。

想了解更多關於 Data Skipping 和 Z-Ordering 的信息，包括如何在網絡安全分析中應用它嗎？閱讀我們的博客>（https://databricks.com/blog/2018/07/31/processing-petabytes-of-data-in-seconds-with-databricks-delta.html）

後續

您已經瞭解了 Delta Lake 及其特性，以及如何進行性能優化，本系列還包括其他內容：

Delta Lake 技術系列-特性
Delta Lake 技術系列-Lakehouse
Delta Lake 技術系列-Streaming
Delta Lake 技術系列-客戶用例（Use Case）

獲取更詳細的 Databricks 數據洞察相關信息，可至產品詳情頁查看：

https://www.aliyun.com/product/bigdata/spark

阿里巴巴開源大數據技術團隊成立 Apache Spark 中國技術社區，定期推送精彩案例，技術專家直播，只為營造純粹的 Spark 氛圍，歡迎關注公眾號！

掃描下方二維碼入 Databricks 數據洞察產品交流釘釘群一起參與交流討論！

前言