沃爾瑪系統(tǒng)產(chǎn)生了世界上最大和最多樣化的數(shù)據(jù)集之一，每天數(shù)據(jù)增長(zhǎng)超 10 PB。 來(lái)自許多不同的來(lái)源及其支持的后端系統(tǒng)，一系列大量的業(yè)務(wù)事件流被發(fā)送到主要由 Apache Kafka 支持的消息傳遞層。

沃爾瑪團(tuán)隊(duì)強(qiáng)烈希望擴(kuò)展近乎實(shí)時(shí)的決策制定，如事件驅(qū)動(dòng)架構(gòu)的顯著增加、來(lái)自生產(chǎn)數(shù)據(jù)庫(kù)的變更數(shù)據(jù)捕獲 (CDC)、ML 和計(jì)算機(jī)視覺服務(wù)，所有這些都導(dǎo)致了大表新的查詢模式。 由于復(fù)雜的拓?fù)浣Y(jié)構(gòu)、事件的速度、 數(shù)據(jù)種類繁多，模式快速變化。

(資料圖片)

考慮到這些挑戰(zhàn)，沃爾瑪已經(jīng)開始將數(shù)據(jù)湖從面向批處理的架構(gòu)發(fā)展為現(xiàn)代 Lakehouse 方法，尋求一個(gè)通用框架來(lái)提供具有類似倉(cāng)庫(kù)語(yǔ)義（強(qiáng)類型、事務(wù)性）的近實(shí)時(shí)數(shù)據(jù) 保證和 ACID 合規(guī)性，并通過緩存、列統(tǒng)計(jì)信息、數(shù)據(jù)分區(qū)、壓縮、Clustering和排序提高查詢效率。

由于將數(shù)據(jù)從一種格式遷移到另一種格式的計(jì)算和開發(fā)人員時(shí)間成本很高，因此所選擇的指南和方向?qū)a(chǎn)生多年的重大影響。 為了減少所有未來(lái)已知和未知的風(fēng)險(xiǎn)，沃爾瑪保持對(duì)支持的格式和運(yùn)行時(shí)的所有方面的全面控制至關(guān)重要，確保在跨沃爾瑪和公共云運(yùn)行時(shí)根據(jù)需要靈活地維護(hù)、修補(bǔ)、升級(jí)和擴(kuò)展框架，以及生態(tài)系統(tǒng)中的所有查詢加速層。 這導(dǎo)致我們只選擇開源格式，以確保沃爾瑪能夠維護(hù)和貢獻(xiàn)。

我們團(tuán)隊(duì)基于以下方面評(píng)估了現(xiàn)代 Lakehouse 架構(gòu)的當(dāng)前行業(yè)標(biāo)準(zhǔn)：

在多云環(huán)境中攝取/查詢兩個(gè)關(guān)鍵工作負(fù)載的性能。 WL1（工作負(fù)載 1）無(wú)限時(shí)間分區(qū)數(shù)據(jù)，由于數(shù)據(jù)延遲到達(dá)，具有顯著扇出，< 0.1% 更新，> 99.9% 插入和 WL2（工作負(fù)載 2）主要有界基數(shù)，未分區(qū)數(shù)據(jù)寫入 > 99.999% 更新，< 0.001% 插入對(duì)底層設(shè)計(jì)選擇和架構(gòu)評(píng)審的權(quán)衡與其他財(cái)富 500 強(qiáng)公司的行業(yè)專家和技術(shù)領(lǐng)導(dǎo)進(jìn)行討論

從這項(xiàng)工作中，考慮到系統(tǒng)特征創(chuàng)建了一個(gè)加權(quán)分?jǐn)?shù)矩陣：

可用性 [3]、可恢復(fù)性和可移植性與不同版本的 Spark、執(zhí)行和查詢引擎的兼容性 [3]沃爾瑪真實(shí)世界數(shù)據(jù)集上每單位工作的成本 [3]攝取、查詢、可調(diào)優(yōu)的性能[2]，合理默認(rèn)值、遷移現(xiàn)有數(shù)據(jù)成本產(chǎn)品開發(fā)路線圖 [2] 以及沃爾瑪?shù)呢暙I(xiàn)和影響能力支持 [2]，產(chǎn)品、文檔和部署控制的穩(wěn)定性TCO [3]，基于工作成本和內(nèi)部管理因素

為簡(jiǎn)潔起見我們包含了對(duì)開源數(shù)據(jù)湖格式（如 Apache Hudi、開源 Delta 和 Apache Iceberg）的調(diào)研（兼容性、性能和總體想法）。

兼容性

獲勝者：Apache Hudi

模式演變和驗(yàn)證

今天沃爾瑪在管理支持業(yè)務(wù)所需的數(shù)據(jù)管道總數(shù)方面有巨大的開銷。 使我們的業(yè)務(wù)現(xiàn)代化和發(fā)展所需的數(shù)千個(gè)應(yīng)用程序更改導(dǎo)致模式管理復(fù)雜性進(jìn)一步加劇了這種情況。了解和管理這些架構(gòu)演變的兼容性對(duì)于構(gòu)建強(qiáng)大的 Lakehouse 至關(guān)重要。 此外至關(guān)重要的是 Lakehouse 中的無(wú)效模式演變必須在源頭上迅速解決，并盡可能在源頭上解決。

Lakehouse 平臺(tái)在寫入時(shí)強(qiáng)制執(zhí)行模式以緩解讀取兼容性問題，從而避免將發(fā)現(xiàn)和報(bào)告錯(cuò)誤的責(zé)任放在消費(fèi)系統(tǒng)上。 此外如果在讀取發(fā)現(xiàn)故障之前寫入了大量數(shù)據(jù)，則可能會(huì)導(dǎo)致數(shù)據(jù)丟失和/或昂貴且耗時(shí)的恢復(fù)。 通過在寫入時(shí)驗(yàn)證模式，Hudi、Delta 和 Iceberg 消除了大部分?jǐn)?shù)據(jù)不兼容問題，但 Lakehouse 寫入端仍然需要處理來(lái)自上游數(shù)據(jù)源的無(wú)效和不可映射的模式。 許多這些上游模式問題無(wú)法通過 Lakehouse 格式來(lái)解決，需要通過靈活的模式管理或?qū)ι嫌卧磸?qiáng)制執(zhí)行模式演化規(guī)則來(lái)全面解決。

Iceberg 的模式演化方法是最靈活的，允許潛在上游模式格式，支持 Protocol Buffers、Avro 和 Thrift 中最有效的模式演化場(chǎng)景。 Hudi 和 Delta 支持 Avro兼容的模式演變，但缺乏列重命名能力， Protocol Buffers 和 Thrift 消息的二進(jìn)制表示中支持該 Schema Evolution。 這要求沃爾瑪在這些類型的管道進(jìn)入我們的 Lakehouse 時(shí)對(duì)其實(shí)施限制。 在處理流數(shù)據(jù)時(shí)，模式演變必須在管道和查詢不停止的情況下進(jìn)行處理，排除允許任何向后不兼容的破壞性變更的可能性。

在寫入上游數(shù)據(jù)源時(shí)驗(yàn)證模式有助于緩解這個(gè)問題，但是由于沃爾瑪中很大一部分流數(shù)據(jù)是使用 JSON 編碼的“代碼模式”，遷移路徑將很長(zhǎng)。 由于可能發(fā)生不支持的模式變更、對(duì)運(yùn)維（工具和監(jiān)控）的投入、以及對(duì)數(shù)據(jù)所有者的培訓(xùn)以及對(duì)上游授權(quán)的長(zhǎng)期投資，沃爾瑪?shù)南?lái)源堅(jiān)持通過統(tǒng)一模式管理更改注冊(cè)表。

出于同樣的原因，所有 Lakehouse 表格式僅支持向后兼容，以支持未來(lái)進(jìn)行重大更改。表格式架構(gòu)更改很少見，但讀取端可能需要在遷移表之前進(jìn)行升級(jí)。

引擎支持

沃爾瑪數(shù)據(jù)使用多種引擎進(jìn)行查詢：Hive 和 Spark、Presto / Trino、BigQuery 和 Flink。 支持這些引擎的本地讀取/寫入端對(duì)于減少現(xiàn)有客戶遷移到新 Lakehouse 非常重要。 此表列出了沃爾瑪使用引擎的程度以及每個(gè)產(chǎn)品對(duì)該引擎的支持。

架構(gòu)與設(shè)計(jì)

性能的改進(jìn)是沃爾瑪著手研究表格格式變化的主要原因。 Hudi、Delta 和 Iceberg 都以性能為中心，雖然如下表所示每種系統(tǒng)方法存在差異，但它們的功能可以分為并發(fā)、統(tǒng)計(jì)、索引、托管和重組。

性能

獲勝者：Apache Hudi

攝取性能

批處理和流式攝取基準(zhǔn)測(cè)試在兩個(gè)難以滿足業(yè)務(wù)延遲 SLA 的真實(shí)世界工作負(fù)載上執(zhí)行。 這兩個(gè)關(guān)鍵的內(nèi)部工作負(fù)載被稱為 WL1 和 WL2。 WL1（批處理）是一個(gè)典型的基于時(shí)間的表，按年、月、日、小時(shí)分區(qū)，并且存在大量延遲到達(dá)的記錄，導(dǎo)致 Spark 攝取在許多分區(qū)中遭受顯著的讀/寫放大。 沒有分區(qū)的 WL2（流式傳輸）維護(hù)行級(jí)更新到有界數(shù)據(jù)集，低延遲數(shù)據(jù)通過從多 Cassandra 表捕獲更改數(shù)據(jù)。

WL2 模式已成為沃爾瑪維持對(duì)有界操作數(shù)據(jù)集上的低延遲數(shù)據(jù)湖表的業(yè)務(wù)需求的關(guān)鍵模式

所有測(cè)試構(gòu)建了完全隔離的環(huán)境，以避免互相影響。 然后部署每個(gè)攝取作業(yè)（Delta、Hudi、Iceberg、Legacy）并留出足夠的時(shí)間達(dá)到穩(wěn)定狀態(tài)。 中值批攝取時(shí)間是在一組合理的批次 (n > 30) 上測(cè)量的，并在所有攝取核心之間進(jìn)行歸一化以確定加權(quán)分?jǐn)?shù) [時(shí)間 * GB 攝取] / 核心（最低分?jǐn)?shù)最好）。 執(zhí)行壓縮時(shí)，通過使用外部 Spark 應(yīng)用程序異步執(zhí)行或在內(nèi)部作為內(nèi)聯(lián)（阻塞）隔離壓縮，并從壓縮階段進(jìn)行測(cè)量，從而計(jì)算出與標(biāo)準(zhǔn)攝取類似的指標(biāo)。

WL1 的結(jié)果表明，與現(xiàn)有的 ORC 處理管道相比，攝取性能顯著提高，性能加速超過 5 倍，性能最高的是運(yùn)行在 Spark 3.x 上的 Hudi。 對(duì)于 WL2 流攝取性能在 Delta 上快了 27%，但是 Hudi 的壓縮速度顯著加快，因?yàn)閼?yīng)用程序執(zhí)行壓縮并且缺少在 Delta 管道中執(zhí)行的 Z-Ordering（在測(cè)試時(shí) Hudi 尚不支持異步排序）。 這種額外的效率使 Delta 中的查詢性能顯著提高了查詢性能。

Delta WL2 模式——攝取困難

攝取作業(yè)——由目標(biāo)分區(qū)文件和要處理的記錄的全局混洗組成——150 核（6 小時(shí)以上且未完成）

Reader具有干凈緊湊的數(shù)據(jù)視圖（無(wú)需合并日志以進(jìn)行實(shí)時(shí)查看）但是隨著基數(shù)的增加，合并變得更加昂貴

由于全局洗牌的成本和不斷增長(zhǎng)的數(shù)據(jù)大小，Delta 寫入無(wú)法有效地處理數(shù)據(jù)。 我們嘗試了一種替代架構(gòu)來(lái)將數(shù)據(jù)附加到表中并運(yùn)行后臺(tái)（異步 - 非阻塞壓縮）但是 Delta 的架構(gòu)下這些操作并不能成功完成。

攝取作業(yè)——由 2 個(gè)作業(yè)組成，一個(gè)僅附加流作業(yè)和一個(gè)異步 cron 計(jì)劃壓縮。 由于多個(gè)寫入端修改相同的文件而失敗。

Reader通過讀取重復(fù)項(xiàng)并在數(shù)據(jù)上應(yīng)用窗口來(lái)消除重復(fù)記錄。

Hudi WL2模式

在測(cè)試中具有同步或后臺(tái)壓縮的 Hudi MOR（讀取時(shí)合并）表是唯一能夠處理這種模式的開放文件格式，確保最新的寫入和清理的視圖可供數(shù)據(jù)消費(fèi)者使用。

攝取作業(yè)——具有文件組映射的行鍵，降低了連接操作的復(fù)雜性——150 核（~15 分鐘批處理/50 分鐘壓縮）

Reader——可以選擇壓縮（避免更改日志視圖）或性能較慢的實(shí)時(shí)視圖。 定期壓縮將日志合并到各自的文件組中

查詢性能

選擇了常見的業(yè)務(wù)查詢模式，并為工作負(fù)載 1 命名為 Q1-Q7，為 WL2 命名為 Q1-Q10。 這些模式包括：

表數(shù)聚合分區(qū)計(jì)數(shù)主鍵計(jì)數(shù)計(jì)算基于分區(qū)的主鍵基于主鍵查詢基于主鍵和分區(qū)的查詢基于數(shù)據(jù)集字段查詢基于數(shù)據(jù)集字段和分區(qū)的查詢主鍵上的 2 表連接主鍵上的 3 表連接

盡管 Delta 在大多數(shù)查詢中有大約 40% 的最佳性能，但在將交易實(shí)時(shí)數(shù)據(jù)之上的 Delta 視圖與 Hudi RT 視圖進(jìn)行比較時(shí)情況不同，其中 Hudi 在提供去重（最新記錄視圖）方面明顯更快。 Delta 的一個(gè)顯著性能優(yōu)勢(shì)在于記錄的 ZOrdering，這可以加速表中的大多數(shù)查詢。ZOrdering 現(xiàn)在可用于 Hudi 以及文件組元數(shù)據(jù)管理方面的改進(jìn)。 這將使基準(zhǔn)更加接近。

圖 3 和圖 4 是對(duì)所測(cè)試的三種 Lakehouse 技術(shù)的查詢和攝取性能的總結(jié)。 需要考慮的是，Hudi 通過比 Delta 更復(fù)雜的配置提供了顯著的性能優(yōu)化。 在我們測(cè)試時(shí)，“開箱即用”的 Delta 默認(rèn)配置得到了顯著優(yōu)化，并且需要更少的框架知識(shí)。

總體而言

獲勝者：Apache Hudi

根據(jù)沃爾瑪?shù)恼{(diào)研，考慮到在可用性、兼容性、成本、性能、路線圖、支持和 TCO 方面的加權(quán)矩陣的最終得分，沃爾瑪選擇 Apache Hudi 來(lái)支持我們的下一代 Lakehouse。 此外值得注意的是最終決策受到高度多樣化的技術(shù)棧的巨大影響，在沃爾瑪?shù)膬?nèi)部云、谷歌和 Azure 中擁有超過 60 萬(wàn)個(gè) Hadoop 和 Spark 核。這些工作負(fù)載還運(yùn)行在大量 Spark 發(fā)行版和版本中。 Apache Hudi 是唯一一個(gè)兼容2.4.x Spark版本，讓我們?cè)邶嫶蟮纳鷳B(tài)系統(tǒng)中具有更大的靈活性和采用率。

沃爾瑪已經(jīng)著手進(jìn)行重大轉(zhuǎn)型，已經(jīng)開始遷移一些關(guān)鍵工作負(fù)載。 同時(shí)領(lǐng)域正在迅速發(fā)展，沃爾瑪將不斷重新評(píng)估該領(lǐng)域的最新技術(shù)，為這些開源做出貢獻(xiàn)，推動(dòng)它們滿足我們復(fù)雜的業(yè)務(wù)需求，并確?；バ屡f倉(cāng)儲(chǔ)技術(shù)之間的互操作性。

沃爾瑪平臺(tái)團(tuán)隊(duì)廣泛利用開源技術(shù)，因此重點(diǎn)是僅評(píng)估開源數(shù)據(jù)湖格式。 我們并沒有主要關(guān)注企業(yè)產(chǎn)品。 考慮到這一點(diǎn)，我們選擇了 Apache Hudi 來(lái)推動(dòng)我們的 Lakehouse 模式向前發(fā)展。 來(lái)幫助世界上最大的公司進(jìn)行轉(zhuǎn)型發(fā)展，支持創(chuàng)建最大的 Lakehouse 之一

注意：這個(gè)領(lǐng)域正在迅速變化，本博客中的一些發(fā)現(xiàn)和結(jié)果可能在發(fā)布時(shí)已經(jīng)過時(shí)。 本文測(cè)試的版本為 Delta Core 1.0.0、Apache Iceberg 0.11.1、Apache Hudi 0.10.1