Flink Hudi 0.10.0 釋出，多項重要更新，穩定性大幅提升

Flink 中文學習網站
https://flink-learning.org.cn

前言

隨著雲數倉技術的不斷成熟，資料湖儼然已成為當下最熱門的技術之一，而 Apache Hudi 是當下最具競爭力的資料湖格式之一：

擁有最活躍的開源社群之一，周活躍 PR 一直維持在 50+ 水平；
擁有最活躍的國內使用者群之一，目前的 Apache Hudi 釘釘群使用者已超過 2200+，國內各大廠商都已經佈局 Apache Hudi 生態。

Apache Hudi 的活躍度得益於其出色的 file format 設計和豐富的事物語義支援：

類 LSM 的 file format 佈局很好的適配了近實時更新場景，解決了超大資料集更新的痛點；
Hudi 的事物層語義在目前的湖儲存中是極其成熟和豐富的，基本所有的資料治理都可以自動化完成：compaction、rollback、cleaning、clustering。

Flink On Hudi

Apache Hudi 的 table format 對流計算友好的特性使得 Flink On Hudi 成為 Apache Hudi 專案最值得探索和挖掘的方向之一，Flink 不僅為 Hudi 解鎖了超大資料流的實時更新能力、更新增了流式消費和計算的能力，讓端到端近實時 ETL 得以在低成本的檔案儲存上輕鬆實現。

Flink On Hudi 專案在 2020 年 11 月立項，至今已迭代了三個版本，從第一個版本開始人氣和活躍度就一直高漲。5 月份組建的 Apache Hudi 釘釘群截止目前半年的時間，已經有超過 2200+ 使用者，並且活躍度一直排在 Flink 使用者群的前列。

Flink On Hudi 已成為部署 Apache Hudi 專案的首選方案，國內主要雲廠商：阿里雲、華為雲、騰訊雲，國外的 AWS 都已整合 Flink On Hudi；國內的大型網際網路公司：頭條、快手、B站以及傳統企業：順豐、海康等均有 Flink On Hudi 的生產實踐，具釘釘群的跟蹤回訪等不完全統計，至少超過 50+ 國內公司在生產上使用 Flink On Hudi，Uber 公司更將 Flink On Hudi 作為 2022 年的重點方向在推進！

Flink On Hudi 的開發者生態也非常活躍，目前國內有阿里雲、華為雲、頭條、B站的同學持續貢獻，Uber 公司和 AWS 更專門投入人力來對接 Flink On Hudi。

版本 Highlights

0.10.0 版本經過社群使用者的千錘百煉，貢獻了多項重要的 fix，更有核心讀寫能力的大幅增強，解鎖了多個新場景，Flink On Hudi 側的更新重點梳理如下：

Bug 修復

修復物件儲存上極端 case 流讀資料丟失的問題 [HUDI-2548]；
修復全量+增量同步偶發的資料重複 [HUDI-2686]；
修復 changelog 模式下無法正確處理 DELETE 訊息 [HUDI-2798]；
修復線上壓縮的記憶體洩漏問題 [HUDI-2715]。

新特性

支援增量讀取；
支援 batch 更新；
新增 Append 模式寫入，同時支援小檔案合併；
支援 metadata table。

功能增強

寫入效能大幅提升：優化寫入記憶體、優化了小檔案策略(更加均衡，無碎片檔案)、優化了 write task 和 coordinator 的互動；
流讀語義增強：新增引數 earliest，提升從最早消費效能、支援引數跳過壓縮讀取，解決讀取重複問題；
線上壓縮策略增強：新增 eager failover + rollback，壓縮順序改為從最早開始；
優化事件順序語義：支援處理序，支援事件序自動推導。

下面挑一些重點內容為大家詳細介紹。

小檔案優化

Flink On Hudi 寫入流程大致分為以下幾個元件：

row data to hoodie：負責將 table 的資料結構轉成 HoodieRecord；
bucket assigner：負責新的檔案 bucket(file group) 分配；
write task：負責將資料寫入檔案儲存；
coordinator：負責寫 trasaction 的發起和 commit；
cleaner：負責資料清理。

其中的 bucket assigner 負責了檔案 file group 的分配，也是小檔案分配策略的核心元件。0.10.0 版本的每個 bucket assign task 持有一個 bucket assigner，每個 bucket assigner 獨立管理自己的一組 file group 分組：

在寫入 INSERT 資料的時候，bucket assigner 會掃描檔案檢視，檢視當前管理的 file group 中哪些屬於小檔案範疇，如果 file group 被判定為小檔案，則會繼續追加寫入。比如上圖中 task-1 會繼續往 FG-1、FG-2 中追加 80MB 和 60MB 的資料。

為了避免過度的寫放大，當可寫入的 buffer 過小時會忽略，比如上圖中 FG-3、FG-4、FG-5 雖然是小檔案，但是不會往檔案中追加寫。task-2 會新開一個 file group 寫入。

全域性檔案檢視

0.10.0 版本將原本 write task 端的檔案檢視統一挪到 JobManager，JobManager 啟動之後會使用 Javaline 本地啟動一個 web server，提供全域性檔案檢視的訪問代理。Write task 通過傳送 http 請求和 web server 互動，拿到當前寫入的 file group 檢視。

Web server 避免了重複的檔案系統檢視載入，極大的節省了記憶體開銷。

流讀能力增強

0.10.0 版本新增了從最早消費資料的引數，通過指定 read.start-commit 為 earliest 即可流讀全量 + 增量資料，值得一提的是，當從 earliest 開始消費時，第一次的 file split 抓取會走直接掃描檔案檢視的方式，在開啟 metadata table 功能後，檔案的掃描效率會大幅度提升；之後的增量讀取部分會掃描增量的 metadata，以便快速輕量地獲取增量的檔案訊息。

新增處理順序

Apache Hudi 的訊息合併大體分為兩塊：增量資料內部合併、歷史資料和增量資料合併。訊息之間合併通過

write.precombine.field 欄位來判斷版本新舊，如下圖中標註藍色方塊的訊息為合併後被選中的訊息。

0.10.0 版本可以不指定 write.precombine.field 欄位，此時使用處理順序：即後來的訊息比較新，對應上圖紫色部分被選中的訊息。

Metadata Table

Metadata table 是 0.7.0 Hudi 引入的功能，目的是在查詢端減少 DFS 的訪問，類似於檔案 listings 和 partitions 資訊直接通過 metadata table 查詢獲取。Metadata 在 0.10.0 版本得到大幅加強，Flink 端也支援了該功能。

新版的 metadata table 為同步更新模型，當完成一次成功的資料寫入之後，coordinator 會先同步抽取檔案列表、partiiton 列表等資訊寫入 metadata table 然後再寫 event log 到 timeline（即 metadata 檔案）。

Metadata table 的基本檔案格式為 avro log，avro log 中的檔案編碼區別於正常的 MOR data log 檔案，是由高效的 HFile data block 構成，這樣做的好處是自持更高效率的 kv 查詢。同時 metadata table 的 avro log 支援直接壓縮成 HFile 檔案，進一步優化查詢效率。

總結和展望

在短短的半年時間，Flink On Hudi 至今已積攢了數量龐大的使用者群體。積極的使用者反饋和豐富的使用者場景不斷打磨 Flink On Hudi 的易用性和成熟度，使得 Flink On Hudi 專案以非常高效的形式快速迭代。通過和頭部公司如頭條、B 站等共建的形式，Flink On Hudi 形成了非常良性的開發者使用者群。

Flink On Hudi 是 Apache Hudi 社群接下來兩個大版本主要的發力方向，在未來規劃中，主要有三點：