datainfra前沿动态 · Vol.95

Databricks 把多语句事务做成 GA，跨 Delta 与 Iceberg 的原子保证不再需要另开一套仓；AlloyDB 用 RRF 把向量与 BM25 两路召回合成一次 SQL 调用；Looker 让 Agent 与数据应用继承语义层并纳入 Git 与 CI/CD；Stripe Data Pipeline 把实时交易数据直接写进 Lakebase Postgres

本期聚焦四条把「必须在两个系统之间做取舍」的地方收敛成单一入口的动作：事务保证不再需要单独的仓，两路召回的融合不再需要应用侧归一化，Agent 的指令不再躺在 UI 配置里，Stripe 数据不再需要在 API/Webhook 与分析表之间二选一。

DataInfra Databricks Delta Lake Apache Iceberg 多语句事务 Unity Catalog Google Cloud AlloyDB 混合检索 RRF Looker LookML CI/CD Stripe Lakebase

本期四条动态集中在 10 月 15 日至 16 日，来自两家平台厂商与一条生态集成，形状高度一致：过去必须在两个系统之间取舍的事情，现在有了单一入口。Databricks 把多语句事务做成正式可用，跨 Delta Lake 与 Iceberg 两张开放表格式给出跨表原子保证；AlloyDB 用 Reciprocal Rank Fusion 把向量召回与 BM25 召回的融合收进一个 SQL 函数，应用侧不再需要写归一化与重排；Looker 一边让 Agent 生成的交互式数据应用原生托管并继承语义层与行级安全，一边把 Agent 的指令写进 LookML 文件，交给 Git 与 CI/CD 管；Stripe Data Pipeline 则把实时交易数据一并喂给分析与在线两条链路。四处动作都不是简单地加功能，而是把一条原本要跨系统拼接的缝，挪到了一个系统内部。

Databricks 多语句事务正式可用：Delta 与 Iceberg 上的跨表原子保证

事件概述

Databricks 于 10 月 16 日宣布 Multi-Statement Transactions 正式可用（作者 Benjamin Mathew、Prakhar Jain、Sumeet Varma）。在此之前的 lakehouse 上，事务保证的作用域是单条语句；要让跨多张表的改动同生共死，组织通常需要把数据搬进一套单独的仓库系统，代价是额外的数据副本、重复的治理策略与自建的一致性补偿逻辑。这一版把保证的边界从「一条语句」扩大到「一个 BEGIN ATOMIC ... END 块」，且覆盖 Unity Catalog 托管的 Delta Lake 与 Apache Iceberg 表。官方称这是第一个在 Delta 与 Iceberg 两种开放表格式上原生支持多语句事务的 lakehouse 架构。

配合这项能力的还有三件已经存在的东西：临时表、存储过程与 SQL 脚本化。三者与事务组合之后，传统数据仓库里的开发范式可以原样搬到开放格式的数据上。

技术解析

  • 语法与组合方式：事务以 BEGIN ATOMIC 开始、END 结束，块内可以放多条 DML。它可以在存储过程里（CREATE OR REPLACE PROCEDURE ... LANGUAGE SQL SQL SECURITY INVOKER AS BEGIN ATOMIC ... END），也可以在块内 CREATE TEMPORARY TABLE 暂存中间结果，还可以写入 streaming tables，让持续摄取与发布的流水线同样获得原子发布语义。
  • 行级并发而非锁串行：官方的表述是 lakehouse 支持 row-level concurrency——并发事务只要不更新同一行，就可以写同一张表。传统与云上数据仓库靠锁把写串行化，这里的差别在于冲突判定的粒度。Databricks 给出的一张图注写的是并发事务在规模下快 4.7 倍，对照物只描述为传统云上仓库与遗留仓库，未点名产品与配置。
  • 治理作用在读写两侧：事务尊重 Unity Catalog 的基于属性的访问控制，行级安全与列掩码在事务内的读与写上都生效。这对「先暂存、再校验、最后发布」这类涉及敏感数据的流程是关键前提。
  • 可观测性入口：官方给出的排障手段是 DESCRIBE TABLE、SHOW COLUMNS 与 GET DIAGNOSTICS——前者用于在写入前确认目标表的 schema 与表属性，后者用于捕获事务执行的信息。
  • 三类官方用例：其一，ETL 多表原子——把 INSERT INTO sales 与 MERGE INTO inventory 放进同一个块，订单状态与库存余额不会各自反映不同版本的批次；其二，仓库存储过程迁移——临时表暂存待处理理赔、DESCRIBE TABLE 校验目标、写入目标表、再写入审计表，四步一个原子单元；其三，Write-Audit-Publish——用 assert_true(count_if(order_id IS NULL) = 0, '...') 在发布前拦下不合法批次，校验、发布、写入审计记录同属一个事务，失败则整体回滚而不是暴露半成品。
  • 能力边界：正式可用的范围是 Unity Catalog 托管的 Delta Lake 与 Apache Iceberg 表；官方没有给出跨格式事务、嵌套事务与长事务的时限说明。

行业影响

这条发布削弱的是「为事务单开一套仓」的理由。过去一家需要开放格式的湖上分析、又要求跨表原子性的组织，常见的做法是额外维护一套仓库来承载这部分工作负载。这套做法的成本不在软件授权，而在它带来的数据副本、同步链路与治理开销——同一份数据两个地方存、两套权限、两份口径。事务能力落到 lakehouse 之后，这部分成本有机会被整体去掉，Fivetran 与 Accolade 两家客户的引语正是围绕这一点展开的。

Fivetran 的引语给出了一个具体的工程账：其 History Mode 用 SCD Type 2 保留记录的每个版本，一次源端变更对应两次目标端写入——关闭旧版本与插入新版本，两者必须同成功。在保证只覆盖单条语句的年代，这两步只能分开跑，再用后续同步里的对账逻辑与一致性检查去防御部分失败；改成多语句多表事务之后，关闭与插入合成一个原子单元，Fivetran 的说法是删掉了一整类一致性修复代码。Accolade 的引语则给出了量级：生产环境每天约 1700 个事务处理理赔与负债记录。

需要打折的地方是性能口径。4.7 倍这个数字来自官方配图的图注，对照物没有点名，也没有给出仓库规格与并发规模，只能读作「在某些配置下」。真正的判据是行级冲突判定这一机制本身：它决定了高并发写同一张表时，吞吐是随并发线性增长还是被锁压平。

相关链接

AlloyDB 把融合排序收进内核：一次 ai.hybrid_search() 调用吃掉向量与 BM25 两路召回

事件概述

Google Cloud 在 10 月 16 日发布的 Data Cloud 周更汇总里，把「原生 AlloyDB 混合搜索与 Reciprocal Rank Fusion」列入 10 月 12 日至 16 日这一周的上线清单。承载这项能力的技术博文由 Kumar Ramamurthy 与 Ricky Zhou 撰写，发布于 10 月 6 日；本专栏在 Vol.89 里只以一句话交代过其中的 BM25 部分，本篇补齐融合这一层。

要解决的问题很具体：现代 RAG 与搜索应用需要一边用向量检索拿语义上下文、一边用全文检索拿关键词精度，AlloyDB 两者都支持，难的是把两路结果合成一份有序结果。向量侧给出的是距离分，全文侧给出的是相关性分，量纲不同、分布不同，要把它们映射到同一尺度再做加权求和，这段逻辑脆弱，且依赖应用侧 expertise；若全文检索还跑在另一个系统里，还要在应用内存里按文档 ID 做 FULL OUTER JOIN、加权、排序。

技术解析

  • RRF 为什么能绕开归一化：Reciprocal Rank Fusion 只吃排名不吃分数。两路各自返回的排序位置直接进入公式，分数本身不需要被映射到公共尺度，也就消掉了「归一化公式随数据分布漂移而失效」这一类故障。
  • 调用形式是一个声明式 JSON 数组：SELECT id, score FROM ai.hybrid_search(search_inputs => ARRAY[...]::jsonb)。向量组件声明 data_type: "vector"、table_name、key_column、vec_column、distance_operator: "<=>"、limit，query_vector 还可以直接写 ai.embedding('text-embedding-005', '...')::vector 让数据库在查询内动态生成嵌入；文本组件声明 data_type: "text"、text_column、query_text_input。官方明确这个数组不限于两个组件。
  • 内核里的执行方式：函数为每一个组件动态生成一条 CTE，CTE 内用 ROW_NUMBER() 计算位置排名；所有组件的排名结果按文档 ID 做 FULL OUTER JOIN；最后用 RRF 公式合成统一分数。整个过程在单个查询计划内完成，官方强调的收益是事务一致性——融合看到的是同一时刻的两路结果。
  • 全文检索给了两条路：RUM 扩展把词位置直接存进索引，换取低延迟的相关性排序与高效短语匹配，官方给出的是 RUM 相对 GIN 在 BEIR Natural Questions 基准上的加速图，未给出逐项倍数；BM25 走 pg_textsearch 扩展，用 CREATE INDEX ... USING bm25 (product_description) WITH (text_config='english') 建索引，查询用 <@> 算子取 bm25_score，排序质量来自 TF-IDF 加词频饱和与文档长度归一化。Google 给出的选型口径是：追求延迟选 RUM，追求关键词打分精度选 BM25。
  • 外部检索也能作为一路输入：新增的外部检索 Foreign Data Wrapper 让 Elasticsearch、OpenSearch、Solr 上的结果直接参与同一次融合，接口仍是 PostgreSQL。
  • 官方自己列的对比维度：从多步应用工作流搬到原生 UDF 之后，代码复杂度从「复杂的归一化函数 + 服务调用 + 应用侧 join」变成零外部逻辑的单次声明式调用；维护从「不断调归一化公式」变成无需调参，因为 RRF 与分数分布无关。

行业影响

这条更新的落点是把「融合排序」这一层从应用代码收回数据库内核。过去这一层几乎必然长在应用里，因为它要一次碰到两个系统的结果，也只能由应用来做跨服务的 join。收回内核之后的直接收益是少一个要维护的组件，间接收益是融合与查询在同一事务视图里发生。

代价同样清晰：RRF 只吃排名，也就放弃了「向量路权重 0.7、关键词路权重 0.3」这类按业务调节的余地。对多数 RAG 场景这是划算的——可调权重在实践中往往意味着一轮又一轮没有终点的人工调参；对有明确先验的场景（例如型号、法条编号这类必须精确匹配的字段），放弃调权可能带来排序质量的损失。官方也留了口子，说后续会引入更多合并与排序算法。

把这条与 BM25 进入 PostgreSQL 生态放在一起看，方向是数据库正在把「检索」从附属能力变成本职工作：索引类型从 B-tree、GIN 扩展到 BM25 与向量，排序算子从比较大小扩展到距离与相关性，融合逻辑从应用侧搬进查询计划。这条路径的对立面是「数据库只管存，检索交给专门的引擎」——Google 自己也没有放弃后者，外部检索 FDW 就是给这条路径留的门。

相关链接

Looker：数据应用继承语义层，Agent 的指令进 Git 走 CI/CD

事件概述

同样是 10 月 16 日那份周更汇总，另外两条与 Agent 相关的条目指向同一个方向——把 Agent 相关的定义从 UI 配置项变成仓库里的代码。

第一条是 Looker Data Apps 进入预览（博文发布于 10 月 13 日，作者 Ani Jain、Sharon Zhang）。它是在 Looker 内部原生托管的交互式 Web 应用，由 AI Agent 生成：用自然语言描述需求，或用 Claude Code、Antigravity CLI 写好 React 应用再部署进去。Google 给的定位是把它作为仪表盘之上的一层——仪表盘负责聚合可见性与被动报表，数据应用负责执行，用户可以输入参数、跑模拟、改底层记录、向 Salesforce 与 Jira 派发事件。

第二条是 LookML 形式的 Dashboard Agents 配置进入预览（10 月 12 日发布于 Google Developer Community，作者 Vaibhavi Sonavane，要求 Looker 26.14 及以上）。它让 Agent 的参数、配置与提示词指令和仪表盘文件一起写在代码里，从而进入 Git 版本控制、同行评审、分支与自动化 CI/CD 校验。

技术解析

  • 数据应用继承什么：每一个应用直接继承已有的语义模型、行级安全与访问控制；Google 特别提到内置的查询检查让团队可以审计生成的每一行 SQL，以消掉指标幻觉。AlloyDB 那条的关键词是召回，这条的关键词是可审计——生成式界面要进生产，前提是它的取数口径可验证。
  • 运行时没有 token 成本：官方的说法是 LLM token 只在设计与生成应用的阶段消耗，之后终端用户的每次交互跑在原生 Looker API 与模型上，50 人和 5000 人的边际成本不变。这条决定了数据应用能否被铺开——若每次交互都要调模型，规模化之后成本与延迟都会失控。
  • 部署方式沿用嵌入：数据应用可以像嵌入仪表盘一样嵌进外部门户，不需要新的流水线、自定义应用代码或第二套权限模型。
  • Agent 声明的写法：在 LookML model 里声明 agent: sales_dashboard_agent { label: "Sales Performance Assistant"; is_dashboard_agent: yes; advanced_analytics: yes; show_thinking: yes; instructions: "..." }，instructions 里写业务规则（例如优先 Net ARR、默认与上一季度对比），并可用 LookML 常量 @{CONSTANT_NAME} 复用公司级 KPI 定义；随后在 .dashboard.lookml 文件里写 enabled_dashboard_agent: yes 与 default_dashboard_agent: sales_dashboard_agent。提交合并分支之后 Agent 即对终端用户可用。
  • 当前限制：每个仪表盘最多一个 Agent。
  • 同批的第三项：Data Agent Kit 本身在 10 月 5 日至 9 日那一周已正式可用（连接超过 15 个 Google Data Cloud 服务的 MCP 工具与 Google 编写的 agent skills，接入 VS Code、Antigravity、Cursor、Claude Code、Codex），这一周新增的是端到端 walkthrough 与 codelab，演示在代码编辑器里构建、测试与调度机器学习流水线。

行业影响

把提示词与 Agent 参数放进 LookML，本质上是给「对话式 BI 的行为」找了一个可版本化的载体。此前这类行为存在于两类地方：UI 里的配置项，或者更常见的——用户的提问习惯里。前者不可评审、不可回滚、难以在多环境之间复制；后者根本不可控。写成文件之后，改一句指令就是一次 PR，Dev 到 Prod 的推广与仪表盘代码同批进行，行为漂移可以被 git log 追到具体某次提交。

这一步的代价是错误的影响面被抬高了。写错一条指令，后果不再是「这个 Agent 回答得不好」，而是「所有看这块仪表盘的人都被同一套错误口径引导」。这也解释了为什么官方把它设计成需要同行评审与 CI/CD 校验，而不是单纯的编辑框。

与本期第一条放在一起看，两处的逻辑是同一个：Databricks 把「哪些改动必须同生共死」写进 SQL，Google 把「这个 Agent 应该按什么口径回答」写进 LookML。前者让约束可执行，后者让约束可评审。

相关链接

Stripe Data Pipeline 实时同步到 Lakebase Postgres：一条管道，两个目的地

事件概述

Databricks 于 10 月 15 日宣布（作者 Carlota Soto），Stripe Data Pipeline 支持把实时 Stripe 数据直接同步进 Databricks Lakebase Postgres，无需写代码。Stripe 侧负责全链路——选择要同步哪些表，之后由 Stripe 完成回填、持续投递与数据审计。该功能为公开预览，起步免费。

这条集成的意义在于它把同一个 Stripe 账号的出口从一条变成了两条。今年早些时候 Stripe 数据已经可以同步到 Databricks：通过 Delta Sharing 把支付、客户、订阅、退款、打款等数据共享到工作区，成为 Unity Catalog 里的一张普通表，服务分析与 AI 类负载——流失打分、用自然语言问各地区的 MRR、月末对账。现在多出来的一条通向 Lakebase，面向的是应用与 Agent 的运行时读取。

技术解析

  • 两条出口对应两类负载：Unity Catalog 侧看的是跨上千客户、数周历史的模式；Lakebase 侧看的是单个客户当下的状态。前者长在扫描与聚合上，后者长在点查与低延迟上。
  • 延迟口径：官方的表述是数据持续同步到 Lakebase，更新在数秒内到达。
  • 它取代了什么：官方点出两种现行做法及其成本。其一是直接调 Stripe API——低量时可用，流量增长后撞上限流；其二是 Webhooks——每个事件都要一个 handler，还要为投递失败写重试、为漏投与乱序写对账。两者的共同点是都要自建并运维一套基础设施，而这套设施失败时，客户拿到的是错误的权限或过期的账户信息。
  • 官方列的四类用例：按订阅状态实时开关产品功能（升级秒级解锁、取消或续费失败秒级收回）；账单与账户页实时反映刚发生的支付；用持续的 charge、refund、payout 做实时财务看板；把订阅与支付历史放在应用数据库里做个性化 Offer（取消后的挽留折扣、用量超计划时的升级提示、支付方式即将过期提醒）。
  • Lakebase 的定位：Databricks 的 serverless Postgres，面向应用与 AI Agent，与平台其余部分集成。

行业影响

这条集成指向的是同一个老问题的新解法：交易数据既要服务分析，也要服务应用。过去的常见架构是两套链路——分析侧走批量或流式的入湖管道，应用侧走 API 调用或 Webhook 落地到业务库。两套链路带来两份数据、两个延迟口径、两套权限，以及长期存在的对账工作。合并成一条管道两个目的地之后，对账问题的规模被压缩了，代价是组织要接受由 Stripe 托管投递语义，包括它选择的回填策略与审计方式。

与本期第一条放在一起看得更清楚：事务能力补齐的是 lakehouse 承载仓库型工作负载的缺口，Lakebase 这类 Postgres 出口补齐的是它承载应用型读取的缺口。Databricks 的四支柱叙事（Lakehouse、Lakebase、Apps、Lakehouse//RT）在结构上的含义，就是同一个治理体系要一并服务长查询、点查、应用与 Agent 四种访问模式。

相关链接

编者评

把四条放在一起看，10 月 15 日至 16 日这两天发生的事有一个共同形状：过去必须在两个系统之间做取舍的地方，被收敛成了一个入口。事务保证不再需要额外一套仓来提供，跨表原子性由 BEGIN ATOMIC 在开放表格式上直接给出；向量与关键词两路召回的融合不再需要在应用里写归一化与重排，一个 SQL 函数在查询计划内做完；Agent 的指令不再躺在 UI 配置项或用户的提问习惯里，而是成为 LookML 文件里可评审、可回滚的一行；Stripe 的支付数据不再需要在 API/Webhook 与分析表之间选一条链路，一条管道并行喂分析与在线。

四处收敛的代价也各有各的形状。RRF 换来鲁棒性的同时放弃了可调权重，对有明确字段级先验的检索场景未必划算；每个仪表盘只允许一个 Agent、且要求 Looker 26.14 以上，是预览阶段的现实边界；把事务写进 SQL 之后，过去靠对账兜住的部分失败会被显式暴露成回滚，一部分原本能跑完的作业会开始失败；把投递语义交给 Stripe 托管，意味着回填与审计策略不再由自己定义。共通的一点是：每一处收敛都把复杂度从一个可见但需要人工维护的位置，移到了一个不可见但由系统保证的位置。

本期还有几处没有单独立篇但值得记录的观察。LanceDB 在 10 月 15 日发布了 v0.41.0-beta.7，仍处在 beta 线上，条目集中在 blob 的读写语义（新增 blob_mode、blob 分层阈值、覆写时保留 blob v2 列、远端并发 blob 读取限流）与一项鉴权 API（被列在破坏性变更里）；Apache Superset 于 10 月 16 日打出 7.0.0rc2，相比 rc1 的变化以安全为主——公开角色的 RLS 规则现在对匿名用户生效、嵌入 guest 检查改为 fail closed、MCP permalink 查找保留 guest 身份、语义视图编辑与同库 dataset repoint 需要数据访问权限；ClickHouse 在 10 月 16 日发布了四个分支的补丁版本，但四个 release body 均为空，无法判断内容。AWS 10 月 16 日的 what’s new 条目里没有数据基建相关内容，Big Data Blog 的最新一篇仍是 10 月 15 日的 dbt 与 Redshift data sharing 组合，而后者所依赖的能力本专栏在 Vol.89 已经报道过，本篇未再重复。

关于中文来源的覆盖情况需要如实说明：阿里云、火山引擎等国内厂商的官方博客与产品更新页，本期仍然抓取不到可解析的条目列表，这已是连续第十四期。火山引擎文档站本轮能抓到的 10 月 16 日时间戳，经核对是云数据库 PostgreSQL 版文档导航的更新时间元数据，不是产品发布条目。本期在国内生态侧继续以开源项目的发布记录作为间接观察点：本轮扫描的 Apache Paimon、Apache Doris、StarRocks、SeaTunnel、Amoro、Kyuubi、Linkis、InLong、TiDB、TDengine 等仓库在 10 月 15 日至 16 日均无新版本，国产开源侧有新标签的只有 GreptimeDB v1.3.0-beta.2（10 月 15 日）与 MatrixOne v4.1.5（10 月 14 日），信息量不足以成篇。需要说明的是，这个观察点只能反映开源项目的节奏，国内闭源数据产品的更新动向仍然无法核实。