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

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

(資料圖片)

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

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

我們團隊基于以下方面評估了現(xiàn)代 Lakehouse 架構(gòu)的當前行業(yè)標準：

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

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

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

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

兼容性

獲勝者：Apache Hudi

模式演變和驗證

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

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

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

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

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

引擎支持

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

架構(gòu)與設計

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

性能

獲勝者：Apache Hudi

攝取性能

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

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

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

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

Delta WL2 模式——攝取困難

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

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

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

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

Reader通過讀取重復項并在數(shù)據(jù)上應用窗口來消除重復記錄。

Hudi WL2模式

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

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

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

查詢性能

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

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

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

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

總體而言

獲勝者：Apache Hudi

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

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

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

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