datainfra前沿动态 · Vol.49

Ray 引入 NVLink 域感知放置组让 GB300 训练提速 13%；BigQuery Graph 统一图关系与业务指标赋能可信 Agent；AWS 用 Blame Graph 追溯多 Agent 级联决策失败根因；阿里云 AnalyticDB 推出全自动 Iceberg 表优化服务

本期聚焦四条 DataInfra 动态：Anyscale 为 Ray 引入 NVLink 域感知放置组，通过 topology_strategy 声明让放置组严格落在同一 NVLink 域内，在 NVIDIA GB300 NVL72 上的真实 VLA 预训练中实现 1.13 倍迭代提速，让调度器第一次理解机架级 GPU 拓扑；Google Cloud 为 BigQuery Graph 增加 measures 支持（预览），将受治理的业务指标与属性图关系统一在库内，让 Agent 通过 GRAPH_EXPAND 原生回答'为什么'而非只会报'是什么'；AWS 在 OpenSearch Service 上构建 Blame Graph，用嵌入相似度衡量 Agent 间影响力、从失败决策反向归因，9 次运行正确归因 6 次、归因仅耗时 74 毫秒；阿里云 AnalyticDB for MySQL 推出面向 Iceberg 的 Table Service 全自动表优化服务，以策略配置取代手写 Spark 脚本，小文件合并、元数据压缩（查询规划从 600MB 元数据降到 MB 级）、文件级 Bitmap 索引与冷热分层（存储成本降低约 60%）全部自动化。

DataInfra Ray Anyscale NVIDIA GB300 NVLink Domain Placement Group 拓扑感知调度 VLA BigQuery Graph Property Graph Measures Agentic AI Google Cloud Blame Graph OpenSearch Bedrock 多Agent可观测性 AWS 阿里云 AnalyticDB Iceberg 表优化 Bitmap Index 冷热分层

本期追踪到四条 DataInfra 动态，分别落在计算调度、数据语义、Agent 可观测性与表服务自动化四个层面，但它们共享同一条主线：AI Agent 时代，数据基础设施正在把”人类运维者默认知道的上下文”——物理拓扑、业务关系、决策证据链、表健康度——显式地编码进系统本身。2026 年 8 月 13 日，Anyscale 发布博客介绍 Ray 新增的 NVLink 域感知放置组（NVLink Domain-Aware Placement Groups）：在 NVIDIA GB300 NVL72 机架级 NVLink 互联成为常态的今天，Ray 通过一个 topology_strategy 字段让放置组声明”必须落在同一 NVLink 域内”，并在与 NVIDIA GEAR 实验室合作的 512 GPU VLA 预训练中实现 1.13 倍迭代提速——调度器第一次理解机架级 GPU 拓扑。8 月 14 日，Google Cloud 为 BigQuery Graph 增加 measures 支持（预览），把受治理的业务指标直接定义为属性图中的 MEASURE，让 Agent 用标准 SQL 的 GRAPH_EXPAND + AGG 在”计算器（SQL）“与”地图（图）“之间自由切换，回答”冬装销量为何在 Seattle 下降 12%“这类需要多跳业务关系的问题。同日，AWS 在 OpenSearch Service 上展示了 Blame Graph（归责图）：用 Titan Embeddings 嵌入每条 Agent 声明、以余弦相似度度量 Agent 间影响力、从失败决策反向归因，9 次运行正确归因 6 次，归因计算仅 74 毫秒——并诚实标注了”影响力≠责任”这一关键局限。而 8 月 14 日阿里云发布的 AnalyticDB for MySQL Table Service for Iceberg，则把过去靠手写 Spark 脚本完成的小文件合并、快照清理、元数据压缩、冷热分层全部变成控制台里的策略配置，典型场景下查询提速 10-15 倍、存储成本降低约 60%。四条动态共同指向：当 Agent 开始大规模消费数据基础设施时，“上下文”从运维者的经验变成系统的原生能力——而能否把这四层上下文自动化，决定了 DataInfra 能否真正承接 Agentic AI 的工作负载。

事件概述

2026 年 8 月 13 日，Anyscale 发布博客《Maximizing the Power of NVIDIA GB300 NVL72: NVLink Domain-Aware Placement Groups in Ray》，作者为 Joshua Lee、Mengjin Yan 等 6 人。文章直指一个此前被分布式调度器系统性忽略的问题：NVIDIA GB200/GB300 NVL72 通过机架级 NVLink 扩展互联，将 72 块 Blackwell GPU 与 36 块 Grace CPU 以每 GPU 1,800 GB/s 的全对全带宽连成一个”超级节点”，但 Ray 原有的放置组（Placement Group）调度模型只有节点级的 PACK/STRICT_PACK 语义，完全无法表达”这些 bundle 必须落在同一个 NVLink 域（同一机架）内”的拓扑意图——结果是在 72-GPU 机架集群上，跨节点的通信密集型工作负载会静默地把 actor 打散到不同机架，白白浪费 NVLink 高速互联。

技术解析

  • topology_strategy 声明式拓扑意图：用户在放置组 API 中新增一个字段即可表达拓扑约束，例如 topology_strategy = {ray.io/node-id: "PACK", ray.io/gpu-domain: "STRICT_PACK"}——在节点层面紧凑打包，同时要求所有 bundle 严格落在同一个 NVLink 域内。16 个各需 4 GPU + 2 CPU 的 bundle 可以被明确要求放入同一个 GB300 机架（16 节点 × 4 GPU = 64 GPU），替代此前给机架手动打 "ray.io/gpu-domain"="rack-7" 标签再用 bundle_label_selector 固定的易错方案。

  • 拓扑检测与容错的深度耦合：Ray 通过 ray.io/gpu-domain 标签识别节点所属的 NVLink 域（对应物理机架），调度器在满足资源需求的同时强制域内放置，多机架集群中会选择有足够剩余容量的机架容纳整个放置组。更重要的是容错逻辑：节点故障或维护时，Ray 优先从同一 NVLink 域选取替代节点，而非把工作负载打散到其他机架；只有当整个放置组的所有 bundle 都宕机时，才会整体迁移到新域。这让长时间训练中的故障处理显著简化。

  • 性能收益与适用场景：与 NVIDIA GEAR 研究实验室合作的 GB300 集群 VLA（Vision Language Action）预训练中，512 GPU（128 节点）分为 8 组 × 64 GPU，域感知放置后迭代速度提升 1.13 倍——因为 all_reduce 等集合通信走 NVLink 而非慢速跨域路径，还能利用 NVIDIA SHARP 等加速特性。除训练外，分离式推理（prefill/decode 需在同一域内交换 KV cache）与 RL 工作负载（策略训练 worker 同域、通信较轻组件灵活调度）都是典型受益场景。当前仅支持 STRICT_PACK，STRICT_SPREAD 与嵌套拓扑（机架→数据中心→可用区）已在规划中。

行业影响

这条动态的深层意义在于：AI 基础设施的调度抽象正在从”资源数量”走向”物理拓扑”。GB300 NVL72 把机架变成了一个逻辑计算单元，但调度器若仍以”节点”为最小单位，就永远无法兑现 NVLink 域互联的性能承诺。Ray 的做法——用声明式 topology_strategy 把拓扑意图交给用户、把拓扑发现与容错留给系统——很可能成为 GPU 调度领域的通用范式，并反过来影响数据管道调度：当数据引擎（如 Spark/Ray Data）跑在 GB300 集群上时，shuffle、广播等数据密集算子同样能从域感知调度中获益。这也是 DataInfra 与 AI 基础设施融合的一个具体交点：计算拓扑感知不再只是 MPI 时代的课题，而正在成为分布式数据与 AI 引擎的默认能力。

相关链接

BigQuery Graph 增加 measures：把受治理指标与业务关系统一进属性图，让 Agent 回答”为什么”

事件概述

2026 年 8 月 14 日，Google Cloud 发布博客《Using BigQuery Graphs with measures for trusted agentic workloads》，作者为 Deepak Dayama（Group Product Manager）与 Yun Zhang（Software Development Manager）。文章针对 Agentic AI 的经典痛点：Agent 直接查询扁平原始表时容易产生不准确洞察——它能报出”西雅图冬装销量下降 12%“的 what，却无法回答”为什么”——因为答案藏在多跳业务关系中：Seattle 订单 → 配送中心 → 被区域风暴延误的供应商。BigQuery Graph 的 measures 支持（预览）正是为此而生：将业务指标（measures）直接定义在属性图（Property Graph）中，实现”零 ETL”地把现有表映射为图，让 Agent 以标准 SQL 同时拥有计算器（SQL 指标）与地图（图关系）两种能力。

技术解析

  • MEASURE 定义在 Property Graph DDL 中：数据建模者可在属性图定义中直接声明 MEASURE(SUM(num_of_item)) AS total_items 这类聚合指标，而无需单独维护一套指标表。查询时通过标准 SQL 的 GRAPH_EXPAND 函数与 AGG 聚合器，引擎先解析结构化的图路径、再评估指标——这从根上规避了”图遍历时标准 SQL join 导致行复制、进而聚合计算错误”的历史难题。以零售场景为例，CREATE OR REPLACE PROPERTY GRAPH 可以把 users、orders 表映射为节点/边，并在 Order 标签上直接挂 MEASURE。

  • BigQuery Studio 的民主化工具链：可视化图建模器（无代码拖拽式构建属性图、节点与边）降低了 DDL 门槛；Conversational Analytics（CA）集成则让用户以自然语言与图交互——CA 代理不再猜测表 join，而是沿着确定性的关系图把自然语言问题转换为边界受约束的 GoogleSQL 或 ISO GQL 查询，从机制上防止模型幻觉并保证语义一致性。

  • 与 Looker 语义层的库内统一：为避免”一套团队在图数据库里维护关系、另一套团队在 SQL 里维护指标”的碎片化，BigQuery Graph 与 Looker（LookML）原生集成——通过 sql_analytic_model_name 让 Looker 直接指向库内定义的图，或用 derived_analytic_model 在 LookML 视图内定义图 schema 由 Looker 生成 DDL 维护；整个图生命周期（Looker IDE、Git 版本控制、CI）纳入企业级 DevOps 流程，核心 KPI（如 Churn Rate）在库内保持一致、可验证、可信。

  • 从”是什么”到”为什么”的认知升级：文章明确提出三层演进——Metadata grounding（有什么数据）→ Business metrics（表现如何）→ Relationship mapping（为什么会这样）。Agent 在拿到”12% 下滑”这个 what 之后，可以继续沿图路径追问供应链延迟这个 why，从而避免给出”建议 15% 折扣促销”这类基于片面信息的错误行动。

行业影响

这条动态是”语义层”之争的又一块拼图。过去一周 Vol.47 报道了 Google 将 Looker 语义层通过 A2A 集成 Gemini Enterprise，本期 BigQuery Graph measures 则更进一步：语义不再只是”指标定义”（LookML/语义层），而是”指标 × 关系”的统一体，并且直接下沉到查询引擎内部（in-database）。对 Agent 而言，图提供了比语义层更丰富的推理上下文（多跳关系），而 measures 提供了语义层擅长的受治理指标——两者合一，正是”可信 Agent 数据访问”的完整答案。对 DataInfra 从业者的启示是：属性图正在从图数据库的专属领域，变成数据湖/数仓引擎的原生查询能力（BigQuery Graph、Spanner Graph、Neo4j 与数仓的融合均是佐证），“关系即数据”的建模方式正在回归主流。

相关链接

AWS 展示 Blame Graph：用嵌入相似度为多 Agent 决策失败反向归因，74 毫秒定位根因

事件概述

2026 年 8 月 14 日，AWS 在 Big Data Blog 发布《Trace cascading decision failures with a blame graph on Amazon OpenSearch Service》，作者为 Jon Handler 与 Smita Singh。文章直击多 Agent 协作系统的可观测性空白：当多个 AI Agent 协作做决策且最终结果错误时，标准日志无法告诉你”是哪个 Agent 导致的”。AWS 的方案是将多 Agent 推理过程建模为一张图——每条”声明”（claim）是节点、声明间引用关系是边——用影响力（influence）度量衡量上游 Agent 输出对下游决策的贡献，再从失败的最终决策出发沿图反向遍历，找到贡献最大的根因 Agent。文章诚实承认：目前业界尚无多 Agent LLM 管道根因归因的标准化方法，该方案是信用分配（credit assignment）与嵌入相似度（embedding similarity）的结合，辅以 LLM-as-a-judge 式检查。

技术解析

  • 影响力 = 嵌入余弦相似度：每个 Agent 产生的每条声明由 Amazon Titan Text Embeddings V2 嵌入为向量；当下游 Agent 引用某信息时，计算该引用与每个上游声明的余弦相似度作为”影响力分数”，连同源/目标 Agent ID 存储为图的边。反向遍历时，贡献最大的 Agent 获得最多归责。系统还记录三项辅助指标：可解释性分数（决策可追溯到多少证据）、归因置信度、异议是否被否决（dissenting agent overruled）。

  • 技术栈与实验设计：五 Agent 管道（研究员 → 风险分析师 → 估值分析师 → 宏观经济学家 → 策略师，最终给出 BUY/SELL/HOLD）由 Bedrock 上的 Claude Sonnet 4.5 驱动；OpenSearch Service 维护 7 个索引（含 kNN 向量的声明索引、归责索引、指标索引、事件索引），OpenSearch UI 应用提供交互式调查界面。实验设计了三种确定性故障模式：幻觉（研究员编造不存在的合作关系）、被压制的异议（风险分析师标记监管风险但被策略师以 0.15 低权重否决）、陈旧数据（研究员遗漏三天前的文件）。

  • 实测效果：9 次运行中正确归因 6 次（67% 准确率），幻觉与陈旧数据场景均正确指向研究员（分数约 0.45-0.46）；全流程端到端约 25 秒，归因本身仅约 74 毫秒——便宜到可以在每次管道执行时持续运行而非仅故障后触发。启用全部三个守护规则（异议否决、来源交叉验证、数据新鲜度检查）后，原本会亏损的 BUY 决策均被拦截，示例场景避免约 379 万美元损失。

  • 关键局限：影响力 ≠ 责任：“被压制的异议”场景归因错误——归责图把风险分析师标为根因（0.37），但真正的失败者是忽视警告的策略师。原因在于影响力衡量的是”声明传播的强度”而非”谁做了错误判断”：异议声明独特且被直接追踪所以分数高，但策略师看到警告仍选择忽略才是失败点。结论：影响力告诉你”什么被传播了”，异议标记告诉你”什么被错误忽略了”，两者都需要。

行业影响

Blame Graph 的意义不在技术栈（OpenSearch + Bedrock 都是现成组件），而在它第一次为”多 Agent 决策失败归因”提出了可操作的方法论——这恰好是 Agentic AI 从演示走向生产最缺失的一块拼图。其”74 毫秒归因、可在每次管道执行时持续运行”的成本特性，暗示Agent 可观测性正在从”事后救火”变成”持续审计”；而”影响力≠责任”的诚实标注，则为整个行业划定了方法论边界：归因图是决策审计的辅助工具，不是权威结论。对 DataInfra 而言，这标志着图数据库/向量索引（OpenSearch kNN）从”数据查询”角色延伸到”Agent 推理链路审计”角色——数据基础设施的可观测性对象，正在从管道与查询，扩展到 Agent 的推理与决策本身。

相关链接

阿里云 AnalyticDB 推出 Table Service：策略化配置取代 Spark 脚本，Iceberg 表优化全自动

事件概述

2026 年 8 月 14 日，阿里云 ApsaraDB 团队在阿里云社区发布《Goodbye Spark Scripts: Fully Automated Table Optimization in AnalyticDB for MySQL》，介绍 AnalyticDB for MySQL 的 Iceberg Table Service——一个全自动表优化服务，用控制台里的策略配置取代手写 Spark 脚本，同时加速查询并降低存储成本。痛点非常普遍：Iceberg 表持续写入后小文件悄悄堆积、历史快照累积、查询性能逐渐劣化、存储成本持续攀升，而手写 Spark 脚本做小文件压缩、快照清理、冷数据分级是每个湖仓团队都做过又都讨厌的脏活。Table Service 目前正在 AnalyticDB for MySQL 湖仓版与企业版逐步开放（可提交工单申请试用）。

技术解析

  • 查询加速五件套：自动小文件合并（碎片小文件合并为合适大小，避免逐个小文件扫描）、智能排序优化（按最常查询列重组数据分布，扫描量可降数倍）、自动元数据压缩（重组 manifest 层级，查询规划从数十秒降到亚秒级）、文件级 Bitmap 索引（指定列上构建位图索引，等值/IN 查询典型场景提速 60%+）、热数据预缓存（高频分区预载入本地缓存，峰值期直接命中缓存，Spark 查询实测提速约 3 倍）。

  • 成本优化六件套：自动冷热分层（按策略将历史数据迁移至 IA/Archive/Cold Archive，存储成本可降至原来的 1/10）、自动过期分区回收（如日志保留 30 天、明细保留 365 天，到期自动清理）、自动历史快照清理（释放旧版本占用的”隐形”存储）、自动孤儿文件清理、按需冷数据恢复（一条 SQL 即可恢复指定分区，如 CALL catalog.system.restore_files(table=>'log_db.app_logs', where=>"dt='2025-11-11'", days=>3)）、以及可选的 LakeCache 预热（按缓存量计费，约 CNY 1.44/GB/月）。

  • 实测数据：日志场景每天写入 500GB、保留一年、全量 Standard 存储月成本约 CNY 22,426，冷热分层后降至约 CNY 8,947/月（年省约 16.2 万元，降幅约 60%）；元数据压缩案例中，频繁写入导致单次查询规划需读约 120 个 manifest（约 600MB 元数据），压缩后按分区重组 manifest 索引（不移动数据文件），查询规划元数据降到 MB 级，典型 XIHE 查询从 20-30 秒降至约 2 秒（10-15 倍）；自研文件级 Bitmap 索引在 1,349 个数据文件的表上把 user_id 等值查询从扫描全部文件收窄到 1 个文件，查询从 4.2 分钟降至 1.8 分钟。

  • 设计决策：Bitmap 索引按数据文件粒度构建（一个数据文件对应一个索引文件），Spark executor 并行加载天然适配分布式；索引元数据纳入 Iceberg 事务管理避免并发写一致性问题；构建过程增量进行（只对新增文件建索引）；采用 fail-open 设计——索引出错时查询自动回退到无索引执行，查询本身永不报错。整个服务支持实例→库→表多级策略继承，可在控制台查看每张表的优化历史（合并了多少文件、释放多少空间）。

行业影响

这条动态与 Vol.47/48 连续报道的 Iceberg 生态演进形成呼应：表维护正在从”人工脚本运维”走向”声明式策略服务”。Dremio 同期强调”数据湖表存储随时间劣化、day-365 需要维护”、Iceberg 社区讨论 compaction 自动化，而阿里云把这一整套能力产品化为控制台内可配置的服务——这与 Databricks 的 AUTO CDC/声明式管道、Delta 的 OPTIMIZE 自动化是同一趋势在不同阵营的落地。对 DataInfra 从业者而言，其信号很清晰：“懂 Iceberg 内部细节 + 会写 Spark 优化脚本”正在从核心技能退化为”了解策略参数即可”；同时，将索引元数据纳入表格式事务管理、fail-open 降级这类工程决策，也为自建表维护系统提供了可复用的设计模式。这是本期少有的中文源深度技术内容，代表国内云厂商在湖仓表服务化上与全球头部厂商齐头并进。

相关链接

编者评

本期四条动态看似分散——Ray 的 GPU 拓扑调度、BigQuery 的图指标、AWS 的 Agent 归因、阿里云的表维护自动化——实则构成同一趋势的四个切面：AI Agent 正在倒逼数据基础设施把”上下文”从运维者的隐性经验，变成系统的显式能力。Ray 把”机架内 NVLink 高速互联”编码进放置组语义，让调度器知道 GPU 之间的物理距离；BigQuery Graph measures 把”业务关系与受治理指标”编码进查询引擎，让 Agent 知道指标之间的因果路径；AWS Blame Graph 把”决策证据链与 Agent 间影响力”编码进可查询的图索引，让多 Agent 系统从黑盒变成可审计；阿里云 Table Service 把”表健康度的维护知识”编码进策略服务，让湖仓的日常运维从脚本变成声明。四者共同回答的问题是：当 Agent 以远超人类的频率与规模消费数据时，哪些”本该由人知道的事”必须交给系统？答案正在从计算、存储、查询、运维四个层面同时展开——这也意味着 DataInfra 的价值锚点，正在从”支撑 BI 报表”迁移到”支撑可信的 Agentic 决策”，而本期恰好是这一迁移在 48 小时内四线并进的缩影。值得持续跟踪的下一站：这些”上下文编码”能力何时会反向标准化——正如本期 BigQuery Graph 之于属性图、Ray 之于拓扑调度、Blame Graph 之于 Agent 可观测性，谁先成为默认能力，谁就定义了下半年 DataInfra 的竞争格局。