怎么深入學習delta lake的事務日志

這期內容當中小編將會給大家帶來有關怎么深入學習delta lake的事務日志，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

理解delta lake的事務日志很有必要，因為其是貫穿很多特性的主線，比如ACID事務，可伸縮的元數據處理，時間旅行等特性。下面詳細探討什么是delta lake的事務日志，它在文件級別的工作方式，以及如何為并發讀寫問題提供完美的解決方案。

1. 什么是delta lake事務日志

delta lake事務日志，也叫做deltalog，是自delta lake表創建依賴，已經執行過的每個事務的有序記錄。

2. 事務日志的作用

2.1 事務日志是真理的單一來源

Delta Lake建立在Apache Spark?之上，以便實現多reader和writer同時讀寫delta lake表。Delta Lake事務日志 始終向用戶展示正確的數據視圖–記錄用戶對表所做的所有更改。

當用戶第一次讀取delta lake的表時或者在修改過的表上執行新的查詢的時候，spark會檢查事務日志，查看是否對該表有新的事務操作，假設有的話會用這些新的變更區更新用戶的目標表。這樣可以確保用戶的表版本始終與最近一次查詢的主記錄保持同步，并且確保用戶不能對表進行不同的沖突更改。

2.2 deltalake原子操作實現

ACID事務的四個屬性之一，atomicity，確保對數據湖執行的操作（例如INSERT或UPDATE）要么完全完成，要么完全終止。沒有此屬性，硬件故障或軟件錯誤很容易導致數據僅部分寫入表中，從而導致數據混亂或損壞。

事務日志是Delta Lake能夠提供原子性保證的機制。出于所有目的和目標，如果未將變更記錄在事務日志中，則變更永遠不會生效。通過僅記錄完整和完全事務行為，并將該記錄用作真相的唯一來源，Delta Lake事務日志使用戶能夠處理pb級的數據，且對信任其處理過程的可靠性。

3.事務日志工作機制

3.1 將事務日志拆分為原子提交

用戶對delta lake表的修改操作，如insert，update或者delete操作，delta lake會將該操作劃分為一系列具體的操作步驟(一個或者多個)。

a).add file 增加一個數據文件

b).remove file 刪除一個數據文件

c). update metadata  更新表的元數據，比如修改表的名稱，schema 或者分區。

d).set transaction 使用給定的ID記錄structured streaming job 提交的微批。

c).change protocol 就是切換delta lake事務日志為最新的軟協議，使其新的特性生效。

e).commit info 提交變更信息。

然后將這些操作作為有序的原子單元記錄在事務日志中。

例如，假設用戶創建一個事務以向表中添加新列，并向其中添加更多數據。Delta Lake會將事務分解為各個組成部分，一旦事務完成，請按以下cmmit將其添加到事務日志中：

• 更新元數據–修改schema，以包含新列

• 添加文件

4. 文件級別的事務日志

當用戶創建delta lake 表的時候，該表的事務日志也會自動創建，目錄是在_delta_log的子目錄。當用戶對表做變更的時候，這些變更會以有序和原子提交的形式記錄到事務日志中。每次提交都是寫為一個json文件，以000000.json開頭。對表的后續操作文件名稱會依次記錄為，000001.json,000002.json文件等等，如下：

因此，作為示例，我們可以從1.parquet和2.parquet文件取數據，添加到delta lake表中。該事務將自動添加到事務日志中，并作為commit文件000000.json保存到磁盤。接著我們也可以決定刪除這些文件并添加一個新文件（3.parquet）。這些操作將被記錄為事務日志中的下一次cmmit文件000001.json，如下所示。

這些checkpoint文件會在某個時間點保存表的整個狀態-以本機Parquet格式保存，Spark可以輕松快速地讀取它們。換句話說，checkpoint文件為Spark的reader提供了一種“捷徑”，可以完全重現表的狀態，從而使Spark可以避免重新處理可能是成千上萬個微小，效率低下的JSON文件。

為了加快速度，Spark可以運行listFrom操作以查看事務日志中的所有文件，快速跳至最新的checkpoint文件，并且僅處理自保存最新checkpoint文件以來進行的那些JSON commits。

為了演示它是如何工作的，假設，我們commit文件創建到了000007.json，如下圖所示。Spark已在內存中自動緩存了表的最新版本，從而加快了提交的速度。但是，與此同時，其他幾個writer（也許是需要的數據變更commit）已經向表中寫入了新數據，并一直添加commit到了0000012.json。

為了合并這些新事務并更新表的狀態，Spark然后將運行listFrom version 7操作以查看表的新更改。

無需處理所有中間JSON文件，Spark可以跳到最新的checkpoint文件，因為它包含commit＃10時表的整個狀態。現在，Spark只需執行表的增量處理0000011.json并0000012.json。然后，Spark將表的版本12緩存在內存中。通過遵循該工作流程，Delta Lake可以使用Spark隨時高效地保存表狀態的更新。

6.處理多并發讀寫

經過前面的介紹，應該大致了解在最上層delta lake事務日志的工作邏輯，接下來討論并發處理。前面主要介紹了線性或者至少沒有沖突的事務 行為。但是當delta lake處理多并發讀寫的時候會發生什么呢？

答案很簡單。為了實現并發控制delta lake引入了樂觀并發控制。

6.1 什么是樂觀并發控制

樂觀并發控制是一種處理并發事務的方法，該方法假定不同用戶對表進行的事務（更改）可以完成而不會相互沖突。該方法之所以如此之快，是因為在處理PB級數據時，不同用戶極有可能會處理數據的不同部分，從而使他們能夠同時無沖突的完成事務。

例如，假設A和B正在一起研究拼圖游戲。只要我們都在其中的不同部分上工作（例如，A在上半部分，而B在下班部分），接可以實現AB分別完成一部分拼圖，并以兩倍快的速度完成拼圖。只有當我們需要相同的零件時，才會有沖突。那就是樂觀的并發控制。

當然，即使采用了樂觀的并發控制，有時用戶的確會嘗試同時修改數據的相同部分。幸運的是，Delta Lake對此有一個協議。

6.2 樂觀的解決沖突

為了提供ACID 事務，Delta Lake有一個協議來確定commit的順序（在數據庫中稱為可序列化性的概念），并確定在同時進行兩個或多個commit的情況下該怎么做。Delta Lake通過實施互斥規則處理這些案例，然后嘗試樂觀地解決任何沖突。此協議允許Delta Lake遵循ACID 隔離原則，該原則可確保在多次并發寫入后，表的最終狀態相同。

通常，該過程如下進行：

1. 記錄表的起始版本。

2. 記錄讀/寫。

3. 嘗試提交。

4. 如果有人獲勝，請檢查已讀的內容是否已更改。

5. 重復上述過程。

要了解所有這些信息是如何實時進行的，讓我們看一下下面的圖，看看Delta Lake在發生沖突時如何處理沖突。想象一下，有兩個用戶從同一個表中讀取數據，然后每個用戶都嘗試向其中添加一些數據。

• Delta Lake記錄在進行任何變更之前讀取的表（版本0）的起始表版本。

• 用戶1和2都嘗試同時向表中添加一些數據。在這里，我們陷入了沖突，因為下一次只能提交一次并記錄為000001.json。

• Delta Lake通過“互斥”的概念解決了這一沖突，這意味著只有一個用戶可以成功進行提交000001.json。用戶1的提交被接受，而用戶2的提交被拒絕。

• Delta Lake寧愿樂觀地處理此沖突，也不愿為User 2引發錯誤。它檢查是否對表進行了任何新的提交，并以靜默方式更新表以響應這些更改，然后簡單地在新提交的表上重試用戶2的提交（不進行任何數據處理），并成功提交000002.json。

在大多數情況下，這種沖突解決是無聲，無縫且成功地進行的。但是，如果存在無法解決的問題，Delta Lake無法樂觀地解決（例如，如果用戶1刪除了用戶2也刪除的文件），則此時唯一的選擇就是拋出錯誤。

最后一點，由于在Delta Lake表上進行的所有事務都直接存儲到磁盤，因此此過程滿足了ACID屬性的持久性，這意味著即使系統發生故障，該操作的效果也將持續存在。

7.其他的使用案例

7.1 時間旅行

每個表都是Delta Lake事務日志中記錄的所有commit的總和的結果。事務日志提供了變更過程的記錄，詳細說明了如何從表的原始狀態變為當前狀態。

因此，我們可以通過從原始表開始在任何時間點重新創建表的狀態，并且僅處理該點之前的commit。這種強大的功能被稱為“時間旅行”或數據版本控制。

3.數據湖deltalake之時間旅行及版本管理

7.2 數據血緣和debug

作為對表進行的每次更改的明確記錄，Delta Lake事務日志為用戶提供了可驗證的數據血緣，可用于治理，審計和合規性目的。它也可以用來追溯意外變更的源頭或pipeline過程中的錯誤，以追溯到引起該錯誤的確切操作。用戶可以運行DESCRIBE HISTORY來查看有關所做更改的元數據。

上述就是小編為大家分享的怎么深入學習delta lake的事務日志了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。