datainfra前沿动态 · Vol.38

Google Cloud 会话分析多云端全面 GA；SAP BDC Connect 零拷贝打通 BigQuery；AWS Spark Upgrade Agent 将 Spark 4.0 迁移从数月压缩至数小时

本期聚焦 DataInfra 三条 Agent-First 企业级生产化进展：Google Cloud Conversational Analytics 全面 GA，从 BigQuery/Looker 扩展至 AlloyDB/Spanner 并支持 Iceberg REST 和 AWS Unity Catalog 多云端查询；SAP BDC Connect for BigQuery 正式 GA，以零拷贝架构打通 ERP 与数据湖；AWS Spark Upgrade Agent 通过 MCP 协议将 Spark 3.x→4.0 迁移自动化，从数月人工迁移压缩至数小时。三条动态共同指向同一趋势：Agent-First 数据基础设施正从实验阶段进入企业级大规模部署。

DataInfra Conversational Analytics Google Cloud BigQuery Looker Spanner AlloyDB SAP SAP BDC Connect BigQuery 零拷贝 AWS Spark Upgrade Agent Apache Spark Spark 4.0 MCP Amazon EMR Agentic Workflows 数据基础设施 Multi-Cloud

本期追踪到三条 DataInfra 动态，指向同一个方向：Agent-First 数据基础设施正在从实验验证阶段全面进入企业级规模化部署。2026 年 7 月 29 日，Google Cloud 发布 Conversational Analytics 全栈升级——BigQuery 和 Looker 的会话分析正式 GA，AlloyDB、Cloud SQL、Spanner 进入 Preview，同时支持 Apache Iceberg REST Catalog 和 AWS S3 Unity Catalog 的多云端联邦查询，标志着自然语言数据交互从”单产品试点”进入”全数据栈统一体验”阶段；7 月 28 日，SAP 与 Google Cloud 联合宣布 SAP BDC Connect for BigQuery 正式 GA，以零拷贝双向架构打通 ERP 数据与数据湖，Accenture、Deloitte、KPMG、PwC 四大咨询巨头已基于此构建 Agentic AI 解决方案；同日，AWS 发布 Spark Upgrade Agent——基于 MCP 协议的自动化迁移工具，将 Apache Spark 3.x 到 4.0 的 Scala 迁移从数月的重复手工劳动压缩到 IDE 内数小时的自动化闭环。三条动态分别从查询交互层、数据集成层和运维工具层推进了同一进程：让 Agent 能够安全、可靠、低成本地访问和操作企业全域数据。

Google Cloud Conversational Analytics 全面升级：BigQuery+Looker GA、多数据库 Preview、跨云端联邦查询

事件概述

2026 年 7 月 29 日，Google Cloud Data Agents 工程高级总监 Ganesh Kumar Gella 与 Richard Kuzma 联合发布博客，系统阐述了 Conversational Analytics (CA) 在 Q3 2026 的产品全貌。核心里程碑：BigQuery Conversational Analytics 和 CA API 正式 GA，加上此前已 GA 的 Looker CA，Google Cloud 的会话分析已覆盖数据仓库和 BI 两大核心场景；AlloyDB、Cloud SQL、Spanner 的 CA 进入 Preview，将自然语言查询能力扩展至运营数据库。同时公布的还有一系列此前未系统披露的企业级能力：多云端联邦查询、主动式 Agentic Workflows、完整的可观测性体系、以及跨 Knowledge Catalog / BigQuery Graphs / LookML 的三层语义接地架构。

技术解析

  • 多云端联邦查询：CA 不仅支持 Google Cloud 原生数据源，还支持 Lakehouse Managed Service 表、Apache Iceberg REST Catalog 和 AWS S3 Unity Catalog 的联邦查询。这意味着一个自然语言问题可以透明地跨越 Google Cloud、AWS 和本地 Iceberg 部署的数据，Agent 在查询规划阶段自动路由到正确的数据源。这是目前主流云厂商中首个将会话分析的多云端能力明确定义为产品功能的案例。

  • 产品矩阵与分发渠道：数据从业者通过 BigQuery Studio、BigQuery Data Canvas 和 Database Studio 内嵌使用 CA；业务用户通过 Looker、Data Studio 和 Gemini Enterprise 的统一界面消费数据洞察。数据团队可以将 BigQuery/Looker/AlloyDB/Spanner/Cloud SQL 中创建的 CA Agent 直接发布到 Gemini Enterprise，形成一个中心化的企业数据问答入口。API（Node.js/Java/Go/Python/PHP/Ruby/.NET SDK）+ MCP 工具的组合让开发者可以将 CA 嵌入自定义应用、Slack 机器人和多 Agent 编排系统。

  • 三层语义接地架构：CA 的防幻觉策略不是简单地给 LLM 喂 Schema——Google 实施了三层接地：(1) Knowledge Catalog（原 Dataplex）提供数据发现、术语表和自动上下文丰富（如表 Join 关系和列描述）；(2) BigQuery Graphs 和 Spanner Graphs 让 Agent 能够理解多跳关系数据中的结构化与非结构化关联；(3) LookML 语义层以”黄金查询（Golden Queries）“形式提供经中心治理的指标定义，Agent 基于验证过的业务逻辑而非推测的 SQL Join 返回答案。

  • Agentic Workflows：从被动问答到主动智能：Preview 阶段的 Agentic Workflows 允许排程自动化报告、持续运行异常检测并在指标偏离基线时自动启动 Agent 进行多维深度钻取（每次分析 10-20 个贡献因子）。这标志着数据分析从”用户问、Agent 答”的被动模式向”Agent 主动发现、推送、解释”的转变——本质上是在数据基础设施之上构建了一个 AI-Native 的持续分析层。

  • 企业级安全与可观测性：CA 提供 CMEK（客户管理加密密钥）、Private IP、VPC 控制、欧盟/美国多区域 Data Residency 保证和 HIPAA 合规。可观测性方面，Agent 通过 OpenTelemetry (OTEL) 导出健康状态、工具使用、延迟和 Token 消耗指标；管理员可以通过 BigQuery 查询标签和 Looker 系统活动日志追踪使用情况，并设置最大查询字节数等成本控制策略。完整的反馈回环（Agent Traces + 用户反馈）为持续评估和准确性改进提供了基础设施。

行业影响

Google Cloud CA 的此次升级代表了一个重要信号：“自然语言查数”不再是 BI 工具的一个附加功能，而是正在成为数据基础设施的原生接口层。当 CA 同时覆盖数据仓库（BigQuery）、BI（Looker）、运营数据库（AlloyDB/Spanner/Cloud SQL）和多云端联邦（Iceberg REST/Unity Catalog）时，它实际上定义了一种新的数据消费范式——Agent 是数据的一等公民消费者，自然语言是基础设施的原生协议。

与 Vol.37 报道的 OKF v0.2（Agent 知识格式）和 Joe Reis 的”每个 Agent 一个 DuckDB”相呼应，Google CA 的多云端 GA 从另一个角度回答了同一个问题：当 Agent 成为数据的主要消费者时，基础设施应该如何重新设计？ OKF 解决的是”Agent 之间如何交换可信知识”，Joe Reis 解决的是”Agent 的数据存储架构”，而 Google CA 解决的是”Agent 如何通过统一语义层安全地查询异构数据栈”。三者分别对应格式层、存储层和查询层的 Agent-First 重构。

相关链接

SAP BDC Connect for BigQuery 正式 GA：零拷贝架构打通 ERP 与数据湖，四大咨询巨头入局

事件概述

2026 年 7 月 28 日，Google Cloud Cortex GTM 董事总经理 Snehanshu Shah 与 SAP Business AI 平台首席营收官 Jan Bungert 联合宣布 SAP Business Data Cloud (BDC) Connect for BigQuery 正式 GA。这是继 2025 年 5 月双方宣布战略合作后的里程碑交付——以零拷贝（zero-copy）双向架构实现 SAP Business Data Cloud 与 Google BigQuery 之间的实时数据互访问，无需数据复制、不产生数据共享费用。Accenture、Deloitte、KPMG、PwC 四大全球咨询巨头均已基于此构建面向客户的 Agentic AI 解决方案。

技术解析

  • 零拷贝双向架构：与传统 ETL/CDC 方案不同，BDC Connect 在 BigQuery 和 SAP BDC 之间建立安全双向连接，直接访问 SAP 表、元数据和业务语义——无需将数据先复制到中间层。在 BigQuery 中可以查询 SAP 中的实时数据（包括库存水平、财务数据、供应链状态），语义元数据通过 Knowledge Catalog（原 Dataplex）双向同步。这意味着 AI Agent 可以在不离开 BigQuery 的前提下，同时分析 SAP 运营数据和非 SAP 的 Google 数据（如 Google Trends、Google Maps 地理空间数据），并将丰富后的分析结果回写至 SAP。

  • 零成本数据共享：零拷贝架构不仅消除了数据复制的存储成本，还不产生数据共享费用（data sharing fees）——对于拥有 TB/PB 级 SAP 数据的企业来说，这意味着可预测的 TCO 模型。这与 Google Cloud “Agentic Data Cloud”战略中强调的”不通过数据出口费用锁定客户”的承诺一致。

  • 四大咨询巨头的实战用例：(1) Accenture 强调 BDC Connect 消除数据孤岛，使其能构建智能 Agent 驱动自主运营；(2) Deloitte 披露了一个自主采购 Agent 案例——Agent 同时读取 BigQuery 中的实时 SAP 库存水平和市场数据，在供应商变动时自主重新路由订单，避免了数百万美元的潜在停机损失；(3) KPMG 评估认为该集成可支撑企业级分析工作负载，为未来 AI 和 Agentic 用例提供关键数据基础；(4) PwC 正帮助客户将 SAP 业务数据与 Google Cloud 内更广泛的数据源统一，构建可信的 AI 基础。ElringKlinger（全球汽车零部件供应商）的真实案例验证了零拷贝查询 SAP BW/4HANA 的可行性。

  • 跨云支持：BDC Connect 已支持 Google Cloud 和 AWS 上托管的 SAP BDC 实例，Azure 支持即将推出——这在”多云 SAP + 单一数据湖”的典型企业架构中具有直接的操作价值。

行业影响

SAP BDC Connect for BigQuery 的 GA 解决了企业数据基础设施中长期存在的一个核心矛盾：ERP 系统（运营数据的”金源”）与数据湖/数据仓库（分析数据的”金源”）之间的物理隔离。传统上，将 SAP 数据引入数据湖需要复杂的 ETL 管道、数据复制、语义映射和持续的同步维护——这不仅是成本问题，更是时效性问题：当 Agent 需要的实时库存数据还在 T+1 的 ETL 管道中流转时，Agent 的决策质量已经打了折扣。

从更广的 DataInfra 视角看，BDC Connect 代表了“数据集成从管道式向联邦式”的范式转移。ETL/ELT 的核心假设是”数据需要被移动到分析平台才能被使用”；联邦查询的核心假设是”数据留在原地，查询引擎去找数据”。随着 Trino、Presto 的成熟和 Iceberg REST Catalog 的标准化，联邦查询的技术基础已经具备——BDC Connect 是在此基础上为 SAP 这一全球最大的企业应用生态提供了原生支持。当 SAP（运营数据）和 BigQuery（分析数据）实现零拷贝互通时，我们离 Vol.37 Joe Reis 所预言的”Agent 不需要关心数据在哪”又近了一步。

相关链接

AWS Spark Upgrade Agent：将 Spark 3.x→4.0 迁移从数月人工劳动压缩至 IDE 内数小时自动化闭环

事件概述

2026 年 7 月 28 日，AWS 大数据博客发布由 Bezuayehu Wate、Chuhan Liu 等六位工程师撰写的深度技术文章，正式介绍了 AWS Spark Upgrade Agent——一款基于 Model Context Protocol (MCP) 的完全托管远程服务，用于自动化 Apache Spark 3.x 到 4.0 的迁移。该 Agent 覆盖构建配置更新、环境验证、代码转换、远程集群验证和数据质量检查五大环节，能将传统上耗时数月的 Spark 大版本迁移压缩至数小时内完成。首发支持 Amazon EMR Serverless 6.9.0 (Spark 3.3, Scala 2.12) 到 8.0.0 (Spark 4.0, Scala 2.13) 的迁移路径，支持 Scala、PySpark 和 Spark SQL 三种工作负载类型。

技术解析

  • 五阶段自动化迁移流水线：(1) 构建配置更新——自动更新 Maven pom.xml 或 SBT build.sbt，将依赖升级至 Spark 4.0 + Scala 2.13，处理依赖排除规则和 Assembly 配置；(2) 环境验证——检查并自动升级 Java 环境（Amazon EMR 8.0.0 要求 JDK 17），更新 Python 环境；(3) 代码转换——通过 fix_upgrade_failure 工具迭代修复编译错误，覆盖 Scala 2.12→2.13 集合 API 迁移（如 JavaConverters→CollectionConverters）、Parquet 配置键更新（legacy.parquet 前缀移除）、ANSI 模式适配（CAST→TRY_CAST）等；(4) 远程验证——将升级后的 JAR 提交到 Amazon EMR Serverless 集群进行运行时验证，自动捕获并解决运行时故障；(5) 数据质量检查——对比 Spark 3.5 基线运行结果与 Spark 4.0 结果，确认迁移正确性。

  • MCP 原生工具调用：Agent 通过 MCP 接口暴露 generate_spark_upgrade_plan、update_build_configuration、check_and_update_build_environment、fix_upgrade_failure、run_validation_job 等工具，支持 Kiro 和 VS Code (Cline 扩展) 两种 IDE 内自然语言交互。“迁移 Agent 通过 MCP 执行代码分析和转换”这一架构选择值得关注——它让 Spark 迁移成为一个可被编排、可审计、可回滚的自动化流程，而非黑盒脚本。

  • 最小权限安全模型：IAM 角色权限范围仅限于 MCP 服务器调用、S3 暂存桶访问和 EMR 作业提交；源代码保留在本地，仅传输最小诊断信息；所有数据传输加密；AWS CloudTrail 记录每次工具调用——这为在生产环境中使用 Agent 驱动的代码迁移工具提供了合规基础。

  • 迭代精炼循环：Agent 的工作模式不是”一次性转换然后报告结果”，而是”本地验证→远程提交→自动解决运行时故障→重新验证”的迭代循环。这种闭环设计使得那些传统上需要多次手动调试才能发现的运行时问题（如序列化变更、Join 策略行为差异）能在无人工介入的情况下被自动修复。

行业影响

AWS Spark Upgrade Agent 的发布标志着一个重要的工具范式转移：“基础设施迁移”正在从”人类阅读 Changelog + 手动修改代码”变为”Agent 自主动作 + 人类审批”。这一转变的影响范围远超 Spark 本身——如果 MCP 驱动的自动化迁移模式被验证可行，它可以复用到 Kafka 版本升级、Flink 作业迁移、Iceberg Schema Evolution 适配等众多 DataInfra 运维场景。

值得注意的是，AWS 选择 MCP 作为 Agent 与迁移工具的协议接口——这与 Google Cloud 同期通过 MCP 暴露 Conversational Analytics 能力（见本期第一条）形成了一个有趣的共振：MCP 正在从”AI Agent 与外部工具的连接协议”扩展为”数据基础设施自动化工具的标准化接口”。当 Spark 迁移、数据查询、知识管理等操作都通过统一的 MCP 接口暴露时，数据平台运维本身也变成了一个可以被 Agent 编排的工作流——这可能是 2026 年下半年 DataInfra 领域最值得关注的元趋势之一。

相关链接

编者评

三条动态表面看分别属于”查询交互""数据集成""运维工具”三个不同领域，但共享一个深层趋势：Agent-First 不是给现有数据基础设施加一个 Chat 界面，而是要求基础设施从接口层（MCP）、格式层（OKF）、语义层（Knowledge Catalog/LookML）、到运维层（自动化迁移）进行系统性重构。Google CA 的多云端 GA 和 SAP BDC Connect 的零拷贝 GA 代表了”让 Agent 能访问一切数据”的供给侧努力；AWS Spark Upgrade Agent 则代表了”让平台运维本身也 Agent 化”的需求侧进化。两股力量的交汇点在于：2026 年下半年，我们正在见证”数据基础设施”从”服务于人类数据工程师”向”同时服务于人类和 AI Agent”的双模时代过渡。MCP 作为这一过渡期的标准协议，其采纳速度和生态广度将是判断 Agent-First DataInfra 成熟度的重要先行指标。