每日視訊：日增數據超10PB！揭秘沃爾瑪Lakehouse架構選型之路

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

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

(資料圖片)

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

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

我們團隊基于以下方面評估了現代 Lakehouse 架構的當前行業標準：

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

從這項工作中，考慮到系統特征創建了一個加權分數矩陣：

可用性 [3]、可恢復性和可移植性與不同版本的 Spark、執行和查詢引擎的兼容性 [3]沃爾瑪真實世界數據集上每單位工作的成本 [3]攝取、查詢、可調優的性能[2]，合理默認值、遷移現有數據成本產品開發路線圖 [2] 以及沃爾瑪的貢獻和影響能力支持 [2]，產品、文檔和部署控制的穩定性TCO [3]，基于工作成本和內部管理因素

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

兼容性

獲勝者：Apache Hudi

模式演變和驗證

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

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

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

在寫入上游數據源時驗證模式有助于緩解這個問題，但是由于沃爾瑪中很大一部分流數據是使用 JSON 編碼的“代碼模式”，遷移路徑將很長。 由于可能發生不支持的模式變更、對運維（工具和監控）的投入、以及對數據所有者的培訓以及對上游授權的長期投資，沃爾瑪的消息來源堅持通過統一模式管理更改注冊表。

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

引擎支持

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

架構與設計

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

性能

獲勝者：Apache Hudi

攝取性能

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

WL2 模式已成為沃爾瑪維持對有界操作數據集上的低延遲數據湖表的業務需求的關鍵模式

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

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

Delta WL2 模式——攝取困難

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

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

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

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

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

Hudi WL2模式

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

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

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

查詢性能

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

表數聚合分區計數主鍵計數計算基于分區的主鍵基于主鍵查詢基于主鍵和分區的查詢基于數據集字段查詢基于數據集字段和分區的查詢主鍵上的 2 表連接主鍵上的 3 表連接

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

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

總體而言

獲勝者：Apache Hudi

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

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

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

注意：這個領域正在迅速變化，本博客中的一些發現和結果可能在發布時已經過時。 本文測試的版本為 Delta Core 1.0.0、Apache Iceberg 0.11.1、Apache Hudi 0.10.1