Apache?Hudi多版本清理服務的示例分析

這篇文章給大家分享的是有關Apache Hudi多版本清理服務的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

1. 回收空間以控制存儲成本

Hudi 提供不同的表管理服務來管理數據湖上表的數據，其中一項服務稱為Cleaner（清理服務）。 隨著用戶向表中寫入更多數據，對于每次更新，Hudi會生成一個新版本的數據文件用于保存更新后的記錄(COPY_ON_WRITE) 或將這些增量更新寫入日志文件以避免重寫更新版本的數據文件 (MERGE_ON_READ)。 在這種情況下，根據更新頻率，文件版本數可能會無限增長，但如果不需要保留無限的歷史記錄，則必須有一個流程（服務）來回收舊版本的數據，這就是 Hudi 的清理服務。

2. 問題描述

在數據湖架構中，讀取端和寫入端同時訪問同一張表是非常常見的場景。由于 Hudi 清理服務會定期回收較舊的文件版本，因此可能會出現長時間運行的查詢訪問到被清理服務回收的文件版本的情況，因此需要使用正確的配置來確保查詢不會失敗。

3. 深入了解 Hudi清理服務

針對上述場景，我們先了解一下 Hudi 提供的不同清理策略以及需要配置的相應屬性，Hudi提供了異步或同步清理兩種方式。在詳細介紹之前我們先解釋一些基本概念：

• Hudi 基礎文件（HoodieBaseFile）：由壓縮后的最終數據組成的列式文件，基本文件的名稱遵循以下命名約定：<fileId>_<writeToken>_<instantTime>.parquet。在此文件的后續寫入中文件 ID 保持不變，并且提交時間會更新以顯示最新版本。這也意味著記錄的任何特定版本，給定其分區路徑，都可以使用文件 ID 和 instantTime進行唯一定位。

• 文件切片(FileSlice)：在 MERGE_ON_READ 表類型的情況下，文件切片由基本文件和由多個增量日志文件組成。

• Hudi 文件組(FileGroup)：Hudi 中的任何文件組都由分區路徑和文件ID 唯一標識，該組中的文件作為其名稱的一部分。文件組由特定分區路徑中的所有文件片組成。此外任何分區路徑都可以有多個文件組。

4. 清理服務

Hudi 清理服務目前支持以下清理策略：

• KEEP_LATEST_COMMITS：這是默認策略。該清理策略可確保回溯前X次提交中發生的所有更改。假設每 30 分鐘將數據攝取到 Hudi 數據集，并且最長的運行查詢可能需要 5 小時才能完成，那么用戶應該至少保留最后 10 次提交。通過這樣的配置，我們確保文件的最舊版本在磁盤上保留至少 5 小時，從而防止運行時間最長的查詢在任何時間點失敗，使用此策略也可以進行增量清理。

• KEEP_LATEST_FILE_VERSIONS：此策略具有保持 N 個文件版本而不受時間限制的效果。當知道在任何給定時間想要保留多少個 MAX 版本的文件時，此策略很有用，為了實現與以前相同的防止長時間運行的查詢失敗的行為，應該根據數據模式進行計算，或者如果用戶只想維護文件的 1 個最新版本，此策略也很有用。

5. 例子

假設用戶每 30 分鐘將數據攝取到 COPY_ON_WRITE 類型的 Hudi 數據集，如下所示：

圖1：每30分鐘將傳入的記錄提取到hudi數據集中

該圖顯示了 DFS 上的一個特定分區，其中提交和相應的文件版本是彩色編碼的。在該分區中創建了 4 個不同的文件組，如 fileId1、fileId2、fileId3 和 fileId4 所示。 fileId2 對應的文件組包含所有 5 次提交的記錄，而 fileId4 對應的組僅包含最近 2 次提交的記錄。

假設使用以下配置進行清理：

hoodie.cleaner.policy=KEEP_LATEST_COMMITS
hoodie.cleaner.commits.retained=2

Cleaner 通過處理以下事項來選擇要清理的文件版本：

• 不應清理文件的最新版本。

• 確定最后 2 次（已配置）+ 1 次提交的提交時間。在圖 1 中，commit 10:30 和 commit 10:00 對應于時間線中最新的 2 個提交。包含一個額外的提交，因為保留提交的時間窗口本質上等于最長的查詢運行時間。因此如果最長的查詢需要 1 小時才能完成，并且每 30 分鐘發生一次攝取，則您需要保留自 2*30 = 60（1 小時）以來的最后 2 次提交。此時最長的查詢仍然可以使用以相反順序在第 3 次提交中寫入的文件。這意味著如果一個查詢在 commit 9:30 之后開始執行，當在 commit 10:30 之后觸發清理操作時，它仍然會運行，如圖 2 所示。

• 現在對于任何文件組，只有那些沒有保存點（另一個 Hudi 表服務）且提交時間小于第 3 次提交（下圖中的“提交 9:30”）的文件切片被清理。

圖2：保留最近3次提交對應的文件

假設使用以下配置進行清理：

hoodie.cleaner.policy=KEEP_LATEST_FILE_VERSIONS
hoodie.cleaner.fileversions.retained=1

清理服務執行以下操作：

• 對于任何文件組，文件切片的最新版本（包括任何待壓縮的）被保留，其余的清理掉。 如圖 3 所示，如果在 commit 10:30之后立即觸發清理操作，清理服務將簡單地保留每個文件組中的最新版本并刪除其余的。

圖3：保留每個文件組中的最新文件版本

6. 配置

可以在 此處 中找到有關所有可能配置的詳細信息以及默認值。

7. 運行命令

Hudi 的清理表服務可以作為單獨的進程運行，可以與數據攝取一起運行。正如前面提到的，它會清除了任何陳舊文件。如果您想將它與攝取數據一起運行，可以使用配置同步或異步運行。或者可以使用以下命令獨立運行清理服務：

[hoodie]$ spark-submit --class org.apache.hudi.utilities.HoodieCleaner \
  --props s3:///temp/hudi-ingestion-config/config.properties \
  --target-base-path s3:///temp/hudi \
  --spark-master yarn-cluster

如果您希望與寫入異步運行清理服務，可以配置如下內容：

hoodie.clean.automatic=true
hoodie.clean.async=true

此外還可以使用 Hudi CLI 來管理 Hudi 數據集。CLI 為清理服務提供了以下命令：

cleans show

clean showpartitions

clean run

可以在 org.apache.hudi.cli.commands.CleansCommand 類 中找到這些命令的更多詳細信息和相關代碼。

感謝各位的閱讀！關于“Apache Hudi多版本清理服務的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！