從技術競爭到生態共創——開放資料架構正在經歷從各自為政到協同演進的根本性轉變，而這種轉變的核心驅動力不僅是技術本身，而是社群治理模式的成熟。
——編者按
每年 6 月的舊金山，Snowflake Summit 與 Databricks Data+AI Summit 如雙子星般閃耀，既是資料與 AI 行業的風向標，又是科技巨頭秀肌肉的頂級舞臺。作為今年 Data + AI Summit 2025 的一部分，我有幸在舊金山的 Marriott Marquis 酒店先參與了一場更為“神秘”和特別的技術峰會——Open Lakehouse Mini Summit。想在分享具體的技術乾貨之前，先和大家聊聊這場會議獨特的“畫風”。
說它獨特，首先是因為這不是一場對公眾開放的會議，而是在 Databricks 的協助和組織下，專門面向全球各大主流資料開源社群核心貢獻者、Committer 和 PMC 成員的閉門邀請制（invite-only）峰會。你可以想象一下這個場面：來自 Apache Spark, Delta Lake, Apache Iceberg, Unity Catalog, Apache Polaris, Apache Arrow 等專案的“核心大腦”們齊聚一堂。這感覺不像一個傳統會議，更像是一場資料江湖的“華山論劍”。
其次，它的會議形式也極具特色。全天沒有任何冗長的 PPT 演講，取而代之的是四個分會場裡、緊鑼密鼓的圓桌討論。每一場都由一位核心維護者用最多 15 分鐘做引子，丟擲最具爭議或最前沿的話題，剩下的超過半小時則留給所有人進行深入、激烈的現場討論。
更關鍵的是，為了鼓勵最真實、最坦誠甚至充滿火藥味的觀點碰撞，所有討論都全程閉門，不設任何錄音錄影。在這種絕對安全的環境下，大家可以毫無保留地探討各個專案的未來路線圖、技術方案的利弊，甚至直接“挑戰”彼此的設計。
正是因為這種獨特的設定，這次會議的討論深度和廣度都遠超常規的技術大會，資訊量極大。為了讓大家對峰會的討論廣度有個更直觀的瞭解，我根據官方日程整理了當天的完整議題表。你可以看到，四個會場同時進行，議題覆蓋了從底層引擎、儲存格式到上層目錄和 AI 應用的方方面面，幾乎囊括了當前資料技術棧所有熱門和前沿的方向。
正如你所看到的，每個時間段都有多個極具吸引力的話題在同時進行，真是讓人分身乏術，充滿了選擇的“痛苦”。我主要參加了 Lakehouse 相關（主要是 Iceberg）的話題討論，所以接下來的內容，我將按照 Iceberg 的現在和未來，結合現場和社群小夥伴們聊天獲得的一手資訊，分享那些最前沿的觀點和讓我深受啟發的思考。
會場爆滿的實況（我就在右下角那一桌，頭剛好被 Apache Parquet PMC Chair Julien Le Dem 給擋住）
2025 年 6 月，Apache Iceberg 社群釋出了 V3 表格式規範。這不僅是技術的迭代，更是資料生態從分裂走向統一的關鍵一步。長期以來，使用者不得不在多個 table format 之間艱難抉擇，而 V3 透過標準化企業級功能與跨格式相容性，首次實現無需重寫資料即可跨引擎操作——這標誌著開放資料生態的質變。
2025 年 5 月 23 日社群投票透過 Iceberg V3 標準
下面列出了 Iceberg V3 標準引入的新功能，完整變更請查閱社群官方文件。
正如 Databricks 博文所述，Iceberg V3 的核心突破在於“實現 Delta Lake、Apache Parquet 與 Apache Spark 間的深度互操作性”。這背後是多個社群史無前例的技術協同：
-
刪除向量（由 Databricks 貢獻）採用與 Delta Lake 完全相同的二進位制編碼，使得 Spark 或 Flink 引擎可直接讀取彼此修改的資料表，終結了傳統表格式的引擎割據；
-
行級血緣機制（由 Snowflake 貢獻）與 Delta Lake 的行追蹤設計相容，讓變更資料流能在 Delta 與 Iceberg 表間自然流動；
-
Variant 與地理空間型別在 Parquet 儲存層的標準化（雲器科技深度參與其中），使半結構化資料和空間查詢得以跨引擎原生支援。
這場協作的本質，是以開放標準取代私有實現——正如博文結語所強調的：“避免使用者被迫選擇格式，實現在單一資料副本上的自由操作”。
雲器科技作為 Iceberg 的 Variant 與地理空間標準制定的全程深度參與者，我親身經歷了開放生態中技術共識達成的艱難與價值。
Iceberg 社群最初計劃直接依賴 Spark 的 Variant 實現，並把 Variant 標準放到 Iceberg 中時，我們預見到潛在的社群割裂風險，極有可能導致不同表格式、檔案格式和引擎研發出自己封閉的標準。為此，我們主動牽頭髮起 Iceberg、Spark、Parquet、Arrow 等社群的技術討論，推動將 Spark 的實現捐贈給 Parquet 社群。這一決策並非程式碼遷移那麼簡單，而是達成多方共識將私有技術轉化為公共規範。
我在郵件列表上提出異議，是 Variant 標準最終落戶 Parquet 社群的轉折點
雲器科技（Singdata）因為深度參與了 Variant 型別的標準制定，在 2025 年 4 月的 Iceberg Summit Keynote 演講中被 Ryan Blue 提及，與多家全球知名廠商並列：
Ryan Blue 在 Iceberg Summit 2025 Keynote 上提到了 Singdata
地理空間作為一個 domain knowledge 比較深的專業領域，至今各個資料庫和大資料廠商都沒有統一的標準和實現。Iceberg 和 Parquet 社群關於地理型別的統一堪稱跨社群治理的經典案例：
-
我們聯合 Apache Sedona（空間計算）、GeoParquet（儲存標準）、Apache Iceberg 和 Apache Parquet 等社群，以及各個資料廠商如 Snowflake、Databricks、BigQuery、AWS、Wherobots、Apple，成立工作組，直面核心衝突（如統一還是單獨資料型別、座標系表達方式、不同索引支援方式等）；
-
歷時九個月，透過多次技術會議協調，最終敲定二進位制儲存協議（擴充套件 WKB 格式）與座標系嵌入規則，並由我主筆完成 Parquet 格式規範（https://github.com/apache/parquet-format/pull/240）的編寫；
-
該標準實現了儲存層和引擎層的統一，使空間查詢能穿透格式邊界下推執行。
我在 Parquet 標準中加入地理空間型別的 PR，經過多輪討論和修改，歷時九個月終於被合併
真正的互操作性誕生於會議室和技術討論而非（開源）程式碼庫。當社群和廠商放下技術偏好，以使用者資料自由為最高目標時，Delta 與 Iceberg 的二進位制相容、Variant 的 Parquet 層抽象等突破才成為可能。正如我們常聽到的：“好的標準如同氧氣——只有當它缺失時，你才會意識到其不可或缺”。這或許正是 Iceberg V3 留給資料生態的最大遺產：技術終會迭代，但開放治理的正規化將長存。
雖然 Iceberg V3 才剛剛定版沒多久，社群成員們也沒有閒著，已經在著手進行下一個版本也就是 Iceberg V4 的籌劃。在 Databricks 收購 Tabular 之後，Iceberg V3 已經統一了 Iceberg 和 Delta Lake 的 data layer，這次閉門會同時也邀請到了 Delta Lake 的核心研發，一起合作討論未來的演進方向。由於現在還在討論的初期，現場大家基本都是分享一些初期目標和可能遇到的問題，離真正進入技術方案的設計還有一定距離。
Iceberg 最初的兩位作者 Ryan Blue 和 Daniel Weeks 在現場發起 Iceberg V4 元資料演進的討論
Apache Iceberg V4 正在醞釀一項重要的元資料格式改進，其核心目標是解決當前版本在頻繁資料更新時或者資料量比較小的表在寫入時，所面臨的元資料寫入開銷問題。 目前，Iceberg 建立一個新快照（snapshot）必須至少寫入一個 manifest 檔案和一個 manifest list 檔案，這種“多檔案寫入”模式在高吞吐場景下成為效能瓶頸。為此，社群提出“單檔案提交”的設計思路：計劃重構 v4 的元資料結構，允許 manifest list 層直接儲存資料檔案和刪除檔案的引用資訊。這意味著在大多數情況下，提交一次變更只需寫入一個新的元資料檔案，從而顯著降低事務操作的成本和延遲。
該最佳化方案同時瞄準了多個關聯問題： 首先，它致力於減少因海量細小 manifest 檔案帶來的問題——這些小檔案不僅需要並行讀取增加開銷，後續還需進行 Compaction，新的元資料維護機制旨在從源頭避免它們的產生。其次，方案計劃增強 metadata skipping 能力，探索支援儲存相容地理空間資料等更復雜型別的聚合列統計資訊，幫助查詢引擎更精準地過濾無關資料分割槽。最後，針對刪除操作，方案考慮引入軟刪除機制來避免重寫整個現有 manifest 檔案（類似 metadata deletion vector），進一步減少 I/O 消耗。
當前 Iceberg 和 Delta Lake 都已經具備 CDF 的基本能力：Iceberg V2 版本的 CDF 依賴引擎實現進行暴力掃描計算增量資料，Iceberg V3 則是透過 Row Lineage 標記了行級別資料變更，而 Delta Lake 則是同時支援行級血緣和輸出 changelog 檔案。下一代 CDF 的核心演進方向聚焦於提升即時資料處理的效率與靈活性，同時降低使用門檻，需滿足以下關鍵要求：
-
零寫入開銷：必須支援讀取時計算（computed on read），避免寫入階段的額外負載；
-
無標記化資料捕獲：無需使用者顯式定義 ID 欄位，直接利用表格式原生能力（如 Delta 的行追蹤 row_commit_version 或 Iceberg 的行血緣 Row Lineage）自動標識變更；
-
高效生效化（Effectivization）：針對整行變更場景，需高效識別變化（例如透過 Delta 的版本差快速定位變更行）；
-
強相容性：必須支援刪除向量（DVs）及非新增型 Schema 變更（如列重新命名、型別擴充套件等複雜演化）。可選方向包括允許使用者指定 ID 列，以及基於自定義列值實現生效化邏輯。
在技術實現層面，社群正探索關鍵問題的解法：
-
API 設計：需統一生效化介面（如透過布林引數切換原始 / 生效化檢視，或提供獨立 API）；
-
引擎整合：定義表格式庫與計算引擎的互動協議，核心是避免全表掃描，透過元資料快速定位變更範圍；
-
Schema 處理：處理列重新命名 / 型別擴充套件時，需決策輸出結果採用變更發生時的歷史 Schema 或當前統一 Schema；
-
生態擴充套件：支援非查詢引擎（如流處理系統）直接消費原始非生效化資料流，並最佳化重複讀取場景的效能；
-
安全與協同：探索在資料掩碼（data masking）和行級過濾表中啟用 CDF，同時推動 Delta Sharing 對 CDF 的原生支援。
未來 CDF 的核心價值在於平衡自動化與靈活性：透過深度整合表格式的元資料能力（如行追蹤、版本比對）實現無侵入式變更捕獲，同時開放使用者自定義介面滿足複雜場景，最終構建低開銷、高相容的即時資料流水線基礎架構。
面對 AI 時代下的多模態資料如檔案、音訊、圖片和影片資料，Iceberg 和 Delta Lake 都沒有很好的應對方案，兩大社群聯手組織了一個現場討論，引入 BLOB 資料型別需系統性解決五大核心問題：
-
儲存表示：需權衡資料檔案（即 Parquet）記憶體儲、外部儲存或混合模式的效率差異，並決策二進位制資料以獨立檔案還是打包（bin-packed）捆綁形式存在；同時必須確保資料完整性機制。
-
查詢體驗：需支援全物件讀取、順序掃描及隨機訪問等多元 API，突破海量傳輸的效能瓶頸，透過統計資訊、佈局最佳化和索引策略（如內容摘要）實現高效分析，關鍵要解決部分資料提取（如直接獲取影片片段）的可行性。
-
治理架構：需定義儲存位置策略——表級隔離或共享 BLOB 空間，明確安全模型（物件級 ACL vs 表 / 列級許可權），解決與目錄令牌授權、安全檢視的相容性，並驗證 Delta Sharing 預簽名 URL 對大檔案的支援能力。
-
建立流程：要求提供零複製攝入、多格式轉換等 API，支援從異構資料來源生成 BLOB。
-
元資料設計：需確定記錄粒度：基礎時間戳 / 大小，或擴充套件 MIME 型別、內容特徵（如影片關鍵幀）；同時評估顯式子型別（如 TEXT）對專用操作和索引的需求。
參與這場討論的最直觀感受，就是開源社群與企業內部的研發流程有著很大的不同。同樣是面對日益增長的 AI 需求，企業內部產品迭代往往採取短週期、高頻率的“快糙猛”模式，強調快速交付和靈活調整；相比之下，開源社群的功能開發流程則嚴謹和剋制得多，涉及更廣泛的討論、更詳盡的設計評審和更嚴格的相容性考量，這是由於社群生態的複雜依賴關係決定了任何疏忽都可能引發連鎖反應，導致漫長而昂貴的修復過程。
Lance 是一種專為多模態資料（影像 / 影片 / 文字 / 表格）設計的高效能列式儲存格式，被認為是傳統 table format 的下一代演進形式，其核心優勢在於：
百倍級隨機訪問效能：透過列式儲存與硬體加速（SIMD/GPU），號稱查詢效率比 Parquet 提升百倍；
原生向量搜尋：內建 HNSW 等索引，支援毫秒級相似性檢索，無縫融合 OLAP 與向量計算；
零複製版本控制：透過刪除標記 + 快照機制實現低成本即時更新，避免傳統 LSM 架構的重寫開銷。
Weston Pace 關於 Lance 的演講
Lance 格式的核心研發 Weston Pace（也是 Arrow 社群 PMC 成員）在現場作了一場主題演講，現場感興趣的聽眾比較多，大家感興趣的話題主要是 Lance 和 Iceberg 融合的可能性，大概有三種方式：
-
Lance 作為 Iceberg 底層檔案格式：Iceberg 透過擴充套件檔案格式支援（替代 Parquet/ORC），將 Lance 檔案納入其 ACID 事務體系。優勢在於複用 Iceberg 的時空旅行、Schema 演進等能力，同時提升查詢效能。但這種替換說實話意義不大，對於大寬表或者面向 AI（比如 feature engineering）場景仍然沒有解決根本問題。
-
Lance Manifest 注入 Iceberg 元資料層：在 Iceberg Manifest 中嵌入 Lance Manifest，比如把 Lance 的一張表或者一個 Manifest 偽裝成 Iceberg 的 Manifest 甚至一個數據檔案。這個聽起來有些 hack，社群很可能不會接受這個路線。
-
REST Catalog 統一管理：利用 Polaris 等 Catalog 協調層，將 Lance 表註冊為 Iceberg 表。Lance 負責儲存與索引（如向量搜尋），Iceberg 提供跨引擎元資料抽象。適用於歷史冷資料存 Iceberg+Parquet，即時熱資料存 Lance。會後和 Weston 私下聊天，他也說這是當前 LanceDB 使用者最多的用法。
無論是 Parquet 社群還是 Iceberg 社群，都已經意識到像 Lance、Nimble 和 Vortex 這樣的新興檔案格式對其發起的挑戰。Parquet 社群去年就已經發起了 Parquet V3 的討論，加上前面提到的 Iceberg V4 相關討論，未來這兩個檔案格式和表格式的事實標準如何演進，還是很值得期待的。雲器科技也會繼續深耕這兩個社群，也歡迎志同道合的朋友們加入我們，一起貢獻自己的力量。
展望未來，Iceberg 生態還在快速發展中。除了核心功能的持續最佳化，社群生態的完善也同樣重要。作為長期參與 Iceberg 社群的從業者，筆者一直認為 C++ 生態的缺失是個遺憾。
去年底，雲器科技在 Iceberg 官方社群發起了 iceberg-cpp 專案，旨在用純 C++ 實現完整的 SDK。目前專案在 MVP 版本，作為發起方，雲器科技會持續投入資源。但開源專案的成功終究需要社群的共同參與，歡迎大家加入社群一起貢獻！
iceberg-cpp 關於 MVP 的 Github Issue
從程式碼開源到標準開放的協作
Iceberg V3 的成功不在於技術創新，而在於建立了跨社群協作的新模式。真正的互操作性誕生於會議室的激烈討論和漫長協調，而非程式碼倉庫的 PR 合併。
互操作性源於開放協作： 真正的開放湖倉架構的互操作性和自由源於社群 / 廠商協作，而非僅靠開原始碼本身。
資料架構的三大演進方向已經明確
-
寫入即時化： 透過元資料革命，儘可能最佳化高頻和即時寫入極限。
-
計算增量化： 實現更低成本和更高效的增量計算正規化，達成流批一體。
-
查詢智慧化： 原生支援多模態資料治理與智慧查詢，突破非結構化資料分析。
AI 不只是應用層的事
Lance 格式的出現、BLOB 型別的討論、向量搜尋的需求，都在提醒我們：AI 正在深刻改變資料基礎設施的設計理念。不是簡單地在上層加個 AI 應用，而是從儲存格式、查詢引擎到元資料管理，整個技術棧都在為 AI 場景重新設計。這種自下而上的融合，才是真正的 AI-Native 架構。為下一代 AI 場景快速演進提供強力支撐。
吳剛，雲器科技 Lakehouse 研發專家Arrow Parquet & ORC PMC Member，ASF Member