当前位置：首页 > 文章列表 > 科技周边 > 业界新闻 > Google Cloud Next 2026 的 Agentic Data Cloud 为什么强调跨云数据

Google Cloud Next 2026 的 Agentic Data Cloud 为什么强调跨云数据

来源：17golang原创 2026-09-08 02:53:57 0浏览收藏

Google Cloud Next 2026 把 Agentic Data Cloud 的重点放在跨云数据，核心原因不是“云越多越先进”，而是企业的业务数据本来就分散在不同云、数据库和应用里。对 Agent 来说，真正的难题是能否在不大规模搬迁数据的前提下，发现数据、理解业务语义、遵守访问边界，并把分析结果接到行动上。公告中的 Cross-cloud Lakehouse、Knowledge Catalog 和 Iceberg 互操作，正是在补这几层能力。

跨云数据的价值可以概括为：数据尽量留在原处，统一入口负责发现和查询，语义与权限负责约束 Agent 的回答。它更像一套访问和治理架构，不等于把所有数据自动迁移到 Google Cloud。

下面只围绕公告已披露的产品方向，拆解它解决什么问题、哪些团队会受益，以及落地时应该先验证什么。

跨云数据先解决的是“看得懂”

如果 Agent 只能看到表名和字段名，它并不知道企业所说的“毛利”“有效客户”或“可售库存”分别采用什么口径。数据跨云之后，这个问题会更明显：目录、权限、业务术语和使用习惯往往分散在多套系统里。

Google Cloud 在公告中将 Dataplex Universal Catalog 演进为 Knowledge Catalog，并把它描述为覆盖整个数据资产的上下文引擎。它的作用不是简单复制一份目录，而是聚合不同平台的上下文，持续补充业务含义，并在搜索时结合访问控制。这样一来，Agent 得到的不是裸数据，而是带有来源、语义和权限约束的检索上下文。

'跨云数据源、Knowledge — 图1：跨云数据要先经过语义与权限上下文，Agent 才能获得可追溯的业务答案。

对开发者而言，这意味着提示词之外还要管理业务定义、数据产品、质量规则和血缘信息。公告提到的列级血缘、结构化审批和可复用质量规则，解决的是“答案从哪里来、谁批准过、能不能继续使用”这类工程问题。

跨云 Lakehouse 改变了数据工程的起点

传统迁移方案往往先把数据复制到一个中心，再围绕复制链路建设 ETL、权限和成本控制。Google Cloud 此次强调的 Cross-cloud Lakehouse，则把问题改成“如何在数据原地保留时提供统一访问”。公告提到它以 Apache Iceberg 和 Iceberg REST Catalog 为基础，面向 AWS、Azure 以及合作伙伴生态提供互操作能力。

这里的关键词是零拷贝和互操作：BigQuery、Managed Service for Apache Spark 以及兼容 Iceberg 的开源或第三方引擎，可以围绕同一套表和目录协作；对 AWS 数据，公告还提到跨云互联和跨云缓存，用于改善重复读取时的访问效率。它减少的是不必要的数据复制和引擎锁定，并没有消除网络、权限、格式、延迟和出网费用这些现实约束。

'数据原地保留、Iceberg — 图2：跨云 Lakehouse 的关键取舍是让数据保留在原处，同时统一发现、查询和治理入口。

哪些团队会先感受到变化

数据工程团队会先关注表格式、目录和权限是否能被多个引擎共同理解；分析团队更关心业务口径能否复用，以及运营数据和历史数据能否联结；Agent 开发团队则关心检索结果是否有来源、是否按用户权限过滤、是否能在不同数据位置之间稳定调用。

因此，最适合先试的不是“把全公司的数据接入 Agent”，而是一个边界清晰的查询任务。例如让 Agent 汇总某个业务域的库存与订单信息，限定数据集、用户角色、时间范围和输出动作，再检查四件事：它是否找到正确的数据资产，是否使用正确的业务定义，是否拒绝越权数据，是否能追溯到表、列或文档来源。

如果这些条件还没有准备好，跨云访问只会把原有的数据质量问题放大。尤其要注意，公告里部分能力带有 Preview 标识，不能在生产承诺中直接按 GA 能力规划；具体支持的云、引擎、区域和计费方式也应以当前产品文档为准。

采用时先做一轮小范围验证

第一步是画出数据位置和责任边界：哪些数据在 AWS，哪些在 Azure 或 Google Cloud，谁负责业务定义，谁批准访问。第二步是选择一组使用 Iceberg 或已有目录的数据，确认表格式、目录接口、读写引擎与权限模型是否匹配。第三步把 Knowledge Catalog 中的语义、质量和血缘信息纳入 Agent 的检索上下文，而不是只接一个自然语言到 SQL 的生成器。

第四步用固定问题集记录结果，包括正确率、拒答率、来源完整性、重复读取的网络成本和延迟。最后再决定是否扩大数据范围。这个顺序能把“跨云能力很强”的宣传判断，转化为数据可见性、治理可追溯性和总成本的工程证据。