目錄

• 1. 現狀說明
• 1.1 數據湖攝取和計算過程 - 處理更新
• 1.2 當前批處理過程中的挑戰
• 2. Hudi 數據湖 — 查詢模式
• 2.1 面向分析師的表/OLAP（按 created_date 分區）
• 2.2 面向ETL（按更新日期分區）
• 1. “created_date”分區的挑戰
• 2. “updated_date”分區的挑戰
• 3. “新”重復數據刪除策略
• 4. Apache Hudi 的優勢

Apache Hudi(簡稱：Hudi)使得您能在hadoop兼容的存儲之上存儲大量數據，同時它還提供兩種原語，使得除了經典的批處理之外，還可以在數據湖上進行流處理。

1. 現狀說明

1.1 數據湖攝取和計算過程 - 處理更新

在我們的用例中1-10% 是對歷史記錄的更新。當記錄更新時，我們需要從之前的 updated_date 分區中刪除之前的條目，并將條目添加到最新的分區中，在沒有刪除和更新功能的情況下，我們必須重新讀取整個歷史表分區 -> 去重數據 -> 用新的去重數據覆蓋整個表分區

1.2 當前批處理過程中的挑戰

這個過程有效，但也有其自身的缺陷：

1. 時間和成本——每天都需要覆蓋整個歷史表
2. 數據版本控制——沒有開箱即用的數據和清單版本控制（回滾、并發讀取和寫入、時間點查詢、時間旅行以及相關功能不存在）
3. 寫入放大——日常歷史數據覆蓋場景中的外部（或自我管理）數據版本控制增加了寫入放大，從而占用更多的 S3 存儲

借助Apache Hudi，我們希望在將數據攝取到數據湖中的同時，找到更好的重復數據刪除和數據版本控制優化解決方案。

2. Hudi 數據湖 — 查詢模式

當我們開始在我們的數據湖上實現 Apache Hudi 的旅程時，我們根據表的主要用戶的查詢模式將表分為 2 類。

• 面向ETL ：這是指我們從各種生產系統攝取到數據湖中的大多數原始/基本快照表。 如果這些表被 ETL 作業廣泛使用，那么我們將每日數據分區保持在 updated_date，這樣下游作業可以簡單地讀取最新的 updated_at 分區并（重新）處理數據。
• 面向分析師：通常包括維度表和業務分析師查詢的大部分計算 OLAP，分析師通常需要查看基于事務（或事件）created_date 的數據，而不太關心 updated_date。

這是一個示例電子商務訂單數據流，從攝取到數據湖到創建 OLAP，最后到業務分析師查詢它

由于兩種類型的表的日期分區列不同，我們采用不同的策略來解決這兩個用例。

2.1 面向分析師的表/OLAP（按 created_date 分區）

在 Hudi 中，我們需要指定分區列和主鍵列，以便 Hudi 可以為我們處理更新和刪除。
以下是我們如何處理面向分析師的表中的更新和刪除的邏輯：

• 讀取上游數據的 D-n 個 updated_date 分區。
• 應用數據轉換。 現在這個數據將只有新的插入和很少的更新記錄。
• 發出 hudi upsert 操作，將處理后的數據 upsert 到目標 Hudi 表。

由于主鍵和 created_date 對于退出和傳入記錄保持相同，Hudi 通過使用來自傳入記錄 created_date 和 primary_key 列的此信息獲取現有記錄的分區和分區文件路徑。

2.2 面向ETL（按更新日期分區）

當我們開始使用 Hudi 時，在閱讀了許多博客和文檔之后，在 created_date 上對面向 ETL 的表進行分區似乎是合乎邏輯的。
此外 Hudi 提供增量消費功能，允許我們在 created_date 上對表進行分區，并僅獲取在 D-1 或 D-n 上插入（插入或更新）的那些記錄。

1. “created_date”分區的挑戰

這種方法在理論上效果很好，但在改造傳統的日常批處理過程中的增量消費時，它帶來了其他一系列挑戰：
Hudi 維護了在不同時刻在表上執行的所有操作的時間表，這些提交包含有關作為 upsert 的一部分插入或重寫的部分文件的信息，我們將此 Hudi 表稱為 Commit Timeline。
這里要注意的重要信息是增量查詢基于提交時間線，而不依賴于數據記錄中存在的實際更新/創建日期信息。

• 冷啟動：當我們將現有的上游表遷移到 Hudi 時，D-1 Hudi 增量查詢將獲取完整的表，而不僅僅是 D-1 更新。發生這種情況是因為在開始時，整個表是通過在 D-1 提交時間線內發生的單個初始提交或多個提交創建的，并且缺少真正的增量提交信息。
• 歷史數據重新攝取：在每個常規增量 D-1 拉取中，我們期望僅在 D-1 上更新的記錄作為輸出。但是在重新攝取歷史數據的情況下，會再次出現類似于前面描述的冷啟動問題的問題，并且下游作業也會出現 OOM。

歷史數據重新攝取：在每個常規增量 D-1 拉取中，我們期望僅在 D-1 上更新的記錄作為輸出。但是在重新攝取歷史數據的情況下，會再次出現類似于前面描述的冷啟動問題的問題，并且下游作業也會出現 OOM。

作為面向 ETL 的作業的解決方法，我們嘗試將數據分區保持在 updated_date 本身，然而這種方法也有其自身的挑戰。

2. “updated_date”分區的挑戰

我們知道 Hudi 表的本地索引，Hudi 依靠索引來獲取存儲在數據分區本地目錄中的 Row-to-Part_file 映射。因此，如果我們的表在 updated_date 進行分區，Hudi 無法跨分區自動刪除重復記錄。
Hudi 的全局索引策略要求我們保留一個內部或外部索引來維護跨分區的數據去重。對于大數據量，每天大約 2 億條記錄，這種方法要么運行緩慢，要么因 OOM 而失敗。
因此，為了解決更新日期分區的數據重復挑戰，我們提出了一種全新的重復數據刪除策略，該策略也具有很高的性能。

3. “新”重復數據刪除策略

• 查找更新 - 從每日增量負載中，僅過濾掉更新（1-10% 的 DI 數據）（其中 updated_date> created_date）（快速，僅映射操作）
• 找到過時更新 - 將這些“更新”與下游 Hudi 基表廣播連接。 由于我們只獲取更新的記錄（僅占每日增量的 1-10%），因此可以實現高性能的廣播連接。 這為我們提供了與更新記錄相對應的基礎 Hudi 表中的所有現有記錄
• 刪除過時更新——在基本 Hudi 表路徑上的這些“過時更新”上發出 Hudi 刪除命令
• 插入 - 在基本 hudi 表路徑上的完整每日增量負載上發出 hudi insert 命令

進一步優化用 true 填充陳舊更新中的 _hoodie_is_deleted 列，并將其與每日增量負載結合。 通過基本 hudi 表路徑發出此數據的 upsert 命令。 它將在單個操作（和單個提交）中執行插入和刪除。

4. Apache Hudi 的優勢

• 時間和成本——Hudi 在重復數據刪除時不會覆蓋整個表。 它只是重寫接收更新的部分文件。 因此較小的 upsert 工作
• 數據版本控制——Hudi 保留表版本（提交歷史），因此提供實時查詢（時間旅行）和表版本回滾功能。
• 寫入放大——由于只有部分文件被更改并保留用于數據清單版本控制，我們不需要保留完整數據的版本。 因此整體寫入放大是最小的。

作為數據版本控制的另一個好處，它解決了并發讀取和寫入問題，因為數據版本控制使并發讀取器可以讀取數據文件的版本控制副本，并且當并發寫入器用新數據覆蓋同一分區時不會拋出 FileNotFoundException 文件。

到此這篇關于Apache Hudi 如何加速傳統的批處理模式的文章就介紹到這了,更多相關Apache Hudi 批處理模式內容請搜索以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持！