Apache Hudi 如何加速傳統的批處理模式？

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

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

時間和成本——每天都需要覆蓋整個歷史表

資料版本控制——沒有開箱即用的資料和清單版本控制（回滾、併發讀取和寫入、時間點查詢、時間旅行以及相關功能不存在）

寫入放大——日常歷史資料覆蓋場景中的外部（或自我管理）資料版本控制增加了寫入放大，從而占用更多的 s3 儲存

借助apache hudi，我們希望在將資料攝取到資料湖中的同時，找到更好的重複資料刪除和資料版本控制優化解決方案。

當我們開始在我們的資料湖上實現 apache hudi 的旅程時，我們根據表的主要使用者的查詢模式將表分為 2 類。

這是乙個示例電子商務訂單資料流，從攝取到資料湖到建立 olap，最後到業務分析師查詢它

由於兩種型別的表的日期分割槽列不同，我們採用不同的策略來解決這兩個用例。

在 hudi 中，我們需要指定分割槽列和主鍵列，以便 hudi 可以為我們處理更新和刪除。

以下是我們如何處理面向分析師的表中的更新和刪除的邏輯：

由於主鍵和 created_date 對於退出和傳入記錄保持相同，hudi 通過使用來自傳入記錄 created_date 和 primary_key 列的此資訊獲取現有記錄的分割槽和分割槽檔案路徑。

當我們開始使用 hudi 時，在閱讀了許多部落格和文件之後，在 created_date 上對面向 etl 的表進行分割槽似乎是合乎邏輯的。

此外 hudi 提供增量消費功能，允許我們在 created_date 上對錶進行分割槽，並僅獲取在 d-1 或 d-n 上插入（插入或更新）的那些記錄。

這種方法在理論上效果很好，但在改造傳統的日常批處理過程中的增量消費時，它帶來了其他一系列挑戰：

hudi 維護了在不同時刻在表上執行的所有操作的時間表，這些提交包含有關作為 upsert 的一部分插入或重寫的部分檔案的資訊，我們將此 hudi 表稱為 commit timeline。

這裡要注意的重要資訊是增量查詢基於提交時間線，而不依賴於資料記錄中存在的實際更新/建立日期資訊。

作為面向 etl 的作業的解決方法，我們嘗試將資料分割槽保持在 updated_date 本身，然而這種方法也有其自身的挑戰。

我們知道 hudi 表的本地索引，hudi 依靠索引來獲取儲存在資料分割槽本地目錄中的 row-to-part_file 對映。因此，如果我們的表在 updated_date 進行分割槽，hudi 無法跨分割槽自動刪除重覆記錄。

hudi 的全域性索引策略要求我們保留乙個內部或外部索引來維護跨分割槽的資料去重。對於大資料量，每天大約 2 億條記錄，這種方法要麼執行緩慢，要麼因 oom 而失敗。

因此，為了解決更新日期分割槽的資料重複挑戰，我們提出了一種全新的重複資料刪除策略，該策略也具有很高的效能。

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

時間和成本——hudi 在重複資料刪除時不會覆蓋整個表。它只是重寫接收更新的部分檔案。因此較小的 upsert 工作

資料版本控制——hudi 保留表版本（提交歷史），因此提供實時查詢（時間旅行）和表版本回滾功能。

寫入放大——由於只有部分檔案被更改並保留用於資料清單版本控制，我們不需要保留完整資料的版本。因此整體寫入放大是最小的。

作為資料版本控制的另乙個好處，它解決了併發讀取和寫入問題，因為資料版本控制使併發讀取器可以讀取資料檔案的版本控制副本，並且當併發寫入器用新資料覆蓋同一分割槽時不會丟擲 filenotfoundexception 檔案。