datainfra前沿动态 · Vol.106

Databricks 把本地库与 Marketplace 数据放进同一次 SQL join，中间不落任何对象；AWS 给 OpenSearch Serverless 时序集合装上热温分层、自定义时间字段与独立保留策略；Databricks 把 ai_extract 的 prompt 与 schema 收进 MLflow Prompt Registry，改配置不再动管道代码；Google 用 ADK 加 MCP 让 Gemini Enterprise 的查询留在 Snowflake 治理边界内执行

本期聚焦 10 月 27 日四条大厂侧进展，动作落在同一个词上：边界。数据不越过存储边界、容量不为峰值越界预留、查询不越过治理边界、配置变更不越过版本边界。

DataInfra Lakehouse Federation Unity Catalog Amazon OpenSearch Serverless 时序数据 数据分层 MLflow Prompt Registry ai_extract Gemini Enterprise Snowflake MCP 数据治理

本期四条动态全部落在 10 月 27 日，三条来自 Databricks、AWS 与 Google Cloud 的官方博客，一条来自 Databricks 的工程实践博客，动作指向同一个词：边界。Databricks 用 Lakehouse Federation 把本地 SQL Server 里的持仓数据与 Marketplace 上的 FactSet 数据摆进同一个 Unity Catalog，一条 SQL 直接 join，中间不建管道、不建物化视图、不落任何持久化对象，每次刷新都重新联邦一次；AWS 给 OpenSearch Serverless 的下一代时序集合装上三个显式开关——index.warm.after 控制热转温、index.timestamp_field 决定哪个字段排序、index.data.retention 把生命周期的责任从独立策略挪回索引本身，容量这边则靠秒级伸缩与十分钟后缩到零，取代了按峰值预留的老做法；Databricks 的另一篇文章把 ai_extract 的 prompt 与 schema 从 notebook 硬编码挪进 MLflow Prompt Registry，改动走别名晋升或回滚，并用冻结测试集、噪声底线与覆盖度三项指标决定一个候选能不能上生产；Google Cloud 用 ADK 加 MCP 把 Gemini Enterprise 接到 Snowflake，文本的转 SQL 与 SQL 的执行都交给 Snowflake 内的 Cortex Agent，用调用者的 OAuth 身份在治理边界内完成。四处的代价也各自留在明面上：联邦查询每次实时回源，热温分层换来的是温层查询延迟上升，评估体系要求先跑三到五次才谈得上改进，Snowflake 侧的 OAuth 令牌会在授权那一刻把默认角色与仓库锁死。

Databricks Lakehouse Federation：本地库与 Marketplace 数据同处一次 join，中间不落对象

事件概述

10 月 27 日，Databricks 在平台博客发布《Unlocking Investment Insights Without Migrating Your Data: Lakehouse Federation》，作者为 Meghana Padmanabhan、Isaac Gritz 与 Max Nienu。文章用一个财富管理机构的持仓分析场景，把 Lakehouse Federation 的用法从头走了一遍。

场景设定是这样的：第一方数据（持仓、股数）存放在企业防火墙内的本地 SQL Server 里，第三方数据（FactSet 的盈利基本面与分析师预测）在 Databricks Marketplace 上。传统做法要在三种都不舒服的选项里挑一个——把敏感数据复制到云上、搭一套脆弱的 ETL 管道、或者干脆放弃整合两者。文章给出的路径是第三种之外的第四条：联邦本地源，订阅云端第三方数据，直接出仪表盘和自然语言问答，中间没有管道，没有物化视图，没有持久化对象。

Lakehouse Federation 本身支持对 SQL Server、PostgreSQL、MySQL、Snowflake 等外部库建立联邦连接，用标准 SQL 直接查询，数据留在原地。加上一个 Marketplace 数据共享之后，两个 catalog 在 Unity Catalog 里并列，一条普通 SQL 就能像 join 两张本地表那样把它们连起来。

技术解析

  • 三步把两个 catalog 摆到一起：第一步在 Catalog → External Data → Connections 建到本地库的连接，连接对象负责保管凭据；第二步基于连接创建 foreign catalog，把外部库映射成 Unity Catalog 的原生对象，此后每次查询都实时打到源库上执行；第三步在 Marketplace 搜索 FactSet、申请并订阅，数据以共享 catalog 的形式出现在工作区，按 schema 分成三部分——fe_v4 是 FactSet Estimates（分析师一致预期 EPS、盈利预测、预测家数）、ff_v3 是 FactSet Fundamentals（营收、净利润、利润率、负债水平等年度财报项）、sym_v1 是 Symbology（ticker 到 FactSet 内部实体的映射，用来把自建持仓符号对上 FactSet 的标识）。
  • 查询与消费都不落中间层：两侧的 catalog 建好之后，一条 SQL 横跨联邦持仓表与 Marketplace 表。仪表盘的每个 widget 把这条查询内联进自己的数据集，不创建视图、不持久化表，每次刷新重新联邦一次源库。Genie agent 直接接到同一组联邦表与 Marketplace 表上，指令里带上 join 链与数据质量过滤条件，把自然语言翻译成仪表盘跑的那类查询。
  • 这条路的代价写在明处：每个 widget 每次刷新都要重新回源，意味着查询延迟与源库负载由源端承担，文章没有给出缓存或物化的替代方案；联邦查询能下推多少计算取决于源的 SQL 能力，跨源 join 的规模也受限于源库能承受的并发。文章把适用范围推广到了医疗（HIPAA 病历 join 药物相互作用库）、制造（本地 IoT 遥测 join 云端供应链数据）与零售（门店 POS join 第三方人口统计），共性都是敏感第一方数据不出本地。

行业影响

联邦查询不是新概念，Presto、Trino 与各类 JDBC 连接器已经做了很多年。这次的变化在于它长在了一个带治理的目录里：foreign catalog 与 Marketplace 共享 catalog 在 Unity Catalog 里是同一类对象，权限、血缘、审计都走同一套机制，联邦连接不再是绕过治理的一条旁路。

对数据平台的架构选择来说，这给出了一个与「先入湖再分析」并列的选项——当数据的敏感等级或合规要求不允许复制时，代价从「搬一次」变成「每次查都回源一次」。前者适合高频、可缓存的分析负载，后者适合低频、强合规、源端能扛住的场景。Cloud 厂商把这条路径做成产品化能力之后，「数据必须先集中」这一默认假设正在被拆掉。

相关链接

AWS：OpenSearch Serverless 下一代时序集合，把分层、时间字段与保留拆成三个独立开关

事件概述

10 月 27 日，AWS Big Data Blog 发布《Introducing the next generation of serverless time series for Amazon OpenSearch Service》，作者 Kevin Fallis。文章先交代下一代 serverless 集合的架构改造，再讲时序集合在这套基础上新增的三个控制项。

架构改造的部分给出六条：计算按需求在秒级内加入，比上一代架构快至多 20 倍；使用默认的最小 OCU 为 0 时，集合在 10 分钟无活动后计算缩到零；最小与最大计算量可分别设置，摄入密集的负载可以把最小摄入 OCU 与搜索需求分开调；计算与存储彻底分离，无状态 OCU 读写共享存储层；数据在摄入那一刻就持久化到 S3，前面由一层快速存储承接；借助 collection groups，多个集合共享计算而各自指定不同的 KMS 密钥，兼顾成本效率与按集合隔离的加密。

在这套基础之上，时序集合新增的是三个写在索引上的设置项，文章逐一给了配置示例。

技术解析

  • 热温分层：index.warm.after：一个索引设置决定索引数据在何时转入低频访问层。示例是 PUT /app-logs { "settings": { "index.warm.after": "7d" } }。摄入时数据在快速层留一份热副本，并持久化到 S3；索引满 7 天后热副本转入温层。查询时如果时间跨度落到温层，那部分数据在同一份响应里一起返回，只是延迟更高——温层数据由 S3 支撑，查询直接与对象存储上的数据交互。文章明确一点：任一时刻只为其中一层付费，两层不叠加计费。
  • 时间字段：index.timestamp_field：classic 集合里时序事件自动带 @timestamp 字段管理顺序；下一代时序集合允许覆盖默认字段，写法是 PUT /app-logs { "settings": { "index.timestamp_field": "event_time" } }，既可以在索引创建时作为索引设置指定，也可以写进索引模板。要求是文档在摄入前必须填好该字段，缺失、为 null 或日期值非法的文档会被逐条拒收；_bulk 请求整体仍然成功，不合规的文档在响应的 errors 块里标出来。
  • 保留策略：index.data.retention：与上一代把生命周期策略挂在集合之外的做法不同，下一代把这份责任挪到了索引上。示例用索引模板让所有匹配 app-logs* 的索引吃同一份策略：PUT /_index_template/app-logs { "index_patterns": ["app-logs*"], "template": { "settings": { "index.data.retention": "30" } } }。热温分层管的是响应速度与成本，保留管的是数据什么时候被删，两者解耦。文章举的对照是合规场景：过去为了压住存储成本，长期数据往往落到快照或不可变存储里，审计时再临时拉起一个取证集群；现在加搜索 OCU 就能直接查长期数据。
  • 配套的可观测性入口：文章把这套能力对接到 2024 年 11 月发布的下一代 OpenSearch UI，Observability workspace 提供告警、异常检测、可视化与 PPL（piped processing language），可以直接操作多种时序实现，配合从预置型向 serverless 迁移的过渡期。

行业影响

时序与日志负载的成本结构一直是运维侧的痛点：容量按峰值规划，冷数据要么删要么付热价。AWS 这次的改动把三个原本耦合在一起的决定——数据放在哪一层、按哪个字段排序、保留多久——拆成三个独立的、可写在索引模板里的声明，并把「为峰值预留」换成「在声明的上限内弹性伸缩」。

值得注意的还有边界的重新划分：保留策略从集合外的独立策略挪到索引上，意味着策略跟着索引模板走，可以按数据类别粒度化管理，代价是策略的可见点变多。把时间字段的决定权交给用户并给出逐条拒收的明确语义，是把一类静默的数据质量问题（时间戳缺失或非法导致顺序错乱）改成了摄入期就能看见的显式错误。

相关链接

Databricks：把 ai_extract 的 prompt 与 schema 挪进 MLflow Prompt Registry，用评估决定晋升

事件概述

10 月 27 日，Databricks 工程博客发布《From spot fixes to measured gains: improving document extraction accuracy with ai_extract and MLflow Prompt Registry》，作者 Kristen Drexinger 与 Seshendranath Balla。

文章从一个具体的失败讲起。项目要从合作伙伴提交的订单 PDF 里抽取约 40 个结构化字段，覆盖数十种版式，人工复核者先修正再放行，这就留下了人工确认过的 ground truth。问题不在于让 ai_extract 返回这些字段，而在于改进整体而不引入退化：一次针对 revision 字段的小改把该字段的错误砍掉约一半，但把所有字段加总，抽取错误总数反而上升了 9%。

文章据此把「看到错就改、改完重跑一遍看看」的循环，换成一套有版本、有固定测试集、有判定标准的流程。配套的是 Genie Code for document processing，它负责建 Lakeflow 作业（ai_parse_document、ai_classify、带引用与置信度的 ai_extract）并自动跑评估与爬坡循环：先按标注表逐字段打分，再把修改建议以可审阅的 diff 形式提出来，接受后重跑评估并给出前后对比。

技术解析

  • 先选对杠杆，再谈改：ai_extract 接三个输入——解析后的文档、JSON schema、可选的 global instructions。字段级规则放 schema（取值集合用 enum 约束而不是在描述里列一遍，数字用数值类型，重复结构用嵌套数组或对象）；跨文档的规则放 global prompt（来源优先级如页眉优于页脚、跨字段一致性、哪些区域禁用）。判定原则是「规则定义一个字段就放 schema，规则定义如何解读整份文档就放 prompt」。ai_extract 2.1 的 precision mode 面向另一类问题：schema 大、行项重复、表格复杂、跨页布局导致值与行对不上时，在 prompt 与 schema 不变的前提下开启，文章说它对重复结构帮助最大，并能减少「本该为空却返回值」的过度抽取。确定性变换（大小写、分隔符、补零、TELEVISION 到 TV 这类映射）交给 SQL 或代码，不交给模型。
  • 引用与置信度用于归因而不是兜底：citations 给出字段级包围盒，可映射回源文档的 element span，用来区分两类错误——抽取错误（选错区域、误解字段、返回源里没有的值）与标注分歧（抽取位置正确但复核者遵循另一套约定），前者改 schema 或 prompt，后者改复核指南。置信度当作排序信号用（先审低置信度字段），不当自动质量闸门用，高置信度结果照样会错。
  • prompt 与 schema 一起版本化：两者都进 MLflow Prompt Registry，别名策略用 @prod（当前批准版本）、@candidate（评估中）、@scr_*（并行对比的实验版本）。管道按别名加载，候选批准后用 mlflow.genai.set_prompt_alias 把 @prod 移到新版本，下一次运行即生效，无需改管道代码；回滚把两个别名恢复到此前的版本，底层版本仍留在注册表里。文章强调只版本化 prompt 是不够的——field description 对抽取的影响不亚于全局指令，只管一半等于另一半继续以未追踪的代码改动形式流动。
  • 评估要有噪声底线、覆盖度与判定：从人工复核通过的结果里冻结一份固定测试集（文中是数百份覆盖多种版式的 PDF），生产配置在冻结集上至少跑 3–5 次，算出均值与标准差 σ 作为噪声底线，策略可以要求候选的改进超过 2σ 才算有意义，落在这个区间内属不可判定。覆盖度必须与准确率一起报：只在「模型与复核者都给了值」的字段上算准确率，会让一个把难题留空的候选显得更准。文中给的反例是 revision 字段——只统计复核者给了值的文档时，那次修改看起来只提升不到 3 个百分点；把「正确答案本应为空」的情况也计入错误后，才是错误数砍半。评估最终归为五种判定：BETTER（准确率过阈值、覆盖度保持、结果稳定）、SUSPECT（准确率升但覆盖度明显降）、UNSTABLE（多次运行波动过大）、INCONCLUSIVE（差异小到无法与正常波动区分）、WORSE（准确率明显下降）。

行业影响

把 LLM 抽取从提示词手艺变成可回归的工程流程，是这条产品线近几期的连续动作。这次的关键不在于又多了一个评估工具，而在于把「改了一处」与「系统变好了」这两件事在度量上分开：噪声底线处理的是 LLM 本身的运行间波动，覆盖度处理的是分母被悄悄缩小，版本化与别名处理的是配置与代码的耦合。三者缺一个，团队看到的「提升」都只是度量假象。

对数据工程团队的直接影响是职责边界的移动：prompt 与 schema 从 notebook 里的字符串变成注册表里的版本化资产之后，晋升与回滚不再需要一次代码部署，抽取配置的变更也就不再必然走一遍研发流程。这套做法的前提是存在人工复核产生的 ground truth——没有这份标注，评估循环无从启动。

相关链接

Google Cloud：用 ADK 与 MCP 把 Gemini Enterprise 接到 Snowflake，查询在治理边界内执行

事件概述

10 月 27 日，Google Cloud 数据 analytics 博客发布《Securely connecting Gemini Enterprise to Snowflake data》，作者 Pankaj Bajpai 与 Abhilash Adavi。文章给出一条用 Model Context Protocol（MCP）与 Google Agent Development Kit（ADK）打通 Gemini Enterprise 与 Snowflake 的路径。

文章先区分了两种集成模式：标准的直连方案适用于企业基础场景，由 Google 与 Snowflake 的联合方案提供；ADK 架构属于高级的自定义编排模式，面向在 Google Cloud 上构建复杂多智能体系统的开发者，例如把 Snowflake 洞察与外部企业工具组合、自定义推理循环、或在 Gemini Agent Engine 里做跨平台状态管理。

核心思路是：业务用户问「上季度德州卖得最好的五件商品是什么」，agent 不把原始 SQL 执行暴露给客户端，而是把查询生成与执行都委托给 Snowflake 里受治理的 Cortex Agent——ADK agent 把自然语言问题交给 Snowflake MCP server，后者调用由 Cortex Analyst 语义视图支撑的 Cortex Agent（CORTEX_AGENT_RUN），Cortex Agent 把问题翻译成 SQL 并在 Snowflake 内部用调用者的 OAuth 会话与角色权限执行，再把结构化结果返回给 ADK agent。

技术解析

  • 第一步：OAuth 安全集成：用 OAuth 2.0 做用户身份模拟，避免在模型侧开一个权限过宽的服务账号。在 Snowflake 里建机密客户端类型的 security integration，OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'，OAUTH_REDIRECT_URI 指向 Google Cloud 官方的握手接收地址 https://vertexaisearch.cloud.google.com/oauth-redirect，OAUTH_REFRESH_TOKEN_VALIDITY = 7776000 秒（90 天，文章注明这是 Snowflake 允许的上限）。凭据通过 SYSTEM$SHOW_OAUTH_CLIENT_SECRETS 取出后配到 Google Cloud 侧。
  • 第二步：最小权限角色：为 agent 建专用角色并授予库、schema、warehouse 的 USAGE，语义视图的 SELECT 与 REFERENCES，以及 schema 内所有表的 SELECT。文章特别提示：用户上下文必须对语义视图底层的物理表有 SELECT 权限，只授予语义视图会在执行期报错；如果安全策略不允许直接放开基表，可以在物理表之上放一层 Snowflake Secure View 再建语义视图——因为视图以 Owner’s Rights 执行，此时 agent 角色只需要对 Secure View 与语义视图的 SELECT。另一处陷阱是 Snowflake OAuth 令牌在授权那一刻会绑定用户的 DEFAULT_ROLE 与 DEFAULT_WAREHOUSE，若用户先授权再改默认值，会话会锁在授权时那个角色上并因权限不足而执行失败，正确顺序是先改默认值、再授权、授权后可改回。
  • 第三步：Cortex Agent 与 MCP server：在 Snowflake 里用语义视图创建受治理的 Cortex Agent，再配置一个 MCP server 以 CORTEX_AGENT_RUN 工具类型把它暴露出去。这样 SQL 生成与执行都留在 Snowflake 内，并强制使用调用者的 OAuth 身份。

行业影响

这条路径的价值不在「又一个 MCP 集成」，而在信任边界的划法：把 SQL 的生成交给有语义视图约束的 Cortex Analyst、把执行留在 Snowflake 内并用调用者自己的角色，等于把「模型写出未经验证的 SQL」和「agent 拿到超出用户的权限」两类风险一并关在数据源一侧。相比把整个 schema 塞进模型上下文再让外部引擎执行，这种做法把语义定义和执行权限都留在了拥有它们的地方。

文章给出的那些具体约束也值得留意——语义视图必须连带底层表的权限、OAuth 令牌在授权瞬间绑定默认角色与仓库——这类细节正是集成上线时最容易卡住的地方。随着 Agent 与企业数据仓库的对接成为常态，这类「谁的身份在执行、在哪一侧执行」的问题正在取代早期的「能不能连上」，成为集成方案的主要分歧点。

相关链接

编者评

本期四条动态分属联邦查询、时序存储、抽取工程与 Agent 集成四个相距很远的领域，形状却高度一致：都在给某件原本默认「越界」的事划一条边界，并把越界的代价留在原地。Lakehouse Federation 划的是数据边界——敏感数据不越过本地，代价以「每次刷新重新回源」的形式付在查询侧；OpenSearch 时序集合划的是容量与生命周期边界——不再为峰值预留，代价以温层查询延迟的形式付在访问侧；MLflow Prompt Registry 划的是变更边界——改配置不越过代码部署，代价以「先跑 3–5 次建立噪声底线」的形式付在评估侧；ADK 加 MCP 划的是治理边界——SQL 不越过 Snowflake 执行，代价以 OAuth 绑定与角色配置的复杂度付在集成侧。四条都选择了把代价留在明处而不是藏起来，这本身是一个信号：DataInfra 的产品竞争正在从「能不能做到」转向「代价写在谁的账单上、由谁承担」。

另一条暗线是「中间层」的持续削减。继前几期 Databricks AI Search 删掉中间那份 Delta 副本之后，本期 Lakehouse Federation 删掉的是管道与物化视图，Agent 集成删掉的是「先把 schema 搬进模型上下文」这一步。值得注意的是，联邦与 Agent 两条路径都依赖一个共同的底座——目录与语义层：foreign catalog 与 Marketplace 共享 catalog 只有在同一个 Unity Catalog 里才长得像两张普通表，Cortex Agent 的确定性也来自 Snowflake 里的语义视图。目录与语义层正在从「元数据管理组件」变成跨系统访问的接入点。

本期中文源（阿里云开发者社区与博客、火山引擎文档站与开发者社区）在 10 月 27 日至 28 日没有可确认日期的新条目；开源侧同样平静——Apache Iceberg 仍为 1.12.0（09-30）、Trino 484、Delta Lake 4.4.1、DuckDB v2.0.0、Ray 2.58.1、Daft 0.7.26，Spark 在 10 月 27 日打出 v4.3.0-rc3 但仍未见 GA 公告，LanceDB 更新至 v0.41.0-beta.15（10-27），其余多为 nightly 与 hotfix。