这一预览功能使多个工具能够直接操作同一数据集，而不必依赖数据复制或专有格式。谷歌还引入了对元数据、表维护以及同步任务的托管支持，而这些工作在传统 Iceberg 部署中往往需要人工处理。
谷歌高级产品经理 Yuriy Zhovtobryukh 与高级产品市场经理 Angela Soares 解释了这一更新的重要性：
如果你现在正在构建 Lakehouse，那你大概已经用上了 Apache Iceberg。对于需要支持多个计算引擎（例如 Spark 与 BigQuery）访问同一份数据、处理不同工作负载的数据平台团队来说，Iceberg 已经获得了广泛普及。
在最近举行的 Next ’26 大会上，谷歌进一步将 Iceberg 的互操作能力扩展到跨云 Lakehouse 场景，支持在 AWS、Azure、Databricks 以及 Snowflake 之间查询 Iceberg Catalog，并扩展到 AI 工作流。根据谷歌的说法，其整体目标是让企业能够以开放格式存储数据，同时使用不同的数据处理与分析工具操作同一数据集。
谷歌认为，许多使用 Apache Iceberg 的团队，相比完全托管的数据平台，依然面临更高的成本与运维复杂度，尤其是在流式数据处理、复制管道以及多工具治理方面。
为了解决这些问题，谷歌正在将 BigQuery 的底层基础设施扩展到对 Iceberg 表的原生支持，包括托管元数据、自动表维护、事务处理以及变更数据复制（CDC）。Zhovtobryukh 与 Soares 补充道：
此前，在构建 Lakehouse 时，客户通常需要根据主要 ETL 引擎，在 Google 托管的 Iceberg REST Catalog 表与 BigQuery 托管表之间做出选择。这意味着，如果客户依赖 Apache Spark 对 Iceberg REST Catalog 表执行 ETL，就无法通过 BigQuery 写入这些表，也无法使用 BigQuery 的存储管理能力。
此次预览还引入了集中式表访问控制，使权限能够在不同查询引擎之间保持一致管理。随着最新功能发布，谷歌云现在已经支持跨 AWS 与 Azure 查询 Iceberg 数据，并能够与 Databricks、Snowflake 等外部平台互操作，同时还支持非结构化数据与 AI 工作流的整合。
BigQuery ObjectRefs 现已正式可用，允许团队将结构化 Iceberg 数据与存储在 Cloud Storage 中的非结构化文件结合起来，用于多模态分析与 AI 工作流。此外，目前仍处于预览阶段的治理层 Knowledge Catalog（原 Dataplex），还可统一管理跨系统的元数据、数据血缘以及访问控制。
业内实践者认为，这种集成有望消除企业采用 Iceberg 时的“隐性成本”。David Colbert 评论称：
团队往往会被 Iceberg 或 Delta 的能力所吸引，但很快就会在 compaction、元数据管理以及编排方面遭遇阻力。Catalog 才是真正关键的部分。开放格式解决的是存储可移植性问题，而控制平面的选择则决定了长期的可选性。
在回顾 Next ’26 上的相关发布时，Precious Pendo 写道：
谷歌正在押注：企业 AI 的价值最终将归属于那些掌握数据推理层的人，而不仅仅是掌握存储层的人。AWS 和 Azure 向你收取的是计算与存储费用，而谷歌想向你出售的是上下文与智能能力。
谷歌云并不是唯一聚焦 Iceberg 工作负载的云厂商。AWS 的 EMR、Glue、Athena 与 Redshift 等分析服务，也都已提供对 Iceberg 的原生支持。
在讨论 Apache Iceberg 如何改变现代数据湖时，Red Oak Strategic 云工程师 Shashank Muthuraj 写道：
Apache Iceberg 在不到七年的时间里，就从 Netflix 的一个工程项目发展成为开放式数据 Lakehouse 架构的事实标准。它的技术优势——ACID 事务、隐藏分区、时间旅行以及引擎无关性——确实非常吸引人，但真正值得关注的是整个行业前所未有的一致性支持。
目前，BigQuery 对托管 Iceberg 表的核心支持已经正式可用；而在 Iceberg Summit 2026 上公布的更广泛开放互操作能力与 REST Catalog 功能，则仍处于预览阶段。
原文链接：Google Cloud Introduces Cross-Engine Iceberg Support in BigQuery - InfoQ
