沃爾瑪系統產生了世界上最大和最多樣化的資料集之一，每天資料增長超 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