對於許多剛接觸數據工程的開發者來說，最頭痛的問題通常不是如何寫 SQL，而是數據到底存在哪裡，以及為什麼同一份數據在不同工具中看起來不一樣。在傳統的數據架構中，如果你想用 Spark 做大規模數據處理（ETL），然後用 BigQuery 做商業分析，你通常得把數據從一個地方複製到另一個地方。這種數據重複不僅浪費儲存空間，更會導致數據不一致，形成所謂的數據孤島。
為了解決這個問題，業界引入了 Apache Iceberg。簡單來說，Iceberg 是一個開放的表格格式（Open Table Format），它在底層的數據文件（如 Parquet）之上建立了一層元數據管理。這讓數據湖（Data Lake）具備了類似傳統數據庫的特性，例如 ACID 事務（確保數據寫入的原子性與一致性）、時間旅行（Time Travel，允許查詢過去某個時間點的數據版本）以及隱式分區（Hidden Partitioning，讓使用者不必手動管理分區路徑）。
Google Cloud 最近在 BigQuery 中引入了跨引擎的 Iceberg 支持，其核心目標是讓企業在不搬移數據的前提下，能讓不同的計算引擎同時讀寫同一份數據。
解決 Iceberg 採用的隱形成本
雖然 Iceberg 提供了開放格式，但實際部署時會遇到一個巨大的挑戰：元數據管理與維護。在實務上，Iceberg 表格需要定期進行 Compaction（小文件合併），以防止文件過多導致查詢變慢；同時還需要管理快照（Snapshot）的清理。對於許多團隊來說，這些維護工作成了採用的隱形成本。
Google 這次推出的伺服器端 Iceberg REST Catalog（一種標準化的元數據目錄接口），將這些繁瑣的維護工作自動化。它讓 BigQuery 不再僅僅是一個查詢工具，而是一個能管理 Iceberg 表格生命週期的控制平面。這意味著你的數據可以儲存在開放格式中，但由 Google 幫你處理底層的同步、事務管理與元數據維護。
實現真正的跨引擎互通
過去，開發者在選擇架構時常面臨兩難：是要使用 BigQuery 原生的管理方式來獲得高效能，還是使用 Iceberg REST Catalog 以維持跨工具的靈活性？如果選擇後者，雖然 Spark 可以寫入，但 BigQuery 可能無法充分利用其儲存管理功能。
現在的更新打破了這個限制。透過統一的 REST Catalog，Spark、Flink、Trino 以及 BigQuery 可以共用同一套元數據。這意味著你的數據工程師可以用 Spark 進行高效能的數據清洗，而分析師可以直接在 BigQuery 中對同一張表進行分析，兩者之間不需要任何數據複製或格式轉換。
跨雲端與 AI 工作流的整合
Google 的野心不僅限於單一雲端。目前的預覽功能已擴展到跨雲端 Lakehouse，支持查詢存放在 AWS 或 Azure 上的 Iceberg 目錄。這種能力對於採取多雲策略的企業至關重要，因為它允許數據留在原處，而分析邏輯可以在 BigQuery 中集中處理。
此外，針對現代 AI 需求，Google 推出了 BigQuery ObjectRefs。這解決了一個關鍵痛點：AI 工作流通常需要同時處理結構化數據（如 Iceberg 表格中的銷售紀錄）與非結構化數據（如儲存在 Cloud Storage 中的圖片或 PDF）。透過 ObjectRefs，開發者可以在同一個分析流程中將這兩者結合，實現多模態（Multimodal）分析。
總結與實務影響
對於工程師而言，這次更新的核心意義在於將數據的控制權從封閉的專有格式轉移到開放標準上，同時保留了託管服務的便利性。當元數據管理（Control Plane）被標準化且自動化後，企業在選擇計算引擎時將擁有更高的靈活性。
如果你正在設計數據平台，現在的趨勢是儲存層採取開放格式（如 Iceberg），而計算層則根據工作負載（Workload）靈活切換。這種架構能有效降低供應商鎖定（Vendor Lock-in）的風險，並為未來的 AI 整合打下基礎。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。