Hudi 演進(jìn) | Apache Hudi PMC 暢談 Hudi 未來演進(jìn)之路

大綱：

1.Hudi簡(jiǎn)介2.表元數(shù)據(jù)3.緩存4.社區(qū)

上圖展示了大部分用戶使用Hudi的場(chǎng)景。通常用Flink或者Spark或者Hudi內(nèi)置工具DeltaStreamer讀取數(shù)據(jù)源，寫入原始表。這些表可以被不同的查詢引擎讀取，做常規(guī)的數(shù)據(jù)湖分析，或者做批處理。同時(shí)用Hudi提供的庫可以搭建增量ETL管道，寫入衍生表中。Hudi促進(jìn)形成了一套生態(tài)系統(tǒng)，包含眾多管理數(shù)據(jù)的功能，可以有效地分離高度優(yōu)化的數(shù)據(jù)層和其上面搭建的查詢層。

Hudi - 先行者

成立于2016年，Hudi項(xiàng)目是在數(shù)據(jù)湖上建立事務(wù)層系統(tǒng)的原創(chuàng)者。最初的設(shè)計(jì)是一個(gè)支持多引擎、與計(jì)算分離的存儲(chǔ)系統(tǒng)。引入了Copy-On-Write和Merge-On-Read的概念，本質(zhì)上提供了不同的組織管理數(shù)據(jù)的方式，迎合了快速寫入和查詢的需求。把變更捕獲（change capture）引入了數(shù)據(jù)湖。很多這些概念被廣泛地借鑒和采用了。

接下來快速的瀏覽Hudi主要功能特點(diǎn)。以上是我們技術(shù)棧里所有的層。建立在廉價(jià)的可擴(kuò)展的存儲(chǔ)上，也可以在內(nèi)存文件系統(tǒng)上工作，比如Alluxio。完全建立在開放的格式上。在底層我們提供的是一個(gè)事務(wù)性的數(shù)據(jù)庫核心，也是項(xiàng)目建立的初始理念。現(xiàn)在我們把這個(gè)成為表格式。還包括快速更刪的索引，內(nèi)置的后臺(tái)運(yùn)行的表服務(wù)，還有并行控制。表格式之上我們提供了一套讀寫API和SQL支持。在最上層提供了一套運(yùn)行編排工具和平臺(tái)服務(wù)。很多Hudi貢獻(xiàn)者的開發(fā)貢獻(xiàn)了各種各樣的很棒的功能。

這里的介紹的核心點(diǎn)是，Hudi是一個(gè)平臺(tái)。接下來的幾個(gè)頁面會(huì)快速過一下。

以上幾頁快速提到了表格式、文件格式、索引、并發(fā)控制、寫入、讀取、表服務(wù)和平臺(tái)服務(wù)。重點(diǎn)提一下并發(fā)控制：Hudi內(nèi)部的進(jìn)程不會(huì)彼此阻塞，因?yàn)樗鼈兿嗷ブ獣浴懭肫髯陨砟壳坝玫搅藗鹘y(tǒng)的鎖模式控制，我們?cè)诔耆珶o鎖的方向開發(fā)。

什么樣的數(shù)據(jù)我們稱為元數(shù)據(jù)？Schema，文件相關(guān)，統(tǒng)計(jì)數(shù)據(jù)，重做日志。至于索引，因?yàn)樗饕坏韧诮y(tǒng)計(jì)數(shù)據(jù)，量也可能很大，Hudi有另一套機(jī)制來管理，所以這里不把索引包含在元數(shù)據(jù)范圍內(nèi)介紹。

Hudi現(xiàn)在如何儲(chǔ)存以上這些元數(shù)據(jù)呢？Schema存儲(chǔ)在重做日志里，可以和不同的元數(shù)據(jù)存儲(chǔ)服務(wù)同步。文件相關(guān)的存在一個(gè)內(nèi)部的元數(shù)據(jù)Hudi表中。重做日志存在時(shí)間線文件夾".hoodie"。事務(wù)完成可以存檔。統(tǒng)計(jì)數(shù)據(jù)目前沒有單獨(dú)存放，從footer里提取。有時(shí)候并行讀取footer反而更快，尤其在云端存儲(chǔ)上。

在高寫入的場(chǎng)景下，把統(tǒng)計(jì)元數(shù)據(jù)寫入額外的文件也會(huì)對(duì)讀效率造成影響，以上的測(cè)試數(shù)據(jù)顯示，1TB的快速寫入文件，分成了16MB的塊，若是100列的數(shù)據(jù)，則產(chǎn)生了650萬以上的統(tǒng)計(jì)記錄，讀取需要10秒左右，會(huì)大幅降低查詢規(guī)劃的速度。Hudi RFC-27 在做的是基于區(qū)間樹的范圍查詢可以大幅提高讀取效率。

即使有了范圍查詢，讀取效率還是很難滿足需要join比如20-30個(gè)表的需求。假如每個(gè)表讀取需要2秒，整個(gè)查詢規(guī)劃很難在1分鐘內(nèi)完成。Hudi 內(nèi)置了元數(shù)據(jù)服務(wù)器，運(yùn)行在driver上，為executor緩存了文件列舉的結(jié)果，能緩解在云儲(chǔ)存比如S3上限流的問題。內(nèi)部的元數(shù)據(jù)Hudi表也利用了元數(shù)據(jù)服務(wù)器緩存查詢結(jié)果，相當(dāng)于給表建立了多級(jí)緩存。

我們正在加大對(duì)元數(shù)據(jù)服務(wù)器擴(kuò)展性的投入。比如開發(fā)關(guān)于統(tǒng)計(jì)，重做日志和鎖定的API。也可以支持集群化，本地存檔恢復(fù)，遠(yuǎn)程數(shù)據(jù)庫集成等。

接下來介紹緩存的設(shè)計(jì)思路。頻繁寫入的場(chǎng)景會(huì)產(chǎn)生大量的commit，不可避免的產(chǎn)生了大量小文件。文件系統(tǒng)層面上的緩存很難滿足性能需求。所以我們需要高效率的內(nèi)存緩存。Hudi的文件組（FileGroup）是一個(gè)天生和緩存契合的模型。右圖展示了文件組的概念：隨著時(shí)間推移，新寫入的文件（log file）會(huì)和本文件（base file）不斷合并。同一個(gè)記錄的更新會(huì)待在同一個(gè)文件組里。文件組是合并（compact）的最小單元，可以通過調(diào)節(jié)設(shè)置來使它匹配緩存容量大小，緩存合并后的數(shù)據(jù)可以很好地節(jié)省計(jì)算成本。

文件組的緩存可以是提前更新（Refresh-Ahead）模式，也可以是讀時(shí)緩存（Read-Through）模式。在典型的更新捕獲的場(chǎng)景中，我們可以做微合并（Micro-compact）來主動(dòng)緩存。根據(jù)讀的需求規(guī)律，可以調(diào)整讀時(shí)緩存的設(shè)置，比如針對(duì)特定分區(qū)的前綴設(shè)置LRU或LFU。

每個(gè)文件組都有唯一的ID，可以使用一致性哈希把緩存服務(wù)器擴(kuò)展到分布式集群。考慮到Hudi本身的事務(wù)性，只有被commit的文件才可以被包括到緩存中，回滾操作也需要確保清空緩存。我們也考慮設(shè)計(jì)可插拔式的緩存層：只要支持了Hudi緩存API的緩存服務(wù)都可以被引入到架構(gòu)里。

Hudi走到今天，得益于廣大開發(fā)者給力的貢獻(xiàn)。Slack上有1200+用戶，GitHub有200+的貢獻(xiàn)者，吸收了來自10+企業(yè)和組織的commiter和PMC。同時(shí)PMC和其他活躍者也對(duì)社區(qū)做著積極的維護(hù)。

以上是一些正在開發(fā)的重大更新和功能。

Hudi已廣泛地被眾多企業(yè)采用。

感興趣的同學(xué)歡迎通過以上方式（郵件列表、GitHub等）和社區(qū)進(jìn)行互動(dòng)。