datainfra前沿动态 · Vol.55

BigQuery Graph GA：一张 PROPERTY GRAPH 横跨 BigQuery 原生表与 Databricks/Glue/Snowflake 上的 Iceberg 表，无向遍历比预览期快 100 倍；TabFM 以 AI.PREDICT 进入 BigQuery，把回归与分类压成一次前向传播；AWS 把 Spark 排障代理做成托管 MCP 服务器，从 CloudWatch 告警到行号级根因约 2 分钟；MaxCompute 的 dbt 集成只读解析 manifest.json，把 semantic models 转成 OSI 语义包给 AI Query 复用

本期聚焦 DataInfra 四条动态，共同指向一条主线：厂商把「先搬动工件、再获得洞察」改成「在工件原地声明一次」——图不搬数据、预测不建模型、排障不搭服务器、dbt 不改工程。

DataInfra BigQuery Graph GQL Property Graph Borderless Lakehouse Apache Iceberg Databricks Unity Catalog AWS Glue Snowflake GraphRAG Context Graph BigQuery Agent Analytics TabFM AI.PREDICT AI.EVALUATE In-Context Learning TabArena TabPFN TabICL BigQuery ML AWS DevOps Agent Spark Troubleshooting Agent MCP Amazon EMR Spark History Server PySpark AWS PrivateLink MaxCompute dbt OSI 语义包 MaxFrame Open Semantic Interface 数据基础设施

第五十五期追踪到 DataInfra 领域四条动态：9 月 1 日 BigQuery Graph 正式 GA——ISO 标准 GQL 与 SQL 并列，借 borderless Lakehouse 让一张 property graph 横跨 BigQuery 原生表与 Databricks Unity Catalog / AWS Glue / Snowflake 上的 Iceberg 表原地遍历不搬数据，GQL 比预览期快 2 倍、无向遍历快 100 倍；TabFM 以 AI.PREDICT / AI.EVALUATE 两个 SQL 函数进入 BigQuery（preview）——Google Research 的表格基础模型把回归与分类压成一次前向传播，无需训练、调参与制品部署，在 TabArena 的 38 个分类 + 13 个回归数据集上跑赢调过参的传统模型；AWS 把 Apache Spark Troubleshooting Agent for Amazon EMR 做成 AWS 托管的 MCP 服务器——注册进 AWS DevOps Agent 后，从 CloudWatch 告警到带行号的根因约 2 分钟，全程走 PrivateLink 不出 AWS 网络；9 月 1 日阿里云 MaxCompute「AI 数据探索客户端」能力升级——dbt 集成以只读方式解析本地 manifest.json（不调用 dbt CLI、不改工程文件），并把 dbt semantic models / metrics 转成 OSI 语义包供 AI Query 复用。四条动态的厂商、层次、对象全不相同，手法却是一致的：把「先搬动某个工件、再获得洞察」改成「在工件原地声明一次」。

BigQuery Graph GA：一张 PROPERTY GRAPH 跨三朵云，无向遍历比预览期快 100 倍

事件概述

9 月 1 日，Google Cloud 宣布 BigQuery Graph 正式 GA。这个在 预览期 就打出「统一图分析与关系分析」口号的特性，GA 时的定位被明确成一句话：the knowledge foundation for the agentic era——给 AI agent 提供「关系上下文」的地基。

GA 的工程量分成两半。一半是图引擎本身更快、更能表达：官方给出的口径是，相对公开基准，GQL 执行比预览期快 2 倍，无向遍历快 100 倍，并在 ACYCLIC 与 TRAIL 两种路径模式下改进了环检测的速度与资源开销。另一半是围绕图建了一套 agent 生态：让 agent 能建图、能和图对话、能把自己在图上的行为留下可审计的记忆。

真正有分量的是它跨云的那一半。借助 borderless Lakehouse，单个 BigQuery Graph 可以覆盖 BigQuery 原生表和另外三朵云上的开放 Iceberg 表——Databricks Unity Catalog、AWS Glue、Snowflake——就地遍历，不复制数据，也不建 ETL 管道。官方给的 DDL 例子把这件事写得很直白：节点表分别来自 my_project.gcs_lake（Google Cloud 侧）和 my_project.dbx_fed_catalog（AWS 侧），CREATE OR REPLACE PROPERTY GRAPH 一次就把它们拼成一张虚拟知识图谱。

技术解析

  • 跨云虚拟图：数据不动，图定义动。传统做法是把需要建图的数据抽到独立的图数据库里，代价是多一套系统、一份副本和一条同步链路。BigQuery Graph 的做法是只把「节点表和边表的映射」声明下来：NODE TABLES 里指定各表的主键，EDGE TABLES 里用 SOURCE KEY / DESTINATION KEY 指回节点表。之后 GRAPH ... MATCH (c:Customer)-[:Bought]->(:Product)-[:Supplied_By]->(s:Supplier) 这样一条 GQL，就在两朵云的底层数据上一次遍历完成。节点表分布在哪个 catalog，对写查询的人是不可见的。

  • GQL 表达力补齐：CALL 语句与扩展子查询。GA 新增 CALL 语句 与扩展的图子查询支持，可以对结果集里的每个实体跑一次图子查询，也可以调用可复用的具名函数。这一条对 agent 场景的意义大于对分析师的意义：分析师手写的那个函数，恰好就是 agent 当作工具去调用的那个函数——人和 agent 共用同一层抽象，不是两套。

  • 不写 GQL 也能用图：BigQuery conversational analytics 支持直接用自然语言与图对话，它读 schema 里的关系把问题翻译成 SQL 或 GQL，对路径类答案还会把遍历过程可视化。关键在于 agent 会利用你在图上定义的 description 和 synonym 来保持 grounded——官方的说法是，正是「让图成为图」的那些关系，切掉了自由文本查询最容易被诟病的歧义与幻觉。你也可以通过 MCP server 把 Gemini Enterprise 接到 BigQuery Graph 上。

  • 让 agent 自己建图，并给出匹配率：官方把建图经验打包成了 Data Agent Kit 的一个 agent skill，在 Antigravity、Visual Studio Code、Claude Code、Codex 等工具里开箱可用，覆盖 GQL 模式匹配、图与 SQL 混合、以及推荐的 schema 设计实践。更值得注意的是它正在获得的「编写」能力：指向一个数据集、一份模型文档或一张 ER 图，它提议节点与边，在真正建图之前逐条拿数据验证，并把匹配率摆出来——这条关系解析度 98%，那条只有 56%。

  • 给 agent 一份可审计的记忆：BigQuery Agent Analytics 的 context graph 把 agent 的每一个动作捕获下来，塑成一张 context graph——一份带类型的、可查询的推理轨迹，就存在 BigQuery Graph 里。轨迹本身是图，于是「这个 agent 为什么这么做」变成一次遍历，而回连到这些决策上的结果，就成了改进下一次决策的数据。

行业影响

对独立图数据库厂商，这不是一次友好的发布。过去「要做多跳关系分析就得上图库」的默认前提，现在被拆成了两个可分别回答的问题：数据在哪、关系怎么声明。当关系可以在数据原来所在的地方声明，且跨云也能声明时，为图单独建一套系统的理由就只剩下「图库本身的算法与性能」这一条，而不是「关系查询做不了」。

对做 GraphRAG 的团队，变化更实际。此前的主流链路是「从文档里抽实体关系 → 写进图库 → 在图库上做检索」，中间那步写进图库既带来同步延迟，也把行级/列级安全甩在了外面。BigQuery Graph 的路线是图就建在仓内，安全策略继承现有的行级与列级权限，BQML 与 AI 函数可以在同一个查询里调用。官方列出的落地场景里，「从非结构化文档构建结构化知识图谱以 grounding Gemini 模型与 GraphRAG 工作流」只是其中一条，与威胁检测、供应链数字孪生、身份解析并列——它没有被当作唯一卖点。

TabFM 进入 BigQuery：把「训练—调参—部署」塌缩成一条 AI.PREDICT

事件概述

Google Research 的 TabFM 于 6 月 30 日发布，9 月 1 日起以 BigQuery 内置 SQL 函数的形态落地，目前处于 preview。它做的事可以概括成一句话：用一个预训练的表格基础模型，把回归与分类变成一次 SQL 查询。

调用方式就是两个新函数。AI.PREDICT 接收历史表和待预测表，指定 label_col，直接吐出预测列与概率列，模型根据目标列的数据类型自行判断这是分类还是回归：

SELECT *
FROM AI.PREDICT(
  TABLE `my_project.my_dataset.historical_transactions`,
  TABLE `my_project.my_dataset.new_transactions`,
  label_col => 'is_fraud'
);

AI.EVALUATE 则一步产出评估指标——回归给 r2_score、mean_absolute_error，分类给 precision、recall、f1。

技术解析

  • 把表格预测重构成 in-context learning：TabFM 不针对某个数据集更新参数，而是把历史样本和目标行一起当作一次统一的前向传播输入，模型在推理时直接从上下文里读出列与列、行与行之间的关系。这跟传统 ML 的范式差异是根本性的：XGBoost 需要 .fit() 拟合出该数据分布上的参数，TabFM 什么都不拟合。

  • 三段式混合架构：表格不是一维有序序列，交换两行或两列不改变含义，所以不能直接套语言模型的 tokenize 方式。TabFM 把 TabPFN 与 TabICL 两条路线合成了一个混合设计：先用多层 attention 在列（特征）与行（样本）两个维度上交替注意力（这一步承担了原本由人工特征工程完成的活），再把每行跨注意力后的丰富信息压缩成一个稠密向量，最后由一个 Transformer 在这一串压缩向量上做 ICL。第三步沿用 TabICL 的做法——注意力作用在压缩后的行向量而非原始网格上——把计算成本压下来。

  • 训练数据全部是合成的：高质量的多样化表格数据，尤其是能反映工业级分析场景的大表，在开源世界里极度稀缺；工业表往往带着专有 schema 和敏感信息，拿不到。合成表可以任意大，于是成了这个规模上唯一可行的预训练路径。TabFM 完全在数亿个合成数据集上训练，这些数据由引入多种随机函数的结构因果模型（SCM）动态生成。

  • 基准与两种配置：评测跑在 TabArena 上，覆盖 38 个分类数据集和 13 个回归数据集，样本规模从 700 到 150,000，以 Elo 分数计分。官方给了两个配置：TabFM 是开箱即用，单次前向传播，不调参不交叉验证；TabFM-Ensemble 在此基础上加交叉特征与 SVD 特征，用非负最小二乘求解 32 路集成的最优权重，分类任务还额外做 Platt scaling 校准。榜单结论是 TabFM 稳定跑赢经典 ML 模型和其他表格基础模型。

  • BigQuery 侧怎么扛住规模：表格基础模型的计算和内存开销不小，BigQuery 的做法是分布式并行推理 + 训练数据智能采样——这让它可以吃下较大的训练输入行，并在数百万行推理数据上于分钟级完成预测。特征化（缺失值、类别编码等）由内置逻辑自动处理。

  • 官方自己划的边界：这是这份发布里最值得读的一段。官方明确说，以下情况该用 XGBoost 这类传统模型——历史数据集体量非常大、需要完全掌控自定义超参调优、特征数量超出 TabFM 当前上限、或者需要特征重要性可解释性（即哪些输入特征对预测贡献最大）。TabFM 适合的则是：没有 ML 专长但要快速拿到高质量预测、历史数据中小规模、数据频繁变化需要频繁重训、以及对话式或 agentic 工作流里按需做预测分析。

行业影响

树模型不会被替代，但会被分流。企业里大量预测需求——流失、购买意向、欺诈打分——之所以没做，常常不是因为没有数据，而是因为走完一遍 train-tune-deploy-retrain 的成本超过了这个需求本身的价值。TabFM 把这条链路压成一条 SQL，改变的是需求的经济性边界：以前不值得建模的问题，现在值得问一句。

对 BQML 自身的定位也有影响。它此前更像一个「在仓内训练模型」的框架，TabFM 进来之后，它多了一层「在仓内直接消费别人训练好的模型」的身份。前者要你管理模型，后者你只管理 SQL。官方把它和 BigQuery MCP server 绑在一起推荐（「给你的 agent 加上预测能力」），也说明这条路径的第一目标用户不是数据科学家，而是写 agent 的人。

需要留意的是边界。特征重要性可解释性这一条被官方列为「该用传统模型」的场景之一，意味着在强监管的信贷、医疗等需要给出理由的场合，TabFM 暂时还进不去。

AWS 把 Spark 排障代理做成托管 MCP 服务器：2 分钟从告警走到行号级反模式

事件概述

9 月 1 日，AWS Big Data Blog 发布 《Accelerate Apache Spark debugging on Amazon EMR with AWS DevOps Agent》（作者 Kalyan Janaki、Aneesh Varghese，Advanced 300 级）。做法上有个关键点：用户不需要自己搭 MCP 服务器——Apache Spark Troubleshooting Agent for Amazon EMR 本身就是 AWS 按区域端点提供的托管 MCP 服务器，只要在 AWS DevOps Agent 的 agent space 里把它注册为自定义能力提供商（custom capability provider）并授权即可。

注册之后，agent 在调查流程里会把原生 AWS API 工具和 MCP 工具交错调用：先用 use_aws cloudwatch describe-alarms 确认告警打在哪个 EMR Serverless application 上，再用 emr-serverless list-job-runs / get-job-run 捞出失败运行，最后调用 spark-troubleshooting analyze_spark_workload 做深度分析。从 CloudWatch 告警进入 ALARM 到产出带行号的根因与代码级、配置级修复建议，官方口径是约 2 分钟；CloudWatch 告警本身可以自动触发调查，无需人工介入。

技术解析

  • 补的是哪块短板：AWS DevOps Agent 原生的 AWS API 工具进不去 Spark 的内部工件。EMR 在 Serverless、on EC2、on EKS 上都通过 Spark UI 暴露了 stage 耗时、task 级指标、executor 利用率、shuffle 读写量和 GC 暂停，但读懂数据倾斜、executor 内存压力、异常耗时 stage 需要 Spark 内部知识。于是原来 agent 只能停在系统调用层面描述症状——「the executor exited with code 1」「executor exited unexpectedly」——识别不出真正导致问题的反模式。

  • 四类证据交叉定位：MCP 服务器读取并关联四类工件。一是 Spark History Server event log，存在 S3 上的按作业归档，提供 stage/task 指标与 GC 数据；二是 query plan，driver 编译出的逻辑计划与物理计划，用来识别不必要的 repartition、缺失 broadcast hint 这类会触发昂贵 shuffle 的写法；三是 S3 上的应用源代码（.py / .jar），用来定位 mapPartitions UDF 或低效 collect() 的具体行号；四是 PySpark worker 进程遥测。

  • 第四类证据是这次最有价值的部分：PySpark worker 是独立于 JVM 托管内存之外的 Python 子进程。当它因 spark.executor.pyspark.memory 耗尽而被内核杀掉时，JVM driver 只能看到一个笼统的「executor exited unexpectedly」——真正的死因对标准 JVM 级日志不可见。这类 OOM 在 PySpark 作业里相当常见，而它恰恰是纯 JVM 视角无论如何也查不出来的。

  • 演示里的根因长什么样：官方故意跑了一个会失败的 PySpark 作业（应用 analytics-events-platform，脚本 customer_events_aggregator.py，配置 spark.executor.pyspark.memory=256m、spark.executor.memory=1g）。Python worker 越过 256 MB 上限被杀，Spark 重试 4 次后 stage 标为 failed。agent 给出的根因叠加了三个问题：expand_event 函数（第 23 行）把每行输入在内存里放大 11 倍；repartition(1) 把所有数据汇聚到单个 executor 的单个分区；collect()（第 31 行）把放大后的数据集拉回 driver——而整个作业只以 1 GB executor 内存在跑。文中强调，不接这个 MCP，agent 只能停在「executor exited with a memory error」。

  • 网络路径：MCP 请求由 AWS DevOps Agent 用分配给能力提供商的 IAM 角色做 SigV4 签名，经设置期创建的托管 VPC Lattice resource gateway 进入用户 VPC，转发到 Interface VPC Endpoint，再由 PrivateLink 路由到 AWS 托管的排障代理（演示中主机为 sagemaker-unified-studio-mcp.us-east-1.api.aws，443 端口，VPC 内私有 DNS 解析）。整条链路完全留在 AWS 网络上，不经公网。服务器再用调用时 assumed 的 IAM 角色去读 S3 上的 event log 与源码、CloudWatch Logs 里的 driver/executor stdout、以及 EMR Serverless 的 job-run 元数据。

行业影响

MCP 在这个场景里的角色，和它过去一年的主流用法不太一样。此前 MCP 主要被当作「给 LLM 接上外部数据/工具」的协议；这里它被用来给运维 agent 接上被引擎藏在内部的可观测状态。被暴露的不是表和数据，而是 event log、query plan、源码和 Python worker 遥测这类只有领域专家才读得懂、但恰好是定位根因所必需的中间态。

另一个值得注意的信号是「托管」。企业自己搭一个 Spark 排障 MCP 服务器并不难，难的是让它具备跨四类证据做关联的能力，以及让安全团队批准它读取生产 S3 桶和日志。AWS 把它做成按区域端点提供的托管服务、并给出一条完整的 PrivateLink 路径，等于把「能力」和「合规路径」打包一起交付。这对于 MCP 在企业内的落地方式是个参照：不是每个能力都要自建，有些能力值得由平台方托管。

阿里云 MaxCompute：dbt 工程只读接入，语义资产转成 OSI 语义包给 AI Query 复用

事件概述

9 月 1 日，阿里云 MaxCompute 发布产品公告（页面更新时间 2026-09-01 14:05:31）：「AI 数据探索客户端」完成新一轮能力升级，新增 MaxFrame Notebook / Python UDF 开发、dbt 与 MaxCompute 生态集成、数据看板（Dashboard）、办公协作、语义包管理与应用、多模态数据集管理六项能力。

这个客户端是 MaxCompute Agentic 生态接入套件（6 月 9 日上线，含 AI 数据探索客户端、MCP Server、Skills、CatalogAPI SDK、CLI 五大组件）中的桌面端一环。本期升级里，工程上最有看点的是 dbt 集成：它把 dbt 的转换工作流接进 MaxCompute，用模型的方式管理 SQL 逻辑、依赖与血缘，并可在客户端内直接编辑、运行、查看编译结果。

技术解析

  • 只读解析 manifest.json，不调用 dbt CLI：这是这个集成最克制也最关键的设计决策。客户端直接读取本地 dbt 工程根目录下的 manifest.json（用 dbt docs generate 或 dbt compile 生成），在不调用 dbt CLI 的前提下完成模型浏览、SQL 编译预览、血缘分析与语义包导入；所有操作为只读模式，不修改 dbt 工程文件。对已经把 dbt 用得很重的团队来说，这意味着接入成本近似于零——不用改工程，也不用装适配插件。

  • SQL 编译预览做了四级 fallback，血缘下钻到列级：功能索引里列了工程管理（关联项目、多项目切换、刷新 manifest、断开关联）、模型浏览（文件树、模型健康度、只读编辑器、ref() / source() 跳转与悬浮）、编译与执行（SQL 编译预览四级 fallback + 编译结果执行到统一结果栏）、以及血缘分析（模型级血缘图，支持全屏与迷你两种形态 + 列级血缘 + 节点详情面板）。列级血缘对「改动某个模型前评估影响范围」这件事是硬需求。

  • dbt 语义资产转成 OSI 语义包：这是本期和中国之外语义层动向最直接的接榫点。文档明确，dbt 工程中已定义的 semantic models 与 metrics，可转换为 OSI 语义包（Open Semantic Interface，客户端的语义资产格式），让 AI Query 基于统一口径的实体、指标、维度做问答。官方在公告里把「语义包管理与应用」描述为：把业务口径、指标定义、表间关系沉淀为语义包供 AI 复用，使自然语言查询结果更贴合业务实际口径。换句话说，dbt 里原本只服务于 dbt 自身的那层语义定义，现在有了一个通往问数 agent 的出口。

  • MaxFrame Notebook 与静态检查：客户端内以 Notebook 方式开发 MaxFrame 分布式作业，支持逐格编写、分段运行、实时预览输出与写入表数据；运行前自动检查漏调 execute()、全表扫描等常见问题并给出修改建议，也可以通过自然语言让 AI 生成完整作业。Python UDF 则把 SQL 难以表达的逐行逻辑封装成可复用函数，在 SQL 里直接调用。

  • 多模态与协作：多模态数据集管理配合 Blob 列类型管理表中的图片、音频、视频等非结构化数据，支持上传、预览与批量处理，结构化分析与多模态处理共用一套数据底座。办公协作侧对接钉钉等工具，把查询结果、报告及看板同步分享到协作平台。

行业影响

dbt 多年积累的语义资产（semantic models、metrics）此前有个尴尬：它定义得很完整，但消费方基本只有 dbt 自己和少数支持 dbt Semantic Layer 的 BI 工具。MaxCompute 把它转成 OSI 语义包喂给 AI Query，是这条资产链的一次外延——方向上和 Databricks 的 Unity Catalog Semantics、Google 的 Knowledge Catalog 是同一件事：让「指标定义」从给人看的文档，变成给 agent 读的机器可读契约。

这条路线的务实之处在姿势上：它不要求你迁移到某个新的语义层产品，而是把你已经写好的东西读出来再用。对那些 dbt 工程已经很大、改造成本极高的团队，这种「只读接入 + 格式转换」的姿势，比推倒重来更容易被接受。

编者评

四条动态的厂商、技术层次和作用对象几乎没有交集——一个是云数仓的图引擎，一个是表格基础模型，一个是运维排障代理，一个是中国云厂商的桌面客户端。把它们并排放在一起才看得清那条共同的线：厂商在竞相把「先搬动某个工件、再获得洞察」的旧流程，改成「在工件原地声明一次」。

BigQuery Graph 不把数据抽到图库，只声明一次 PROPERTY GRAPH，跨三朵云原地遍历；TabFM 不训练也不部署模型制品，只声明一次 AI.PREDICT，预测就出来了；AWS 不要求你自建 MCP 服务器或人工翻 event log，只注册一次托管端点，行号级根因就到位；MaxCompute 不要求你把 dbt 工程改造成平台专用格式，只读一次 manifest.json，语义资产就换了消费方。四次「不」指向同一件事：能力在往下沉，工件留在原地。

这个方向的驱动力不难理解。搬动工件的成本——数据副本、模型制品、自建服务、格式改造——从来不体现在功能清单上，却实实在在决定了这些能力能不能进生产。当一层能力把自己从「需要一次迁移」变成「只需要一次声明」，它被采用的概率就不再是同一个量级。

还有一个细节值得单独拎出来说：TabFM 的官方博客花了整整一段讲「什么情况下你不该用它」——超大数据集、需要精细调参、特征数超限、要特征重要性可解释性。在一片 benchmark 曲线的发布稿里，这段自陈边界的文字比任何一条 Elo 排名都更能说明这项能力的成色。愿意把边界写清楚的产品，通常是在按工程件设计，而不是按 demo 件设计。

2026-09-02 datainfra前沿动态 Vol.55 —— 本期围绕「能力下沉，工件不动」一条主线：BigQuery Graph GA 让一张 property graph 横跨 BigQuery 原生表与 Databricks/Glue/Snowflake 的 Iceberg 表，无向遍历比预览期快 100 倍；TabFM 以 AI.PREDICT 进入 BigQuery，把回归与分类压成一次前向传播，并在 TabArena 的 38 分类 + 13 回归数据集上跑赢调参传统模型；AWS 把 Spark 排障代理做成托管 MCP 服务器，从 CloudWatch 告警到行号级根因约 2 分钟，全程 PrivateLink；MaxCompute 的 dbt 集成只读解析 manifest.json，把 semantic models 转成 OSI 语义包给 AI Query 复用。下期继续追踪 DataInfra 领域最新动态。