1. 現狀說明
1.1 資料湖攝取和計算過程 - 處理更新
在我們的用例中1-10% 是對歷史記錄的更新。當記錄更新時，我們需要從之前的 updated_date 分割槽中刪除之前的條目，並將條目新增到最新的分割槽中，在沒有刪除和更新功能的情況下，我們必須重新讀取整個歷史表分割槽 -> 去重資料 -> 用新的去重資料覆蓋整個表分割槽
1.2 當前批處理過程中的挑戰
這個過程有效，但也有其自身的缺陷：
- 時間和成本——每天都需要覆蓋整個歷史表
- 資料版本控制——沒有開箱即用的資料和清單版本控制（回滾、併發讀取和寫入、時間點查詢、時間旅行以及相關功能不存在）
- 寫入放大——日常歷史資料覆蓋場景中的外部（或自我管理）資料版本控制增加了寫入放大，從而佔用更多的 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。
作為面向 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 檔案。