datainfra前沿动态 · Vol.44

Databricks Unity AI Gateway 正式 GA：统一 AI 治理控制面覆盖全模型生态与千亿级 Token；dbt Labs 提出 context engineer 新范式：数据团队从建指标到建上下文；DEW 发布主动基准测试方法论

本期聚焦 DataInfra 三条 AI 治理与工程范式动态：Databricks Unity AI Gateway 正式 GA，以 Unity Catalog 为基础构建覆盖模型、Agent、MCP、Skill 的统一 AI 治理控制面；dbt Labs 提出 context engineer 新角色，用数据仓库建模替代直接 MCP 调用，实测降低 98% Token 成本；Data Engineering Weekly 发布主动基准测试方法论，系统阐述如何让数据基础设施的性能评测从'跑完看数'升级为'边跑边解释'。三条动态从治理控制面、数据工程范式到评测方法论三个层面，勾勒出 AI 成为数据基础设施首要消费者后必须回答的三个核心问题。

DataInfra Databricks Unity Catalog AI Gateway AI Governance MCP Smart Routing Token Economics dbt Context Engineering Analytics Engineering Data Modeling Fivetran Benchmarking Performance Engineering Lakehouse Throughput Latency

本期追踪到三条 DataInfra 动态，从治理控制面、数据工程范式到评测方法论三个层面，勾勒出 AI 成为数据基础设施首要消费者后必须回答的三个核心问题。2026 年 8 月 4 日，Databricks 正式宣布 Unity AI Gateway 进入 General Availability——一个以 Unity Catalog 为治理基础、覆盖模型、Agent、MCP Server、Skill 等全 AI 资产的统一控制面，过去一年已处理超过一千万亿（quadrillion）Token，同步发布 Smart Routing Beta 实现跨模型智能路由降本。8 月 6 日，dbt Labs 的 Britton Stamper 发布长文《From analytics engineer to context engineer》，提出数据团队的角色正在从”为 BI 建指标”转向”为 AI Agent 建上下文”——并分享了 dbt 内部将 Gong 通话转录从直接 MCP 调用改为数仓建模后 Token 成本降低 98% 的真实数据。同日，Data Engineering Weekly 发布深度方法论文章《On Benchmarking》，系统阐述了从被动基准测试（跑完看数）到主动基准测试（边跑边解释）的方法论升级——涵盖 Little’s Law、Amdahl’s Law、Universal Scalability Law 三大模型在数据系统评测中的实战应用，以及 coordinated omission、metastable failure 等常见陷阱的诊断方法。三条动态分别回答了 AI-first DataInfra 的”谁在管""数据怎么准备""怎么证明它有效”三个基础问题。

Databricks Unity AI Gateway 正式 GA：一千万亿 Token 后的统一 AI 治理控制面

事件概述

2026 年 8 月 4 日，Databricks 五位作者——David Nasi、Stefania Leone、Kevin Stumpf、Kasey Uhlenhuth 和 Kelly Albano——联名宣布 Unity AI Gateway 正式进入 General Availability。这是 Databricks 在 AI 治理基础设施领域的旗舰产品，以 Unity Catalog 为治理基础，构建了覆盖模型、外部 Agent、MCP Server、Skill、Coding Assistant 等全 AI 资产的统一控制面。产品在过去一年（Preview 期间）已处理超过一千万亿（quadrillion）Token，被 Rivian、Asana、Edmunds、Zepto、STRABAG、Magnite、OnePay 等数千客户用于生产环境。同步发布的还有 Smart Routing Beta——一个跨模型智能路由能力，可根据质量、成本、性能、可用性和预算动态选择最优模型。

Databricks 将 Unity AI Gateway 定位为解决企业 AI 规模化中三个核心挑战的基础设施层产品：Cost（不可持续的 Token 支出）、Control（安全与 IP 风险）和 Choice（供应商锁定）。

技术解析

  • 从”Token 最大化”到”价值最大化”的架构哲学：Unity AI Gateway 的核心设计理念是成为所有 AI 交互的中央代理（Proxy）——任何 Agent、模型调用、MCP 请求、Skill 执行都必须经过 Gateway 的安全与策略检查。它不是一个”API 网关”（仅做路由和限流），而是一个”AI 治理控制面”（理解 AI 资产的语义、执行上下文感知的策略）。所有 AI 使用数据被集中到 Unity Catalog 中，提供开箱即用的仪表板和 Genie 驱动的自然语言分析。这使得企业可以从”每个团队自己管理 AI 支出”的碎片化状态，转变为”一个控制面看全公司 AI 支出”的集中治理模式。Databricks 自身的数千名员工已通过此平台管理跨多个 AI 工具的支出。

  • Smart Routing Beta：模型选择从”人工决策”变为”策略自动化”：Smart Routing 是本次发布中技术含量最高的新能力。它根据质量、成本、性能、可用性和预算五个维度，动态将每个请求路由到最合适的模型。核心逻辑是”好钢用在刀刃上”——将最强大（也最贵）的模型留给真正需要它们的任务，将其他工作路由到更高效的选项。这解决了企业 AI 治理中的一个经典张力：开发者希望使用最好的模型（因而倾向用最贵的），而财务团队希望控制成本（因而倾向限制模型选择）。Smart Routing 用策略引擎替代人工博弈。目前为 Beta 阶段，需联系客户团队参与。

  • 治理维度一（Cost）：端到端可观测性与硬性预算上限：Gateway 提供按模型、Provider、团队、应用的细粒度成本归因，所有数据存储在 Unity Catalog 中。企业可设置主动预算和硬性支出上限。Zepto 的技术负责人 Sriram Ravichandran 透露其月均处理超过 1000 亿 Token，Gateway “零可用性问题”。STRABAG 的 Max Lautner 强调 Gateway 使其能”跨数据产品和编码 Agent 集中治理 LLM”，提供”单一治理访问层”。

  • 治理维度二（Control）：数据与 AI 统一治理：Databricks 的核心论点——“数据与 AI 必须一起治理”——是 Unity AI Gateway 区别于纯 API 网关的根本差异。Agent 的交互轨迹中混杂着机密信息、PII 数据和密钥，传统的”安全团队管数据 + AI 团队管模型”分离模式无法应对。Unity Catalog 提供身份、权限、血缘和审计，Unity AI Gateway 在运行时执行 guardrails 和上下文感知的策略。Rivian 的 Saravanan Lakshmanan 将此描述为”守一个门，而不是十几个门”——将分散的 AI 治理收敛到单一控制面。OnePay（金融数据场景）的用例进一步验证了这一模式在合规敏感行业的价值。

  • 治理维度三（Choice）：开放、多 AI 的治理框架：Gateway 同时提供对 Anthropic、OpenAI、Gemini、Kimi、GLM 等多个前沿模型的原生访问，通过单一查询 API 即可切换模型。Databricks 强调这实现了”开放性”与”治理性”的平衡——企业可以自由采用最新模型和工具，同时保持一致的权限、策略和可观测性。Edmunds 的 Greg Rokita 指出这使其能”标准化 Coding Agent，安全共享治理过的 Skill”，为规模化 AI 采用提供基础。

行业影响

Unity AI Gateway GA 是 AI 治理基础设施领域的一个重要里程碑。它标志着 AI 治理正在从”安全团队的事后审计”转变为”基础设施层面的运行时控制”。从 DataInfra 的视角看，这本质上是一个数据治理体系向 AI 交互层的纵向延伸——Unity Catalog 原本管理的是表、视图、模型注册，现在扩展到了 Agent 调用、MCP 请求、Token 消费等 AI 运行时行为。

将这一事件放在我们持续追踪的”Agent-First DataInfra”叙事中看（Vol.37-43），一个清晰的层次结构正在浮现：底层是数据存储与计算（Iceberg/Spark/Redshift），中层是数据治理与目录（Unity Catalog/Polaris/Glue），上层是 AI 交互治理（Unity AI Gateway）。Databricks 在走”全栈治理”路线——用自己的 Catalog 治理数据，用自己的 Gateway 治理 AI 访问——而 AWS 在走”平台嵌入式”路线——将 Agent 治理能力嵌入到 EMR/MSK/Redshift 等具体服务中。这两条路线的竞争将深刻影响 2026-2027 年的企业 DataInfra 架构选型。

值得注意的是，Matei Zaharia（Databricks CTO）和 Kasey Uhlenhuth 将于 8 月 13 日举办 AI 治理网络研讨会——这可能是 Unity AI Gateway 路线图的进一步披露窗口。

相关链接

dbt Labs 提出 context engineer：当数据团队的用户从人类变成 AI Agent

事件概述

2026 年 8 月 6 日，dbt Labs 的 Britton Stamper 发布了《From analytics engineer to context engineer》，提出了数据工程领域的一个新角色定义：context engineer（上下文工程师）。文章的核心论点是：当 AI Agent 成为数据的主要消费者时，传统 analytics engineer（为 BI 仪表板建模）的技能集需要升级——从”为人类建指标”扩展到”为 Agent 建上下文”，且不需要更换技术栈。

Stamper 分享了 dbt Labs 内部的真实案例：销售团队使用 Claude 直接通过 Gong 的 MCP 分析通话录音，单次对话消耗高达 50,000 Token（约 $0.25），500M+ Token 的通话转录数据池使整体 AI 支出”显著增长”。数据团队将 Gong 原始数据摄入 Snowflake 数仓、用 dbt 建模为通话摘要后，Token 消耗降低了约 98%——一次 60 分钟通话的分析从数万 Token 降至数百 Token——同时保持甚至提升了上下文质量。

技术解析

  • context engineering 的四个核心操作：Stamper 将 context engineering 抽象为四个可复用的操作模式——Compress（将大规模语料压缩为仅含相关内容的最小形态）、Enrich（将数据与其他相关信息关联以降低访问成本）、Describe（提供数据的含义和适用性元信息）、Govern（精确控制每个 Agent 的可见数据范围）。这四步与传统 analytics engineering 的”Extract-Transform-Model-Serve”管线完全兼容，区别在于输出从”给人看的仪表板”变为”给 Agent 读的上下文”。Stamper 强调这”不需要实质性改变数据栈”——Fivetran 负责数据摄入，dbt 负责建模转换，只是现在建模的目标对象变成了 Agent。

  • Read Once, Write Many 经济模型：context engineering 最核心的经济原理是”用批处理做一次昂贵读取，然后服务所有 Agent 无数次”。直接 MCP 模式下，每个 Agent 每次查询都要消耗 Token 重复读取原始数据——100 个销售每天分析 10 个通话 = 1,000 次 API 调用 + Token 消耗。将数据建模后存入数仓，一次批处理建模完成，所有 Agent 通过统一的 context connector 读取——边际成本趋近于零。Stamper 将此称为”用已有的数据基础设施解决 AI 的成本问题”。

  • 非结构化数据的数仓化：文章提出了一个数据团队的认知升级——历史上数据团队回避非结构化数据（通话转录、PDF、工单、邮件），因为传统 BI 工具无法处理。但 AI Agent 的出现改变了这个等式：非结构化数据恰好是 Agent 最有价值的上下文来源（通话转录揭示客户意图、工单记录产品问题、PDF 合同记载商业条款）。dbt Labs 的实践表明，利用 Snowflake Cortex 的 AI_EMBED/AI_COMPLETE/AI_PARSE_DOCUMENT 等 SQL 函数，可以在 dbt 模型中直接处理非结构化数据——将 PDF 解析为结构化文本、对通话转录做摘要和分类——所有操作在数仓内完成，与传统的结构化数据建模共享同一套治理和血缘体系。

  • 增量上下文维护：Stamper 特别指出，Agent 需要”当前、正确”的信息来做决策——上下文不能只是一次性快照。增量模型（incremental models）持续捕捉状态变化，确保上下文层的时效性与源数据同步。这与传统数据仓库的”T+1 批处理”模式不同——context engineering 要求近实时或至少高频更新的上下文刷新，因为 Agent 的决策质量直接取决于上下文的时效性。

  • 分析工程到上下文工程的迁移对照：文章给出了一个清晰的对比表——Analytics Engineering 的消费者是”查看仪表板和运行查询的个人用户”，Context Engineering 的消费者是”整个组织使用的 AI Agent（如 Claude、Codex）“；前者处理定量结构化数据，后者处理定量+定性+半结构化数据的混合体；前者的目的是”理解发生了什么”，后者的目的是”为 Agent 提供准确响应和可信行动的上下文”。

行业影响

dbt Labs 这篇文章的发布时机意味深长——它出现在 Fivetran 与 dbt 合并完成后，且正值 Databricks Unity AI Gateway GA 的同一周。三者之间构成了一个从治理控制面、数据工程范式到数据摄入管线的完整叙事弧：Fivetran 负责将数据从各种 SaaS 工具（Gong、Salesforce、Zendesk）摄入数仓，dbt 负责将原始数据建模为 Agent 可用的上下文，Unity AI Gateway 负责治理 Agent 对这些上下文的访问。这是”Open Data Infrastructure for AI”从概念走向产品组合的实质性进展。

从 DataInfra 从业者的视角看，context engineer 的提出解决了一个长期存在的问题：当 AI Agent 成为数据仓库的首要消费者时，数据团队的角色是什么？传统的回答是”继续建数仓和 BI 仪表板，Agent 自己会查询”。但 dbt 的实践表明，让 Agent 直接查询未经优化的原始数据会产生巨大的 Token 浪费和治理风险——数据团队需要主动为 Agent 设计上下文层。这在工程上意味着数据建模的”消费者画像”需要扩展——过去只需要考虑”分析师会怎么查这张表”，现在还需要考虑”Agent 查这张表时需要什么粒度的上下文、多少 Token、哪些治理约束”。

Stamper 预告这将成为一个博客系列，后续会分享端到端技术演练、跨 Agent 共享上下文的架构模式等更多实践内容。对于正在规划 Agent-First DataInfra 的团队来说，这是一个值得持续追踪的技术方向。

相关链接

DEW 发布主动基准测试方法论：为什么 50,000 ops/sec 不能决定架构选型

事件概述

2026 年 8 月 6 日，Data Engineering Weekly 作者 Ananth Packkildurai 发布了深度方法论文章《On Benchmarking: Why a throughput number is not an architecture decision》。文章系统阐述了数据基础设施评测从被动基准测试（passive benchmarking——跑完测试，只看最终数字）到主动基准测试（active benchmarking——边跑边观察系统行为，解释瓶颈成因）的方法论升级，借鉴了 Brendan Gregg 的 Active Benchmarking 框架。

Packkildurai 的核心论点是：数据工程团队在选择引擎、表格式、集群规模时最常见的错误，就是把一次压测的吞吐量数字当作架构决策依据——而忘记了追问：数据是否已在缓存中？客户端在系统变慢时是否维持了预期的请求速率？重试、提交冲突、错误是否被计入？测试用的是真实数据布局还是方便的合成数据？

技术解析

  • 基准测试契约（Benchmark Contract）：文章提出在启动任何基准测试之前，必须先写一份简短的”契约”，明确六个核心问题——决策目标（这个测试将影响什么选择）、工作负载定义（读写比例、请求大小、分区分布、数据集规模、并发模式）、系统边界（客户端、网络、Catalog、对象存储、元数据服务、计算层）、到达模型（请求是按固定频率发出还是客户端等待响应后才发下一个）、系统状态（冷缓存/热缓存/Compaction 高峰期/稳态流）、输出指标（吞吐量、错误率、成本、延迟百分位——不能只看其中一个）。没有这份契约，吞吐量曲线图”只是截图，不是决策文档”。

  • Coordinated Omission：最危险的延迟陷阱：文章指出闭循环客户端（closed-loop client）天然存在 coordinated omission 问题——当服务端因锁、GC 或元数据服务过载而暂停时，客户端工人因为等待响应而减少请求发出量，导致测试未能记录”如果请求以预期速率到达，排队延迟会有多长”。这使得系统在无法跟上预期负载时，反而看起来”更稳定”——因为在暂停期间请求根本没发出去。修复方法是：使用能独立于已完成响应调度预期负载的负载生成器，或使用专门设计来修正 coordinated omission 的测量方法，并同时报告 offered load 和 completed throughput。

  • “The Tail at Scale”在数据系统中的实战应用：文章引用了 Jeffrey Dean 的经典论文，将其映射到数据基础设施场景——如果一次查询依赖 100 个独立的后端操作，每个操作有 1% 概率变慢，则至少有一个变慢的概率是 63%（1 − 0.99¹⁰⁰）。Packkildurai 特别指出”独立性假设在真实系统中往往不成立，关联故障会更糟”，因此必须报告 p50、p95、p99 延迟百分位（仅在样本量足够时报告 p99.9），且始终将超时和重试与延迟并列展示。

  • 三个性能模型作为诊断工具（而非判决书）：文章详细阐述了 Little’s Law（L = λW —— 暴露与吞吐量和延迟不一致的 in-flight 请求量）、Amdahl’s Law（S(N) = 1/[(1−P)+(P/N)] —— 使串行工作可见，在数据系统中串行部分可能是 Catalog 访问、提交路径、协调屏障或单个倾斜分区）、Universal Scalability Law（C(N) = N/[1+α(N−1)+βN(N−1)] —— 将扩展曲线转化为关于竞争与协调开销的问题）。Packkildurai 强调这些模型的价值不是”证明系统正确”，而是”暴露假设”——当观测数据与模型预测不一致时，就是深入调查的信号。

  • 生产态场景下的 Metastable Failure 测试：文章特别推荐了一类容易被忽视的测试场景——metastable failure（引用 Bronson et al. 的 HotOS 2021 论文）。在生产环境中，一次短暂减速会触发重试→队列增长→超时→更多负载→系统在原始触发消失后仍然不健康的恶性循环。数据平台在缓存预热、Checkpoint 累积、Compaction 启动、分区倾斜或写冲突上升时的行为变化，往往比稳态性能更能决定运维体验。文章建议基准测试必须包括冷/热缓存对比、长时运行（覆盖 Compaction/Checkpoint 周期）、键/分区倾斜变化、乐观并发控制下的冲突写入、负载阶梯变化与恢复测试、以及依赖服务减速注入。

行业影响

这篇文章的发布时机与本周 Databricks Unity AI Gateway GA 和 dbt Labs context engineer 形成了意味深长的呼应——当行业在快速推出新的数据基础设施产品（AI Gateway、上下文引擎、Agent 驱动运维）时，如何客观评价这些产品的实际性能成为一个被严重低估的问题。Packkildurai 的方法论为 DataInfra 从业者提供了一个结构化的评测框架，从”看 Benchmark 数字选产品”升级为”用 Benchmark 理解系统行为”。

对于正在评估 DataInfra 技术选型的团队而言，本文提出的基准测试契约（Benchmark Contract）可以作为一个实用的团队规范——在下次压测之前，强制团队先回答六个核心问题，避免”10,000 QPS 所以选它”的决策捷径。对于 DataInfra 产品的技术营销而言（无论是开源项目还是商业产品），本文也是一面镜子：当你的 Benchmark 报告缺少了冷/热状态说明、coordinated omission 修正、错误率和重试数据时，它在方法论上是不可靠的。

相关链接

编者评

本期三条动态看似分属不同领域——AI 治理控制面（Databricks）、数据工程范式（dbt）和性能评测方法论（DEW）——但底层共享一个正在加速成形的结构性命题：当 AI Agent 成为数据基础设施的首要消费者时，数据基础设施需要回答三个新问题：谁在管（Governance）、数据怎么准备（Context Engineering）、怎么证明它有效（Benchmarking）。 Unity AI Gateway 回答了”谁在管”——用一个统一控制面治理所有 AI 资产对数据的访问；dbt context engineer 回答了”数据怎么准备”——从为人类分析师建模升级为为 AI Agent 建模；DEW 基准测试方法论回答了”怎么证明它有效”——从被动看吞吐量数字升级为主动解释系统瓶颈。回顾从 Vol.37 至今的八期专栏（Agent-First DataInfra 叙事线），我们见证了数据基础设施的焦点从”Agent 如何帮助人类运维 DataInfra”（Spark/MSK Agent、YugabyteDB AMP）逐步扩展到”数据基础设施如何更好地服务 Agent 作为消费者”——本期的三条动态是这个扩展的最新锚点。DuckDB 在 8 月 5 日获得了第 40,000 个 GitHub Star——这个看似独立的小里程碑，其实也是同一趋势的注脚：当数据处理引擎的用户群从”数据工程师”扩展到”数据工程师 + AI Agent + 被 Agent 服务的业务用户”时，基础设施的治理面、建模面和评测面都需要系统性升级。