Google Cloud 无界湖仓发布：Iceberg REST Catalog Federation 打通三大多云端；AWS EMR Serverless 大规格 Worker 实测 29% 提速降本；阿里云 MaxCompute MaxAgent 正式 GA

---

本期追踪到三条次日历的 DataInfra 动态，均于 2026 年 7 月 29-30 日发布。7 月 30 日，Google Cloud 在 Next Tokyo 大会上发布了 Borderless Lakehouse（无界湖仓） 增强——以 Iceberg REST Catalog Federation（Preview） 打通 AWS Glue、Databricks Unity Catalog 和 Snowflake Horizon 三大外部 Catalog，配合 Cross-Cloud Interconnects 专用私有链路和 Knowledge Catalog 元数据自动同步，实现零拷贝、双向互操作的跨云分析。同日，阿里云 MaxCompute AI 助手 MaxAgent 正式版 GA，Beta 下线、Credits 计费体系就位、作业诊断与运维场景增强，并预告后续将支持 Data Agent 能力。前一天（7 月 29 日），AWS 发布 EMR Serverless 32 vCPU 大规格 Worker 实测报告——在 126 个 TPC-DS/TPC-H 查询中，搭配 shuffle-optimized 磁盘的新配置实现平均 29% 提速、29% 降本，shuffle-heavy 多表 Join 场景峰值达 45-55%。三条动态从跨云端互通层、执行引擎层到运维工具层，共同指向一个正在加速成形的趋势：数据基础设施不再假设”数据先集中再分析”，而是为”数据留在原地、Agent 跨云发现和查询”的新范式铺设物理和软件基础。

---

Google Cloud 无界湖仓发布：Iceberg REST Catalog Federation 打通 AWS Glue/Databricks Unity/Snowflake Horizon，Cross-Cloud Interconnects 私有链路就位

事件概述

2026 年 7 月 30 日，Google Cloud 数据库、数据分析及 Looker 产品副总裁 Sirish Chandrasekaran 与工程高级总监 Will Ochandarena 在 Next Tokyo 大会上联合发布了 Borderless Lakehouse（无界湖仓） 重大增强。核心里程碑：Iceberg REST Catalog Federation 进入 Preview，首批支持 AWS Glue、Databricks Unity Catalog 和 Snowflake Horizon 三个外部 Catalog 的联邦访问。同时发布的配套基础设施包括：Cross-Cloud Interconnects 专用私有链路（1G-100G 按需扩容，固定月费）、Knowledge Catalog 对三方 Catalog 元数据的自动同步与语义翻译、以及 Data Agent Kit + Conversational Analytics API 的 Agent 集成。这一组合让 BigQuery、Managed Spark 和任何 Iceberg 兼容引擎能够在不拷贝数据的情况下，安全地发现和查询分布在 AWS、Azure、Databricks 和 Snowflake 上的数据，同时通过对端 Catalog 的语义元数据同步为 AI Agent 提供跨云统一上下文。

技术解析

• Catalog Federation 的双向互操作架构：与传统的单向联邦查询（只读外部表）不同，Iceberg REST Catalog Federation 支持双向数据流——BigQuery 和 Managed Spark 可以查询外部 Catalog 中的 Iceberg 表，同时经过 Google AI 增强后的派生数据集可以写回对端 Catalog 供下游消费。这一”读-增强-写回”闭环在代理商场景中具有直接价值：Agent 在 BigQuery 中使用 Gemini AI 模型对 AWS 上的原始 Iceberg 数据做推理增强，将结果以新的 Iceberg 快照形式写回 Unity Catalog 供 Databricks 工作负载使用。Google 明确宣称这是”零拷贝”架构——没有中间数据复制、没有数据共享费用。

• Cross-Cloud Interconnects：把网络变成固定成本：跨云分析的最大隐性成本不是计算，而是数据出口费用和网络延迟。Google 的 Cross-Cloud Interconnects 方案通过专用物理链路将跨云数据传输从”按流量计费”变为”按带宽订阅”——1G 到 100G 的 SLA 保障连接，固定月费。配合智能跨云缓存（intelligent cross-cloud caching）——将远程数据片段临时缓存在 Google Cloud 侧以避免重复跨云查询的重复传输——形成了一套从网络层到查询层的多层跨云 I/O 优化策略。Google 还特别强调了对 AWS 数据的零浮动出口费承诺（需支付接入小时费）。

• Knowledge Catalog 作为”跨云语义桥梁”：无界湖仓的 Runtime Catalog 自动同步 AWS Glue、Databricks Unity Catalog、Snowflake Horizon 三类外部 Catalog 的表名、列信息、分区策略等原始元数据。Knowledge Catalog 在此基础上进行”语义翻译”——将原始 Schema 映射为业务术语、构建跨数据源的列级血缘图谱，并在 Schema 变更时自动更新语义映射。这是对”Agent 需要理解数据语义”这一刚性需求的基础设施级回应——当 Agent 面对分布在三朵云上的数十万张表时，它需要的不是一个”表清单”，而是一套可以机械理解的”这些表是什么意思、它们之间是什么关系”的语义层。

• 经济模型创新：230x Token 缩减：Google 在博文中披露了一个意味深长的成本数据——使用 BigQuery 的内置成本优化 AI 函数（自动路由到较小蒸馏模型），客户实测 Token 消耗降低至原来的 1/230。背后逻辑是：与其让 Agent 加载完整 Schema + 数据快照到 LLM prompt 中（Token 黑洞），不如通过 Knowledge Catalog 只投喂该查询真正需要的精准上下文。这一经济模型直接关系到 Agent 驱动数据分析的商业可行性——如果每个自然语言查询的上下文 Token 成本比查询本身的计算成本还高，Agent 优先的数据消费就无从谈起。

• 完整的供给侧布局：除了 Catalog Federation 和网络层，Google 还同步推进了 Lakehouse Federation for AlloyDB（事务数据库可直接查询湖仓）、Spanner Omni（跨环境运行）、零拷贝 SaaS 集成（SAP、Salesforce、Workday 等应用数据直接作为 BigQuery 外部数据源）。这一布局的完整叙事是：从 OLTP 到 OLAP、从自有数据仓库到对端 SaaS 应用、从本地到多云端——所有”数据所在的地方”都被纳入无界湖仓的查询范围，Agent 不需要关心数据在哪。

行业影响

将 Borderless Lakehouse 与一天前（Vol.38）的 Conversational Analytics 多云端 GA 放在一起看，Google Cloud 的 2026 年 7 月是一条精心编排的双线叙事：7 月 29 日发布的 CA GA 回答了”Agent 怎么用自然语言访问数据”（消费端），7 月 30 日发布的 Borderless Lakehouse 回答了”数据分布在各朵云上怎么办”（供给侧）。两线交叉处就是 Vol.37-38 持续追踪的 Agent-First DataInfra 叙事——Google 不是在做”又一个联邦查询引擎”，而是在搭建一整套”Agent 优先”的数据基础设施架构。

值得关注的是，Google 选择在 Next Tokyo（而非北美主场）发布这一战略级产品增强，可能反映了亚太市场对多云和混合云部署的强烈需求——日本和亚太企业长期面临”数据分布在本地数据中心 + 多朵公有云”的现实，对跨云数据互操作的需求远比”All-in 一朵云”的北美市场更迫切。

从竞争格局看，Borderless Lakehouse 的 Catalog Federation 直接对标了 Databricks 的 Unity Catalog 开放联邦愿景（Vol.32 报道的 Lakebase Postgres 和 Vol.36 报道的 Catalog Commits），但 Google 选择了一条不同的路径：以 Iceberg REST Catalog 为标准协议，以 Knowledge Catalog 为语义中枢，以 Cross-Cloud Interconnects 为物理基础设施——这是一套”联通而非统一”的架构哲学，与 Databricks “统一在 Unity Catalog 之下”的路线形成了有趣的对照。两者谁能更快落地、更多引擎接入，将是 2026 H2 DataInfra 领域最值得追踪的竞争线之一。

相关链接

• Google Cloud Blog: Introducing the borderless Lakehouse
• Google Cloud Lakehouse 文档
• Cross-Cloud Interconnects 文档
• BigQuery AI Functions 成本优化

---

AWS EMR Serverless 大规格 Worker 实测：32 vCPU + shuffle-optimized 磁盘实现 29% 提速降本，零回归案例

事件概述

2026 年 7 月 29 日，AWS 大数据博客发布了 Karthik Prabhakar、Arun Maniyan、Neil Mukerje 三位工程师联合撰写的 EMR Serverless 新 Worker 配置实测报告。核心发布：32 vCPU / 244 GB 内存 / 2000 GB shuffle-optimized 磁盘 大规格 Worker 正式可用。AWS 工程团队在 3 TB TPC-DS（104 查询）和 1 TB TPC-H（22 查询）两个标准基准上进行了严格的 A/B 测试——大规格 Worker（6 个 executor × 32 vCPU）对比小规格 Worker（48 个 executor × 4 vCPU），总 vCPU 相同（192），但平均查询速度提升 29%、成本降低 29%，126 个查询零回归案例。shuffle-heavy 多表 Join 查询的峰值收益达 45-55%。

技术解析

• shuffle-optimized 磁盘不是噱头：AWS 在这篇博文中首次系统披露了 shuffle-optimized 磁盘的技术原理——它随容量线性扩展 IOPS 和吞吐量，在大规格 Worker（8+ vCPU）上自动启用。在 Spark shuffle 操作中，数据先写入本地磁盘再通过网络分发给远端的 reducer——普通磁盘的随机读写瓶颈直接决定了 shuffle 耗时。shuffle-optimized 磁盘通过提升随机 I/O 吞吐，让”写本地 shuffle 文件→读 shuffle 文件发给远程 reducer”这条关键路径不再受磁盘限制。AWS 的定价模型也支持这一设计逻辑：磁盘是 EMR Serverless 三个计费维度中最便宜的（$0.000111/GB-hour，比 vCPU 便宜 474 倍），磁盘应该被当作”性能杠杆”而非”成本杠杆”——多配磁盘让 shuffle 变快、作业提前结束，少花的 vCPU 和内存费用远超多的磁盘费用。

• 少 executor、多内存 = 少网络协调开销：6 个大 executor 对比 48 个小 executor，意味着每个 executor 在 shuffle 时只需从 5 个而非 47 个远端拉取数据块——这大幅减少了 shuffle 阶段的网络连接建立、协调和失败重试开销，同时提高了”本地读取的 shuffle 数据”占比。而在 244 GB 的大内存配置下，内存溢写（spill）的概率显著降低——对于数据倾斜和大量缓存中间结果的场景，这是最直接的性能提升来源。

• 适用场景的清晰边界：AWS 给出了明确的”该用”和”不该用”决策规则。该用：(1) Spark History Server Stages 标签页中 Shuffle Read/Write 量大的作业，(2) Spill (memory/disk) 频繁或峰值 JVM 内存接近��置上限的作业。不该用：I/O 密集型工作负载（运行时主要由读写数据时间主导，而非 shuffle 或内存压力）——此时更多中等规格 Worker 可以发挥更充足的读写并行度。

• 成本透明的实测报告值得关注：AWS 这篇博文的与众不同之处在于，它不像典型的”新功能发布”公告那样只给性能曲线——而是逐条拆解了计费公式 $15.37 vs$19.87（TPC-DS）和 $5.20 vs$8.28（TPC-H），清晰展示了磁盘成本仅占 $1.03/$15.37（约 6.7%）这一反直觉事实，从而论证”多配磁盘就是省钱”的论据。

行业影响

大规格 Worker 的发布看似只是一个硬件选项的增加，但实际上代表了一个更深的趋势：Serverless 大数据引擎正在从”替用户省集群管理”向”替用户做性能工程”演进。传统的自管理 Spark 集群上，调优 executor 大小、磁盘类型、shuffle 分区数是高级 Spark 工程师的看家本领——同一份代码、同一批数据，调对参数和调错参数可以有 3-5 倍的性能差距。EMR Serverless 的大规格 Worker + shuffle-optimized 磁盘组合，本质上是将这部分”人类专家的经验调优”编码为 AWS 推荐的硬件配置——用户不需要理解 shuffle 的底层原理，只需把重 shuffle 作业丢到大规格 Worker 上就跑。

从一个更广的视角看，这一趋势与 Vol.38 报道的 AWS Spark Upgrade Agent 共享同一个主题：DataInfra 运维正在从”专业工程师的手工艺术”向”平台级自动化和推荐系统”过渡。Spark Upgrade Agent 解决了”怎么迁移”，大规格 Worker 解决了”怎么配硬件”——两者都是将专家知识产品化为平台能力的案例。

相关链接

• AWS Big Data Blog: Accelerate Spark on EMR Serverless with larger workers and shuffle-optimized disks
• Amazon EMR Serverless Worker Configurations 文档

---

阿里云 MaxCompute MaxAgent 正式版 GA：Beta 下线、Credits 计费就位、运维场景增强

事件概述

2026 年 7 月 30 日，阿里云 MaxCompute AI 助手 MaxAgent 正式版在华东 1（杭州）、华东 2（上海）、华北 2（北京）、华北 3（张家口）、华北 6（乌兰察布）、华南 1（深圳）、西南 1（成都）七个地域同步上线，Beta 版本同期下线。此前一个月，MaxCompute 于 7 月 13 日发布了 Agentic 生态接入套件（MCP Server、Skills、CatalogAPI SDK、CLI 四大组件），MaxAgent 是这一策略在”运维侧的 AI-Native 入口”。正式版的核心变化：(1) Credits 商业计费体系——开通标准版后每月赠送固定免费 Credits，超出后可购买 Credits 包；(2) 增强的作业诊断创建能力——从原来的”被动问答”升级为主动诊断和创建运维动作；(3) 新增运维场景覆盖。公告同时透露后续将支持 Data Agent 能力——即从运维助手扩展为数据探索和分析 Agent。

技术解析

• “运维 AI Agent”的产品化路径：MaxAgent 的 Beta→GA 演进提供了一条具有参考价值的 Agent 产品化路线——Beta 阶段的能力是”智能问答 + 资源查询”（“这个 Quota 用了多少？""为什么这个作业跑了这么慢？”），这些是检索增强生成（RAG）的典型场景；正式版增加了作业诊断创建能力——Agent 不仅要”说出问题”，还要能”发起诊断作业”——这需要 Agent 具备对 MaxCompute 内部状态的写入权限和操作语义理解，是比纯净的”只读 RAG”更高的工程复杂度。公告中预告的 Data Agent 能力将再进一步：Agent 不再只管理平台，而是直接消费平台上的数据。

• Credits 计费：Agent 作为独立产品线的信号：将 Agent 能力从”免费附加功能”升级为”独立 Credits 计费”是一个重要的商业信号——这意味着阿里云认为 MaxAgent 不是某个产品的附属特性，而是有独立商业价值的产品线。结合 Vol.37 报道的 Dataphin V6.2 将 Dataset API 定位为”AI Agent 的开箱即用知识查询服务”，阿里云大数据产品矩阵在 2026 年 7 月完成了运维 Agent（MaxAgent）+ 治理平台（Dataphin V6.2）+ 开发工具（Agentic 套件） 的三层 Agent-First 布局。

• 与 Google、AWS 的对话：有趣的是，MaxAgent GA 与本期第一、二条动态形成了中美两套云生态在 Agent-First DataInfra 路线上的结构性对照。Google 从”跨云联通”（Borderless Lakehouse）和”自然语言查询”（CA GA）两个方向推进，AWS 从”硬件优化”（大规格 Worker）和”运维自动化”（Spark Upgrade Agent）两个方向推进，阿里云从”治理平台 Agent 化”（Dataphin）和”引擎运维 Agent 化”（MaxAgent）两个方向推进——三方不约而同地在 2026 年 7 月将 Agent 从”产品特性”提升为”产品战略”。区别在于，Google 和 AWS 的 Agent 战略更多围绕”如何让外部 Agent 用好我的数据基础设施”，而阿里云的 Agent 战略更多围绕”如何让我的数据基础设施本身成为 Agent 的工作台”——前者的视角是”服务 Agent”，后者的视角是”成为 Agent”。

行业影响

MaxAgent GA 对国内 DataInfra 从业者的直接影响有限——它本质上是 MaxCompute 产品的内部能力升级。但它的信号价值不容忽视：在短短一个月内（7 月 13 日 Agentic 套件 → 7 月 26 日 Dataphin V6.2 → 7 月 30 日 MaxAgent GA），阿里云大数据产品矩阵完成了一次从”数据平台”到”Agent-Native 数据基础设施”的战略转型。这不是孤立的几个功能发布，而是一条连贯的产品演进线。对于国内 DataInfra 创业公司和团队来说，这意味着”如何让自己的数据平台变成 Agent 的工作台”已经不再是可选的差异化方向，而是与头部云厂商对齐的基线要求。

相关链接

• MaxCompute MaxAgent 正式版 Region 开放公告 (阿里云 Help)
• MaxCompute Agentic 生态接入套件发布公告
• MaxAgent 快速上手指南

---

编者评

三条同日历的动态表面看分属不同厂商和产品线，但共享一个深层前提：数据基础设施的架构假设正在发生根本性翻转——从”数据来就 Agent”变为”Agent 去找数据”。Google 的无界湖仓用 Iceberg REST Catalog Federation 解决了”怎么让 Agent 找到和查询散落在不同云上的数据”，AWS 的大规格 Worker 解决了”Agent 驱动的分析负载用什么硬件配置最高效”，阿里云的 MaxAgent 解决了”数据平台本身的运维和管理怎么 Agent 化”。三个命题分别对应数据分布、执行效率和运维范式——任何一个没有解决，Agent-First DataInfra 的完整图景都无法落地。

回顾从 Vol.34（7 月 19 日）开始的 6 期期刊，可以清晰看到一条叙事弧线：格式层（OKF v0.2）→ 平台层（Dataphin V6.2, MaxAgent GA）→ 架构层（Joe Reis DuckDB-per-Agent）→ 跨云联通层（SAP BDC Connect, Borderless Lakehouse）→ 运维工具层（Spark Upgrade Agent）→ 执行引擎层（EMR 大规格 Worker）。六层叠加，Agent-First DataInfra 的拼图正在 2026 年 7 月的最后两周以惊人的速度一块块到位。一个值得持续追问的问题是：当所有基础设施都为”Agent 是数据的主要消费者”这一假设重新设计后，人类数据工程师的角色将发生什么变化？ 是退化为”Agent 的管理员”，还是升维为”Agent 工作流的设计师”？这个问题的答案，或许将在未来 6-12 个月内通过各大云厂商的招聘 JD 而非产品公告给出。

本期与 Vol.38 仅相隔一天——这本身也是一个信号：DataInfra 领域的发布节奏正在加速，Agent-First 转型不是渐进式的线性演进，而是多厂商在同一时间窗口内的集中发力。 建议读者将 Vol.38（CA 多云端 GA + SAP BDC Connect + Spark Upgrade Agent）与本期放在一起阅读——两期共同构成了 2026 年 7 月末 Google Cloud 和 AWS 的双线 Agent-First 攻势全景。