開放式湖倉是湖倉一體架構的最終歸宿

由於現有架構中的數據倉庫和數據湖有著各種各樣的問題，湖倉一體架構就應運而生了，接下來我們來看看什麼是湖倉一體。

湖倉一體是什麼

Databricks 公司在 CIDR 2021 發表論文首次正式提出了 Lakehouse 的概念 ，但實際上湖倉一體的概念並非由單一個體提出，而是隨著技術的發展和需求的變化逐漸形成的，下圖分別列舉了國外主流廠商對 Lakehouse 的理解。

與"湖 + 倉"混合架構簡單地把數據湖和數據倉庫進行簡單的堆積不同，湖倉一體架構（Lakehouse）是一種新興的數據架構，將數據湖和數據倉庫的特點融合在一起。它旨在解決傳統數據湖和數據倉庫各自的局限性，並提供更強大的數據管理和分析能力。湖倉一體架構的特點如下：

• 統一數據存儲：湖倉一體架構將結構化、半結構化和非結構化數據以原生格式存儲在數據湖中。這種統一的數據存儲方式消除了數據複製和轉換的需求，簡化了數據管理過程。
• 事務支持：與傳統的數據湖相比，湖倉一體架構提供了事務支持。它允許在數據湖中執行事務操作，如插入、更新和刪除，確保數據的一致性和可靠性。
• 數據質量和治理：湖倉一體架構注重數據質量和治理。它提供了數據血緣追蹤、數據質量監控和數據訪問控制等功能，確保數據的準確性、完整性和安全性。
• 實時和批處理：湖倉一體架構支持實時和批處理數據處理。它可以處理實時數據流和大規模批量數據，並提供實時分析和即席查詢的能力。
• 彈性和可擴展性：湖倉一體架構具有彈性和可擴展性。它可以根據需求自動擴展計算和存儲資源，以適應不斷增長的數據量和變化的工作負載。

湖倉一體架構通過將數據湖和數據倉庫的優勢結合起來，提供了更靈活、可擴展和強大的數據管理和分析能力。它適用於各種數據場景，包括實時分析、機器學習、數據探索和報表等。

傳統數據倉庫和數據湖的老玩家，演進到湖倉一體架構有兩個主要方向：一是「湖上建倉」，即在數據湖的基礎上構建數據倉庫，保留數據湖的靈活性和可擴展性，同時引入數據倉庫的治理和分析能力，典型的例子是 Databricks 和開源 Hadoop 體系；二是「倉外掛湖」，即在數據倉庫外部掛載數據湖，讓數據湖成為數據倉庫的一個數據源，以便企業更好地利用數據湖中的數據，典型的例子是 Amazon Redshift、Google BigQuery、阿里雲 MaxCompute。由此可見，湖倉一體技術的發展，旨在融合數據湖和數據倉庫的優勢，形成一種更強大、靈活且易於管理的數據管理架構。通過湖倉一體，企業可以更好地處理和分析各種數據類型，實現數據價值的釋放，因此湖倉一體架構已經成為當代大數據平台的事實標準。

湖倉一體發展趨勢

隨著用戶場景和業務需求的不斷變化，湖倉一體架構在發展過程中也出現了新的趨勢。Dremio 在 2023 年發表的論文《The Data Lakehouse: Data Warehousing and More》中，提出 Lakehouse 是一個與具體實現無關的模塊化湖倉一體架構：

模塊化的湖倉一體架構，核心模塊包括以下幾個方面：

• 數據存儲（Data Storage）：使用雲對象存儲來保存原始數據文件，需要能夠高效地存儲大量來自不同來源的數據。
• 存儲引擎（Storage Engine）：負責處理數據管理任務，如數據壓縮、重分區和索引等。存儲引擎通過優化數據的組織方式，提高查詢性能，並確保數據在雲對象存儲中的高效存儲。
• 文件格式（File Format）：它將原始數據以特定的格式存儲在對象存儲中。數據湖倉使用開放的文件格式（如 Apache Parquet、ORC 等），這些格式具有高效的壓縮和查詢性能，並且可以被不同的分析引擎使用。
• 表格格式（Table Format）：表格格式是數據湖倉的一個重要組件，它在數據湖上添加了邏輯模型和可靠的數據治理。表格格式簡化了數據文件的組織和管理，並提供了元數據管理和數據版本控制的功能。常見的表格格式包括 Apache Iceberg、Apache Hudi 和 Delta Lake 等。
• 計算引擎（Compute Engine）：計算引擎負責處理數據操作和計算任務，它與表格格式進行交互，實現數據的查詢、轉換和分析等功能。Lakehouse 可以支持多種計算引擎，如 Apache Spark、Presto 等。
• 元數據服務（Catalog）：用於管理數據湖中的表格信息和元數據，它跟蹤每個表格的名稱、模式和其他相關信息，提供了數據發現和搜索的功能。

模塊化的設計讓湖倉一體架構更加清晰和可解釋，這個觀點與 Voltron Data（開源項目 Apache Arrow 背後的商業公司）提出的 Composable Codex 不謀而合。

Voltron Data 聯合 Meta 和 Databricks 發表在 VLDB 23 上的論文《The Composable Data Management System Manifesto》指出，不僅模塊化是數據系統的正確發展方向，基於開放標準和開源模塊構建的數據系統才是未來，可以帶來很多好處：

• 提高靈活性和可擴展性：模塊化的設計可以將數據計算引擎拆分為多個組件，使得每個組件可以獨立開發、維護和優化。這樣可以提高系統的靈活性和可擴展性，使得引擎可以適應不同的工作負載和需求。
• 促進互操作性：開放標準可以使不同的數據計算引擎之間實現互操作性，使得它們可以無縫地集成和協同工作。這樣可以避免數據孤島的問題，提高數據生態系統的整體效率和一致性。
• 降低開發和維護成本：模塊化的設計和開放標準可以促進組件的重用和共享，減少重複開發的工作量。同時，開放標準可以吸引更多的開發者和廠商參與，形成一個龐大的社區，共同推動引擎的發展和優化，從而降低開發和維護的成本。
• 促進創新和進步：模塊化的設計和開放標準可以為不同的開發者和廠商提供一個共同的平台，使他們可以自由地創新和實驗新的功能和技術。這樣可以推動數據計算引擎的不斷進步，滿足不斷變化的需求和挑戰。

開放式湖倉才是未來

傳統數據倉庫對用戶最大的困擾是很容易被運營商鎖定（Vendor Lock-in），通常有以下幾個原因：

• 專有技術和格式：傳統數據倉庫通常使用特定廠商的專有技術和格式。這些技術和格式是特定廠商的商業機密，不公開或不兼容其他廠商的系統。因此，一旦選擇了特定廠商的數據倉庫解決方案，就會受到其技術和格式的限制，難以無縫地遷移到其他廠商的解決方案。另外，有一些開源項目使用了自有文件格式來存儲數據，雖然原始碼開源的，但其文件格式沒辦法被其他主流計算引擎理解，仍然不屬於開放式的架構設計。
• 閉源軟體：傳統數據倉庫通常使用閉源的商業軟體，用戶無法查看或修改其內部實現細節。這意味著用戶對軟體的定製和擴展能力受到限制，只能依賴於特定廠商提供的功能和更新。
• 依賴特定硬體和作業系統：傳統數據倉庫可能依賴於特定的硬體和作業系統。這意味著用戶需要購買和維護特定的硬體設備，並且只能在特定的作業系統上運行數據倉庫。這增加了用戶的成本和依賴性，限制了他們在硬體和作業系統選擇上的靈活性。
• 高度集成的架構：傳統數據倉庫通常採用高度集成的架構，將數據存儲、計算和查詢等功能緊密耦合在一起。這使得用戶難以將數據倉庫的不同組件替換為其他廠商的解決方案，因為這些組件之間存在複雜的依賴關係。
• 供應商鎖定策略：一些數據倉庫供應商可能採用鎖定策略，通過限制用戶的選擇和遷移選項來維持其市場份額。這可能包括限制數據遷移工具、封閉的 API 接口、高昂的許可費用等。這使得用戶難以切換到其他供應商的解決方案，從而導致供應商鎖定。

湖倉一體架構發展到今天，其最吸引人的一個特點就是就是數據開放性，這是因為其獨特的模塊化設計帶來的：

• 數據格式的靈活性：Lakehouse 架構使用開放的數據格式，例如 Parquet、Avro 或 ORC，這些格式是通用的、開放的標準。這意味著數據可以以一種獨立於特定供應商的方式存儲和處理，而不會受到特定供應商的限制。這樣，即使更換或切換供應商，數據仍然可以保持可訪問和可用。
• 開放的數據處理工具和技術：Lakehouse 架構支持使用各種開放的數據處理工具和技術，例如 Apache Spark、Apache Hive、Presto 等。這些工具和技術是開源的，可以在不同的供應商之間進行遷移和切換。這樣，即使更換供應商，組織可以繼續使用相同的數據處理工具和技術，而不需要重新學習或更換整個技術棧。
• 數據所有權和控制：在 Lakehouse 架構中，數據湖是組織自己擁有和控制的。這意味著組織可以自由地管理和操作數據，而不受運營商的限制。即使切換供應商，組織仍然可以保持對數據的完全控制，並且可以根據需要進行數據遷移或複製。
• 多雲和混合雲支持：Lakehouse 架構可以在多個雲提供商之間進行部署，或者與本地數據中心進行混合部署。這種靈活性使得組織可以根據需求選擇最適合的雲提供商，而不會受到單一供應商的限制。這樣，即使更換或切換雲提供商，數據仍然可以保持可訪問和可用。

值得一提的是，有些廠商聲稱自己是「開放式」湖倉一體架構，但所謂的「開放」實際是存算分離架構的「開放」，其實是與開放式湖倉一體混為一談。存算分離是一種大數據處理架構，它將存儲和計算節點分開，數據節點負責數據的存儲和管理，而計算任務則由單獨的計算節點來負責執行。相對於傳統的存算一體架構，存算分離架構設計使得系統能夠擴展到更大規模的並發能力和數據容量。相較於湖倉一體架構的開放數據設計，存算一體架構只是把數據放在了存儲節點上，並沒有保證數據的開放性（如使用開源表格式 Apache Iceberg，或者開源文件格式 Apache Parquet 等），因此並不能認為存算分離架構也是開放的。

隨著人工智慧（AI）和大語言模型（LLM）的熱潮，AI 給數據平台帶來新的挑戰：AI 需要更豐富的數據，數據需要更多樣的 BI+AI 應用。Data 與 AI 的關係不再是 Data+AI，而是 Data*AI ——數據平台不再是一對一的計算和存儲架構，而是 m 對 n 關係的架構。這樣的架構改變變化下，數據平台的架構更應有兼具一體化與開放性的設計。開放式湖倉一體架構，是面向 Data+AI 融合場景的新趨勢。

雲器開放式湖倉的設計理念

我們（雲器科技）是一家新興的數據平台服務提供商，主打多雲及一體化的數據平台服務。我們依照 Open Lakehouse 的設計理念，實現了一套完整的系統，並服務多家頭部客戶。存儲層設計兼容各種主流的開放存儲格式，確保與廣泛的數據環境的無縫集成：

• 開放元數據服務：採用 Catalog 形式開放，增強數據管理的靈活性和可訪問性。
• 安全的數據訪問：保障數據安全的同時，通過身份認證和鑒權機制，允許外部引擎訪問雲器 Lakehouse 中的數據文件。
• 統一安全策略與開放性結合：結合統一的安全策略與開放性，藉助豐富的開源生態系統，最大化地釋放企業數據的潛在價值。

文章前半部分講述了 Open Lakehouse 的架構優勢、設計目標和原則。文章後半部分，重點介紹我們在實現過程中的設計、取捨和經驗總結。

雲器開放式湖倉的設計實踐

擁抱 Apache Iceberg 打造開放生態

Apache Iceberg、Apache Hudi 和 Delta Lake 是當前數據湖領域中的三種主要表格式，它們都在努力成為數據湖的標準表格式，這種競爭有時被形象地稱為"Table Format War"。這三種表格式都是開源的，擁有非常好的生態，背後都有一個商業公司在支持。雲器認為重複再造一個新的表格式的輪子並不能讓 Lakehouse 更加地開放，因此選擇一個最合適的表格式，圍繞它構建 Lakehouse 的內置表格式，打造一個開放的生態是對用戶最負責任的方案。

為什麼是 Apache Iceberg

來自 Tabular（Apache Iceberg 背後的商業公司）的 Brian Olsen 在 2023 年 7 月發表了一篇文章 Iceberg won the table format war，他認為 Apache Iceberg 已經在這場表格式的競爭中取得了勝利。其觀點基本符合我們的看法，也是雲器科技選擇使用 Apache Iceberg 作為開放存儲底座的原因：

• 從技術角度來說，Apache Iceberg 是第一個跳出了 Hive 標準（比如 Hive 分區）限制的表格式，相對於 Apache Hudi 來說沒有主鍵約束，通過 Hidden Partition 的設計支持 Partition Evolution 這種高級功能。這種設計使得使用方有更大的定製空間，支持更豐富的場景。
• 從標準角度來說，Apache Iceberg 首先就制定了一套簡單、清晰的標準，然後才提供各種引擎下的實現。Apache Hudi 實現太過複雜，並且非常依賴 JVM 生態。Delta Lake 開源版本相比 Databricks 內部版本有很多滯後性，與 Apache Spark 框架綁定也比較深。有了一個簡潔的標準，用戶和廠商既可以選擇使用官方開源實現，也可以根據自己的需求開發一套完全兼容的實現，這正是一個開放的標準所帶來的好處。
• 從生態角度來說，Dremio 很早就選擇了 Apache Iceberg 作為其完全開源的 Open Lakehouse 底座。像 Snowflake 這種起初期望用其私有格式搶占市場的大玩家，也支持了 Apache Iceberg 作為可選的內置存儲格式，並且性能與內置格式相差無幾。甚至像 Databricks 和 Onehouse（Apache Hudi 背後的商業公司）這樣的直接競爭對手，也分別通過 Delta Uniserval Format 和 Hudi OneTable 的機制，輸出 Apache Iceberg 兼容格式。選擇 Apache Iceberg 能更好地避免被運營商綁定的風險，保護用戶的數據。

如何基於 Apache Iceberg 構建通用的增量存儲

雲器 Lakehouse 使用 Apache Iceberg 表格式，以及 Apache Parquet 文件格式，打造了一個能夠實時兼容 Apache Iceberg 標準的存儲文件布局，其元數據通過完全兼容 Iceberg 的 catalog 進行輸出，天然兼容所有支持消費 Apache Iceberg 的開源框架，如 Apache Spark 和 Trino 等。由於所有雲器 Lakehouse 內表輸出的數據文件都是以 Apache Parquet 格式存放在雲對象存儲上，元數據完全兼容 Apache Iceberg，用戶真正擁有自己的數據資產，無需擔心 Lock-in 的風險。

前面提到過增量計算模式依賴增量存儲，這也是通過 Apache Iceberg 實現的。具體來說，基於 Snapshot Isolation 使用 Apache Iceberg V2 標準引入的 Position Delete File 來表示增量數據。由於 Position Delete File 只能表示數據的刪除，我們需要把 Update 拆分成經典的 Delete+Insert 模式，這樣的設計對數據有三個挑戰：

• Freshness：代表數據進入 Lakehouse 的新鮮度，即數據寫入湖倉之後多久可見。為了讓數據儘快可見，我們設計了單獨的 Ingestion Service 服務，根據不同的表類型，兼顧性能和成本使用最優的方式把數據灌入湖倉。
• Latency：代表數據的查詢性能，也就是查詢湖倉中的數據要多久才能出結果。由於數據文件都保存在雲對象存儲上，我們設計了 Shared-Everything 的分層 Cache 服務，根據數據的冷熱以及訪問模式，自動將文件中的數據放到最合適的 Cache 中，加快查詢速度。
• Performance：增量計算的間隔越短，就會以增量存儲的方式引入越多的小文件，這對後續查詢的性能會帶來影響。同時，用戶的數據和訪問模式後續都可能會動態變化，我們需要能夠識別並給出存儲文件排布的最佳方案。因此，寫入增量存儲的時候，我們可以根據需要，自動選擇以 Copy-on-Write 或者 Merge-on-Read 的方式產生數據文件。同時，在後台使用單獨的 Compaction 服務，根據 Lakehouse 搜集到的信息進行文件的重排布，以節省成本，優化查詢性能。

圍繞 Apache Parquet 錘鍊極致性能

對於 Lakehouse 的引擎來說，一個 SQL 查詢始於讀（TableScan）終於寫（TableSink）。如果說開放的表格式決定了 Lakehouse 的能力下限，那合適的文件格式則可以決定 Lakehouse 的性能上限。在大數據領域，Apache Parquet 和 Apache Orc 基本就是列存格式的實施標準。兩者曾一度各占半壁江山，但現在就像 DuckDB 作者 Hannes 回答社區問題時說的，似乎 Apache Orc 已經被用得越來越少了。那在 Apache Parquet 越來越獨領風騷的今天，是不是無腦選擇它就能高枕無憂了？

事實並非如此，Parquet 標準其實是一個基於 Thrift 協議定義的文件格式，其中包含很多可選的欄位，這為後面的問題埋下了伏筆：

• 由於早期 Parquet 開原始碼的糟糕實現，各個引擎和框架都開始從頭寫自己的 Parquet Reader/Writer，它們都根據自己的需要，只使用了 Parquet 標準中一部分欄位，這對不同引擎之間 Parquet 文件的互操作性帶來了問題，系統 A 因為用了某個更高級的欄位，系統 B 沒有實現它，導致 B 無法直接消費 A 產生的文件。
• 不同的 Parquet 實現有不同的 bug，而用戶持久化的文件無法重寫，這進一步導致不同引擎需要打上各種補丁，從有問題的歷史 Parquet 文件中讀出正確的數據。
• 再就是臭名昭著的 Parquet V2 爭論。Apache Parquet 社區先是引入了一個 Data Page V2 的概念，用來支持對某一列的某個 Page 進行更細粒度的壓縮和編碼控制，這沒有問題。但後續又引入了一個 Feature V2 的概念，把所有新加入的功能如 Page Index、Bloom Filter、Delta Encoding、Byte Stream Split Encoding 等，都稱做 V2 功能。這樣一來，有的實現認為 Data Page V2 才是 V2，其他則認為只要用了某個 V2 功能也叫 V2，導致對如何判斷一個 Parquet 文件是不是 V2 版本沒有一個共識。所以很多企業為了規避這個問題，直接禁用 V2 的任何功能。

儘管 Parquet 有各種各樣的問題，它仍然是當前大數據文件格式的事實標準，在開放存儲這個大前提下，也沒有什麼好糾結的。既然 Parquet 是開源的，是不是挑一個開源實現拿來用就好了？很多引擎和框架都實現了自己的 Parquet 讀寫模塊，但由於前面提到的問題，要麼功能不全，要麼性能不佳，基本沒有能直接拿來用。早在雲器 Lakehouse 選型文件格式的時候（2022 年初），C++ 的開源 Parquet 實現只有 Apache Arrow、Apache Impala 和 DuckDB 三家，其中後兩者都只實現了 V1 的功能；而 Apache Arrow 中的 Parquet C++ 代碼是 Parquet 社區捐贈的，V2 的功能也實現了一部分，但仍然缺少 Predicate Pushdown、Page Index 和 Bloom Filter 等重要功能，並且內部測評的性能也不及預期，無法直接使用。

Community Over Code

縱觀國外的一些友商，Velox 和 Databricks 開發了自己的 Native C++ Parquet 實現，而 Snowflake、BigQuery 和 ClickHouse 則都是基於 Apache Arrow 中的 Parquet C++ 實現來完成 Parquet 的拼圖。雖然從頭開發一套 Parquet 實現的確能夠獲得最佳的定製和性能，但也需要付出大量重複勞動，也可能會掉進一些前人踩過的坑。既然 Apache Parquet 是一個開源的標準，沒有任何秘密，而 Apache Arrow 已經被友商廣泛使用，那直接基於 Apache Arrow 中的 Parquet 代碼來實現雲器 Lakehouse 的文件格式，也符合雲器 Lakehouse 追求最佳開放性的設計理念。與此同時，雲器科技也決定投入到社區當中，補全 Parquet 缺失的功能，並且深度優化性能，從而真正成為社區的一部分。

主要貢獻

雲器科技對 Parquet 社區的貢獻，主要涉及了 Apache 軟體基金會旗下兩個頂級項目 Apache Parquet 和 Apache Arrow 的三個 GitHub 倉庫：

• apache/parquet-format：Parquet 格式規範，所有的實現必須遵循此規範。參與該項目可以影響格式標準的後續發展，把對雲器有益的格式演進推回社區，從而讓更多用戶受益。
• apache/parquet-mr：Parquet 的 Java 語言實現，是以 Java 生態為主的大數據開源生態圈依賴最廣泛的 Parquet 實現。它也被認為是 Parquet 最權威的實現，其他語言的實現在拿不準的時候，都會參照它來統一行為。參與該社區，可以讓雲器 Lakehouse 寫出的 Parquet 文件，能被所有 Java 生態的開源框架（如 Apache Spark、Apache Hive、Trino）直接消費，達到最大的開放性。
• apache/arrow：Apache Arrow 項目的核心是一種基於內存的列式數據結構，這是一種與語言無關的標準化規範，使得數據可以在不同的程式語言和計算引擎之間以零複製（zero-copy）的方式進行共享和交換，同時提供了一套比較乾淨和功能最多的 Parquet C++ 實現。雲器 Lakehouse 的 Parquet 正是基於這套代碼進行功能開發和性能優化，使其達到一個比較理想的狀態。

上面兩張圖基本涵蓋了雲器科技在 Parquet 社區中最主要的貢獻，團隊兩名成員也因此被 Apache Parquet 和 Apache Arrow 社區提名為 Committer。雲器科技對開源社區的投入不會停止，團隊成員在 2023 年 8 月北京舉行的「Apache Software Foundation 旗下大會 - Community Over Code Asia 2023」上分享了參與開源項目的心得，後續仍會深耕社區，把我們認為有價值的功能貢獻回社區，讓更多的用戶受益。

總 結

本文回顧和分析了數據湖倉的歷史和大數據平台的演進趨勢，提出了基於增量計算的一體化趨勢，以及該架構必然需要一個開放式的增量存儲支撐。基於 Single Engine · All Data 理念雲器發布了一體化數據平台——雲器 Lakehouse，並分享了如何圍繞 Apache Iceberg 和 Apache Parquet，來構建開放湖倉之上的增量存儲，獲得最佳開放性和極致性能。同時雲器科技也大力投入開源社區，以合作共贏的姿態踐行構建 Open Lakehouse 的設計理念。

作者簡介：

吳剛，雲器科技，Lakehouse 技術專家。目前是 Apache ORC 的 PMC，也是 Apache Arrow 和 Apache Parquet 的 committer。在此之前，曾是阿里巴巴的高級技術專家，負責 MaxCompute 的存儲系統，也曾在 Uber 負責 Apache Spark 平台。

選擇哪種程式語言已經不重要了，只提倡程式設計師下班後「多看看書」提升競爭力是誤人子弟｜獨家專訪亞馬遜 CTO

一代更比一代強，AI 時代的至強如何為雲服務保駕護航？

尋找增長，SaaS 企業選擇上飛書

離開雲轉戰 AI？23 歲寫了百萬人用的開源軟體，這個 IT 奇才 11 年後離開了自己的上市公司