本文為 Apache Hudi 技術(shù)社區(qū)分享會(huì)嘉賓分享文章，主要介紹火山引擎 LAS 團(tuán)隊(duì)自研的多場景樣本離線存儲(chǔ)技術(shù)，用于處理機(jī)器學(xué)習(xí)系統(tǒng)的離線數(shù)據(jù)流。同時(shí)，還會(huì)為大家揭秘流批一體樣本生成的過程，分享對 Hudi 內(nèi)核所做出的優(yōu)化和改造，探索其在數(shù)據(jù)處理領(lǐng)域的實(shí)際應(yīng)用和效果。
以下為分享原文。
1. 業(yè)務(wù)場景
為了讓大家更容易理解接下來要講的基于數(shù)據(jù)湖的樣本存儲(chǔ)和樣本生成問題，文章先給大家簡單介紹一些相關(guān)的基礎(chǔ)概念。首先是機(jī)器學(xué)習(xí)系統(tǒng)的離線數(shù)據(jù)流架構(gòu)，機(jī)器學(xué)習(xí)系統(tǒng)和其他線上服務(wù)系統(tǒng)類似，其中和樣本有關(guān)的角色也比較集中。如下圖所示，整個(gè)離線數(shù)據(jù)流架構(gòu)分為流式和批式兩種類型，其中的樣本數(shù)據(jù)由兩部分構(gòu)成，分別是特征和標(biāo)簽。
在流式架構(gòu)中，特征由在線預(yù)估服務(wù)在 serving 時(shí) dump 對應(yīng)的快照并發(fā)送到消息隊(duì)列中。標(biāo)簽則來自實(shí)時(shí)行為采集服務(wù)，通過日志上報(bào)等方法采集得到。在線樣本生成服務(wù)消費(fèi)兩個(gè)數(shù)據(jù)流，通過關(guān)聯(lián)得到完整的樣本，并發(fā)送到下游的流式訓(xùn)練服務(wù)中進(jìn)行模型訓(xùn)練，完成樣本數(shù)據(jù)的消費(fèi)。
批式架構(gòu)是流式架構(gòu)的補(bǔ)充，批式架構(gòu)在訂閱流式數(shù)據(jù)的同時(shí)，還會(huì)加入批式的特征或者批式生成的標(biāo)簽。比如風(fēng)控反作弊或者廣告類的業(yè)務(wù)，會(huì)有批式生產(chǎn)的數(shù)據(jù)，并使用批式的樣本生成模塊生成樣本，進(jìn)而被模型訓(xùn)練組件消費(fèi)。
流式和批式數(shù)據(jù)流架構(gòu)中，還有元數(shù)據(jù)服務(wù)，元數(shù)據(jù)服務(wù)記錄了特征的相關(guān)元數(shù)據(jù)，流式批式數(shù)據(jù)流都會(huì)訪問元數(shù)據(jù)服務(wù)獲取 meta 信息。因此，我們對于批式的特征存儲(chǔ)有若干種特定的訪問 pattern。
讀方面有以下讀數(shù)據(jù) pattern：大范圍的按天批式讀取，關(guān)注吞吐指標(biāo);秒級(jí)的點(diǎn)查;高效的謂詞下推查詢能力;存在基于主鍵/外建的 join。
在寫方面需支持以下能力：基于主鍵的 upsert;針對部分 cell 的插入與更新;針對行/列/cell 的刪除;基于外鍵的 upsert。
在這樣的背景下，我們了解 Hudi 在機(jī)器學(xué)習(xí)離線數(shù)據(jù)流中的若干應(yīng)用場景。
2.離線樣本存儲(chǔ)與迭代
我們希望設(shè)計(jì)的樣本離線存儲(chǔ)方案能夠適用于多種場景，主要包含以下三類情況。
第一，模型的重新訓(xùn)練，回放流式訓(xùn)練的過程，迭代/糾偏模型等等。
第二，樣本的數(shù)據(jù)迭代，增加修改或者刪除對應(yīng)的特征/標(biāo)簽，并重新訓(xùn)練模型。
第三，樣本的 OLAP 查詢，用于日常 debug 等。
為了能夠支持以上的場景的樣本存儲(chǔ)與迭代，我們提出的存儲(chǔ)方案整體架構(gòu)設(shè)計(jì)如下。在邏輯建模上，構(gòu)建樣本存儲(chǔ)和構(gòu)建特定 pattern 的 Hive 表非常類似，樣本包含主鍵、分區(qū)鍵、內(nèi)部元數(shù)據(jù)列等功能性 column，然后包含若干特征列和若干標(biāo)簽列。在物理架構(gòu)上，通過流式和批式生產(chǎn)/采集的特征數(shù)據(jù)和標(biāo)簽數(shù)據(jù)通過多個(gè)作業(yè)混合 upsert 的方式寫入 Hudi，更新位于 KV 存儲(chǔ)的索引信息，并將實(shí)際的數(shù)據(jù)寫入 HDFS 中。由于 Hudi 基于主鍵/外鍵 upsert 的特性，數(shù)據(jù)會(huì)被自然地拼接在一起，形成完整的包含特征和標(biāo)簽的樣本數(shù)據(jù)，供消費(fèi)使用。
在對離線特征進(jìn)行調(diào)研時(shí)，我們需要面臨以下挑戰(zhàn)：基于 HDFS 這種不可變的文件存儲(chǔ)，如何實(shí)現(xiàn)低成本低讀寫放大的數(shù)據(jù)修改。在沒有使用數(shù)據(jù)湖之前，用戶做離線特征調(diào)研之前需要復(fù)制樣本，修改并另存一份。其中消耗了巨大的計(jì)算和存儲(chǔ)資源，伴隨樣本量的增大，這樣的方案將消耗數(shù)個(gè) EB 的存儲(chǔ)，使得迭代變得不可能。
我們基于 Hudi 實(shí)現(xiàn)了 ColumnFamily 的能力。這個(gè)方案受到了經(jīng)典 BigTable 存儲(chǔ) Apache Hbase 的啟發(fā)，將 IO pattern 不同的數(shù)據(jù)使用不同的文件進(jìn)行存儲(chǔ)，以減少不必要的讀寫放大。原理是將同一個(gè) FileGroup 的不同列數(shù)據(jù)存儲(chǔ)在不同的文件中，在讀時(shí)進(jìn)行合并。這種方法會(huì)將新增列的數(shù)據(jù)單獨(dú)進(jìn)行文件存儲(chǔ)，發(fā)生修改或者新增成本很低。
我們通過為調(diào)研特征列賦予單獨(dú)的 CF 的方式來減少讀寫放大，其他列復(fù)用線上的特征所在的 CF。這樣資源的使用量只會(huì)和新增特征相關(guān)。這種方式極大得減少了迭代所需的存儲(chǔ)使用，并且不會(huì)引入任何 shuffle 操作。
上文介紹了離線樣本的存儲(chǔ)與迭代方案，接下來我們進(jìn)一步為大家介紹在線樣本生成時(shí)的流批一體生成方案，討論其如何降低在線存儲(chǔ)的使用成本。
3. 流批一體的樣本生成
在線樣本生成服務(wù)中，我們使用 KV 或者 BigTable 類存儲(chǔ)來滿足樣本拼接的需求，比如 RocksDB 等。這類存儲(chǔ)點(diǎn)查性能好，延遲低，但是存儲(chǔ)成本也較高。如果在數(shù)據(jù)有明顯的冷熱分層的情況下，這類存儲(chǔ)本身并不能很好的滿足這樣的存儲(chǔ)需求。Hudi 是一個(gè)具有 KV 語義的離線存儲(chǔ)，存儲(chǔ)成本較低，我們將冷數(shù)據(jù)存在 Hudi 上的方式來降低在線存儲(chǔ)的使用成本，并通過統(tǒng)一的讀寫接口來屏蔽差異。這一架構(gòu)也受到了目前市面的多種 HSAP 系統(tǒng)的啟發(fā)。
為了能夠讓 Hudi 支持更好的點(diǎn)查，我們復(fù)用了寫時(shí)的 Hbase 索引。點(diǎn)查請求會(huì)先訪問 Hbase 索引找到數(shù)據(jù)所在文件，然后根據(jù)文件進(jìn)行點(diǎn)查。整體端到端的延遲可以做到秒級(jí)。適合存儲(chǔ)數(shù)據(jù)量大，qps 較低的場景。
4. 功能與優(yōu)化
在使用 Hudi 滿足諸多業(yè)務(wù)需求的過程中，我們也對其內(nèi)核做了一些改造，以更好得服務(wù)我們的業(yè)務(wù)場景。
4.1 Local Sort
我們支持了單文件內(nèi)的主鍵排序。排序是較為常見的查詢性能優(yōu)化手段。通過對主鍵的排序，享受以下收益
● CF 在讀時(shí)，多 CF 合并使用 Sort Merge 的方式，內(nèi)存使用更低。
● Compaction 時(shí)支持 Sort Merge。不會(huì)觸發(fā) spill，內(nèi)存使用低。我們之前使用 SSD 隊(duì)列來做 Compaction 以保證性能，現(xiàn)在可以使用一些廉價(jià)的資源(比如無盤的潮汐資源)來進(jìn)行 Compaction。
● 在流批一體的樣本生成中，由于主鍵是排好序的，我們點(diǎn)查時(shí)基于主鍵的謂詞下推效果非常好。提升了點(diǎn)查性能。
4.2 Bulkload 并發(fā)寫
并發(fā)寫一直是 Hudi 的比較大的挑戰(zhàn)。我們的業(yè)務(wù)場景中會(huì)發(fā)生行級(jí)別/列級(jí)別的寫沖突，這種沖突無法通過樂觀鎖來避免。基于機(jī)器學(xué)習(xí)對于數(shù)據(jù)沖突的解決需求，我們之前就支持了 MVCC 的沖突解決方式。更進(jìn)一步得，為了能夠讓 Hudi 支持并發(fā)讀寫，我們參考 Hbase 支持了 Bulkload 的功能來解決并發(fā)寫需求。所有寫數(shù)據(jù)都會(huì)寫成功，并由數(shù)據(jù)內(nèi)部的 mvcc 來決定數(shù)據(jù)沖突。
我們首先將數(shù)據(jù)文件生成到一個(gè)臨時(shí)緩沖區(qū)，每個(gè)緩沖區(qū)對應(yīng)一個(gè) commit 請求，多個(gè)寫臨時(shí)緩沖區(qū)的請求可以并發(fā)進(jìn)行。當(dāng)數(shù)據(jù)完整寫入臨時(shí)緩沖區(qū)之后，我們有一個(gè)常駐的任務(wù)會(huì)接收數(shù)據(jù) load 的請求，將數(shù)據(jù)從緩沖區(qū)中通過文件移動(dòng)的方式 load 進(jìn) Hudi，并生成對應(yīng)的 commit 信息。多個(gè) load 請求是線性進(jìn)行的，由 Hudi Timeline 的表鎖保證，但是每個(gè) load 請求中只涉及文件的移動(dòng)，所以 load 請求執(zhí)行時(shí)間是秒級(jí)，這樣就實(shí)現(xiàn)了大吞吐的數(shù)據(jù)多并發(fā)寫和最終一致性。
4.3 Compaction Service
關(guān)于 Compaction，Hudi 社區(qū)提供了若干 Compaction 的開箱即用的策略。但是業(yè)務(wù)側(cè)的需求非常靈活多變，無法歸類到一種開箱即用的策略上。因此我們提供了 Compaction Service 這樣的組件用來處理用戶的 Compaction 請求，允許用戶主動(dòng)觸發(fā)一次 Compaction，并可指定 Compaction 的數(shù)據(jù)范圍，資源使用等等。用戶也可以選擇按照時(shí)間周期性觸發(fā) Compaction，以達(dá)到自動(dòng)化數(shù)據(jù)生效的效果。
在底層我們針對 Compaction 的業(yè)務(wù)場景做了冷熱隊(duì)列分層，根據(jù)不同的 SLA 的 Compaction 任務(wù)，會(huì)選擇對應(yīng)的隊(duì)列資源來執(zhí)行。用來降低 Compaction 的整體成本。比如每天天級(jí)別的數(shù)據(jù)生效是一個(gè)高保障的 Compaction 任務(wù)，會(huì)有獨(dú)占隊(duì)列來執(zhí)行。但是進(jìn)行歷史數(shù)據(jù)的單次修復(fù)觸發(fā)的 Compaction，對執(zhí)行時(shí)間不敏感，會(huì)被調(diào)度到低優(yōu)先級(jí)隊(duì)列以較低成本完成。
針對數(shù)據(jù)湖的樣本存儲(chǔ)與生成問題，我們搭建了適用于多種場景的存儲(chǔ)方案架構(gòu)，實(shí)現(xiàn)了批流一體的樣本生成，并且通過對 Hudi 內(nèi)核進(jìn)行一定的改造，實(shí)現(xiàn)更加滿足實(shí)際業(yè)務(wù)需求的功能設(shè)計(jì)。
以上就是字節(jié)跳動(dòng)在 Hudi 的實(shí)踐，目前均已通過火山引擎 湖倉一體分析服務(wù) LAS 產(chǎn)品對外服務(wù)，歡迎對這方面有需求、感興趣的用戶都可以積極地來體驗(yàn)一下我們的 LAS 湖倉一體分析服務(wù) 。
湖倉一體分析服務(wù) LAS(Lakehouse Analytics Service)是面向湖倉一體架構(gòu)的 Serverless 數(shù)據(jù)處理分析服務(wù)，提供字節(jié)跳動(dòng)最佳實(shí)踐的一站式 EB 級(jí)海量數(shù)據(jù)存儲(chǔ)計(jì)算和交互分析能力，兼容 Spark、Presto 生態(tài)，幫助企業(yè)輕松構(gòu)建智能實(shí)時(shí)湖倉。
