datainfra前沿动态 · Vol.61

Databricks 提出 LTAP，把事务与分析统一在存储层而不是引擎层，湖仓不再为实时分析复制第二份数据；Temporal 与 Lakebase 组合出可持久执行的 agent 参考架构，重试策略、幂等写入与审计回流全部下沉到基础设施；Google 把 Data Agent Kit 做成 IDE 里的 MCP 服务器加技能包，一次会话横跨 BigQuery、Cloud SQL 与对象存储；Rubrik 发布 Iceberg 感知备份，恢复时自动重建元数据并重注册目录

本期聚焦数据栈四个层级的同步改造：存储层为 agent 拆掉 OLTP 与 OLAP 之间的墙，执行层把 agent 的控制流与运营状态交给基础设施托管，接入层把跨库排查收敛成 IDE 里的一段自然语言，恢复层承认开放表格式的原生存量保护不住目录。四处的代价都换了个位置，没有一处消失。

DataInfra Databricks LTAP Lakebase Temporal Unity Catalog Change Data Feed Google Cloud Data Agent Kit MCP dbt Rubrik Apache Iceberg S3 Tables Glue Data Catalog DataInfra前沿动态 Vol.61

本期四条动态来自同一个压力源：agent 成了数据栈的新使用者，而它既等不起批处理，也不遵守人类操作员的克制。Databricks 用 LTAP 把事务与分析统一在存储层，冷层直接以列式落盘，运营库不再需要为分析负载再复制一份；Temporal 与 Lakebase 的参考实现把 agent 的重试、幂等、人工审阅与审计回流拆成四类可配置的基础设施能力，应用代码只保留业务判断；Google 的 Data Agent Kit 把 MCP 服务器与技能包塞进 IDE，一次会话里跨 BigQuery、Cloud SQL 与对象存储三种系统追根因；Rubrik 则指出一个被忽略的前提——Iceberg 的 snapshot 只是同桶同账户里的元数据指针，真正的备份必须连目录条目一起保护，并在恢复时自动重注册。四处的代价分别换成了冷层刷新延迟、预览特性的端到端验证缺口、人类审批环节，以及一次跨账户的角色信任。

LTAP：把 OLTP 与 OLAP 的墙从引擎层挪到存储层

事件概述

Databricks 于 2026 年 9 月 7 日发布对高级产品经理 Jonathan Katz 的访谈，正式给出 LTAP（Lake Transactional/Analytical Processing） 这一命名的完整解释。Katz 是长期 Postgres 贡献者，这个背景让整篇论述的起点显得扎实：运营与分析之所以分开四十年，不是厂商偷懒，而是行存与列存的物理差异决定的——行存让单条记录返回最快，列存让全量扫描最快；运营查询被设计成尽量少占资源，分析查询则可以吃满一个大规模并行系统的全部算力。

真正的变化在于 agent 的行为模式。Katz 举的例子是欺诈检测：信用卡交易在数百毫秒内清算完，如果负责抓欺诈的 agent 读的是几分钟甚至几小时前的批式副本，它根本来不及在交易完成前做出反应。可一旦让 agent 直接对运营库发起跨客户历史的扫描查询，又会拖慢同一时刻正在清算的每一笔交易。一个 agent 或许还懂得克制，一群 agent 并发发起相似查询时，运营库会很快被压垮。

技术解析

  • 统一的位置是存储层，不是引擎层：LTAP 让分析查询直接作用在运行中的运营数据上，数据不搬走，也不给事务系统增加负载。HTAP 之所以长期停滞，按 Katz 的说法是因为它要一个系统同时干两件事，昂贵、笨重且不开放；LTAP 的答案是保留各自的专用引擎，只统一底下那层。他的原话是——存储是任何数据系统里便宜的部分，计算才是贵的部分。
  • 依赖 Lakebase 的存算分离：LTAP 之所以可行，前提是 Lakebase 继承自 Neon 的架构——无状态、短暂的计算与湖中存储完全解耦。持久存储层得以独立承接高吞吐写入，并周期性地把数据刷到对象存储做持久化，跟当时跑着什么计算无关。
  • 最难的一步是位级保真：Postgres 有自己的数据类型与编码，Iceberg 和 Delta 有自己的。要把运营数据写成 Parquet 且保留 Postgres 原始的物理表示、一个比特都不改，才能让同一份数据的两种表示合二为一。这一步做不成，统一存储就只是又一次 ETL。
  • 两层存储的冷热分工：热层以行格式留存，服务运营侧的快速访问；冷层以列格式留存，服务分析侧的扫描读取。两侧各取所需，物理上仍是同一份数据。
  • 治理边界跟着走：Lakehouse 原本的价值之一是集中目录带来的统一策略视图，而这套东西从来没有真正覆盖过运营系统——运营系统生来就是数据孤岛，管道把数据运走之后，下游发生了什么没人负责。LTAP 把运营数据也纳入同一套存储模型与同一个目录，分析不再需要让数据跨出治理边界。

行业影响

把统一的位置从引擎挪到存储，是过去两年”开放表格式 + 多引擎”路线的自然延伸：既然格式已经开放、引擎已经可插拔，那么最后要统一的就只剩下”数据到底有几份”。LTAP 给出的答案是一份——代价是冷层的刷新延迟，以及一套必须做到位级保真的格式转换。对已经在用 Iceberg 或 Delta 的团队，这个论述并不要求换引擎，只要求接受”运营库的持久化层可以直接产出开放格式的列式文件”这一新前提。

对架构师而言，Katz 在文末给出的判据值得记住：如果 agent 的下一个决策依赖于仍在沉降中的数据，而这份数据又存放在一个被设计成”贴近且受保护”的系统里，那么旧的管道加复制模型就快不起来。这是判断某个 agent 负载是否真的需要 LTAP 这一类模式的实用测试。

相关链接

Temporal 加 Lakebase：把 agent 的持久执行、运营状态与审计拆成三层

事件概述

Databricks 于 2026 年 9 月 8 日发布由 Sam Ingbar 撰写的参考架构，并配套开源仓库 temporal-sa/temporal-lakebase-agent，以一个个人贷款承保 agent 为例，演示如何把 Temporal 的持久执行与 Lakebase Postgres 的可查询运营状态结合起来。

它要解决的问题有六个：恢复、重试、长等待、运营可见性、运行时治理、审计。这六项过去多半散落在应用代码里，由每个团队各自实现一遍；这次的做法是把它们分别交给不同的基础设施层。

技术解析

  • 三层分工：Temporal 的 Event History 负责驱动 replay，保存 agent 运行的控制流状态；Lakebase 保存面向应用的视图——agent_ops schema 下的 agent_runs、agent_messages、agent_tool_calls、agent_review_decisions 等表，记录当前状态、对话、工具调用证据、审阅状态与指标；Unity Catalog 作为承保策略的治理源，经 continuous synced table 同步成 Lakebase 里的只读 Postgres 副本 agent_policy.underwriting_policy_limits。策略负责人改了源表，后续运行即可读到，不必重新部署 Worker。
  • 重试策略按操作粒度配置：模型调用 Activity 最多 4 次尝试、3 分钟 schedule-to-close 超时；工具调用 Activity 最多 3 次尝试、60 秒 start-to-close；Lakebase 写入 Activity 最多 5 次尝试、15 秒 start-to-close。边界划分得很清楚——Temporal 决定何时重试，Activity 决定外部系统如何处理这次重试。
  • 幂等靠确定性 ID 加约束：run_id、message_id、tool_call_id、event_id、review_id、decision_id 全部预先分配，Postgres 的主键与唯一约束强制其唯一性。写入走 upsert 与 guarded update，使 at-least-once 的 Activity 重试收敛到同一条逻辑记录。文中给出的终止态守卫例子是：工具开始写入只允许把非终态行写回 started，若目标行已是 succeeded 或 failed，则影响 0 行且不报错。
  • 审计回流走 Change Data Feed：为 agent_ops 各表设置 REPLICA IDENTITY FULL 后，Lakebase 从 Postgres WAL 捕获增删改，批量写入 Unity Catalog 管理的 Delta 历史表，命名模式为 lb_<table>_history。刷新间隔约 15 秒——适合审计与分析，不适合实时 UI，UI 的当前状态仍直接查 Lakebase。
  • 人工审阅不占 Worker：Workflow 用 wait_condition 等待承保人决策，Temporal 保留 open Workflow 但不占用 Worker 进程。API 在发 Signal 前先查 Lakebase 确认状态为 AWAITING_REVIEW 且 review_id 与当前轮次匹配，任一不满足即返回 conflict。

行业影响

这套架构真正的信号不在 Temporal 或 Lakebase 任何一方，而在职责的切分方式：控制流状态、应用状态、治理策略、审计轨迹分别落在四个不同的系统里，彼此用确定性 ID 而不是分布式事务来对齐。文中明确写着两个系统不共享事务，Lakebase 写入以 at-least-once 执行，正确性由幂等契约而非两阶段提交保证。

代价也写得很直白，值得逐条留意：Change Data Feed 仍是 Public Preview，仓库只配置了源 schema，不包含已观测到的端到端运行，启用与目标表验证仍是部署步骤；本地崩溃演练在 Lakebase 禁用的条件下进行，只隔离验证了 Temporal 侧的恢复；0 行写入结果当前不会被 Activity wrapper 转成失败，生产代码需自行确认终态后分类处理；示例在 Lakebase 不可用时会回退到 fixture 策略并记录 fixture_fallback，而受监管工作流应当 fail closed；Databricks OAuth token 与数据库凭证会过期，长运行 Worker 必须在 1 小时到期前刷新连接池；Temporal Cloud 按 Actions 与 Event History 存储计费，重试频率与长期打开的 History 会直接体现在账单上。

相关链接

Google Data Agent Kit：MCP 服务器加技能包，把跨系统排查收进 IDE

事件概述

Google Cloud 于 2026 年 9 月 8 日宣布 Data Agent Kit 进入预览。它是一组 MCP 服务器与 agent 技能（skills），让数据开发者在 IDE 里直接跑数据工作流：既可作为 VS Code 分支（Antigravity IDE、Cursor）的扩展，也可作为插件接入 Antigravity 2.0 / CLI、Claude Code、Codex 等工具。

官方给出的演示场景很典型：一个开放性问题——平均订单值在 1 月下降 7%，总收入却持平，为什么。答案的三块碎片分散在三个系统里：订单明细在 BigQuery，客户记录在 Cloud SQL 的 Postgres 生产实例，营销活动规则是对象存储里的原始 JSON。

技术解析

  • 两个机制：MCP 是连接 agent 与工具、数据库、远端云基础设施的开放标准；skills 是 markdown 文件，用来补充 agent 对特定技术栈的知识。二者叠加的效果是——agent 不再只生成 SQL 片段让人复制粘贴，而是自己执行查询并读回结果。
  • 权限发生在执行前：agent 调用 execute_sql_readonly 之类的 MCP 工具前，IDE 会暂停请求授权，可以只放行一次以便审计，也可以设为 always allow。执行轨迹可被检查，包括每一次 MCP 工具调用和发往 BigQuery 的原始 SQL。
  • 一次会话跨三种系统：先用 BigQuery 定位到均值下滑来自新增渠道 B2B-Wholesale（AOV 约 75 美元，而 Online 与 Offline 仍约 110 美元，业务本身没有下滑，是产品结构变了）；接着切到 Cloud SQL 的 MCP 查出这 100 个批发账户全部是 30 天内新建的主体；再切到 Cloud Storage 的 MCP 追出 92% 的批发订单使用了促销码 BIGORDER25，25% 折扣拉低了混合 AOV。
  • 从临时分析到可复现管线：让 agent 把上述排查固化成 dbt 项目，它会自建虚拟环境、装 dbt-bigquery、写模型与测试并运行 dbt build。首次构建失败——order_id 唯一性测试抓到重复，原因是客户可以拥有多只宠物，第一版模型把宠物档案直接挂在订单上，一个三宠家庭的订单被拆成了三行。agent 读取自己的终端输出后重写逻辑并重跑，直到通过。
  • 官方保留的提醒：agent 能写出成堆的代码，数据质量检查仍需人来定义——不过这些检查也可以让 agent 来写。

行业影响

这条动态的价值不在”用自然语言查数据”，而在接口的位置变了。过去跨库排查的成本主要来自切换上下文：不同方言、不熟悉的 schema、重复的 join，以及十个浏览器标签页。Data Agent Kit 把这些折叠进 IDE 的同一个会话，用的是 MCP 这一开放标准加可编辑的 markdown 技能文件，而不是某个厂商的私有插件协议——这意味着技能文件可以被团队自己改写和版本化。

它与此前几期反复出现的 MCP 主线是同一条：Vol.55 里 AWS 把 Spark 排障做成托管 MCP 服务器，Vol.58 里 AWS 用 MCP 加 AgentCore Gateway 做联邦数据访问，这次轮到 Google 把 MCP 放到开发者本地。三家不约而同选择同一个协议，说明”agent 接数据”的接口层已经收敛，剩下要竞争的是技能内容与人机审批的粒度。

相关链接

Rubrik Iceberg 感知备份：保护对象从文件扩到目录条目

事件概述

Rubrik 于 2026 年 9 月 8 日发布 Apache Iceberg Protection，面向 AWS 上运行的 Iceberg 表提供企业级数据保护。新闻稿与技术博客（作者 Mike Preston）给出了同一个核心论断：Iceberg 的原生 snapshot 只是元数据指针，不是备份。

这个论断拆开来有三层。其一，snapshot 指向的文件就躺在同一个 S3 桶、同一个 AWS 账户里，不是独立副本；表被删除、被勒索软件加密、或被一个权限过大的 AI agent 覆盖时，指针连同数据一起消失。其二，即便底层文件还在，把对象恢复回 S3 也换不来一张能用的表——没有任何东西告诉目录去哪里找它们，得有人手工重建元数据，而 Iceberg 表在千万级文件、数 PB 的规模下，这是实打实的工程量；若改从源端重建，则是数周的计算与传输成本。其三，现有工具补不上这个缺口：AWS Backup 能抓 S3 对象但不懂什么是 Iceberg 表，恢复后仍是一堆没有目录的文件；版本控制与复制会把一次误删原样复制过去；自定义脚本脆且很少考虑目录。

技术解析

  • 备份范围扩到四件套：数据文件、manifest、元数据，以及目录条目本身。覆盖 AWS Glue Data Catalog（自管）与 Amazon S3 Tables（全托管）两类目录。
  • 执行链路：Rubrik 从自己拥有的 AWS 账户取客户专属凭证 → 调用 STS:AssumeRole → 通过 onboarding 时部署的跨账户角色获得权限 → 调用区域 API 枚举 catalogs、tables 与 metadata → 拉起一组轻量、短暂的 EKS Pod 执行采集 → 以不可变、air-gapped 方式写入客户自有 S3 桶或 Rubrik Cloud Vault → 元数据回传 RSC 用于恢复。
  • 增量不做全桶扫描：直接用 Iceberg 自己的 manifest 文件判断自上次备份以来变了什么，而不是对桶做全量清点。备份窗口在表增长到数十亿对象时仍然可控。
  • 只备份需要的版本：可选仅备份最新 snapshot，或针对最新压缩后的 snapshot、最新打了标签的 snapshot 做备份，并可在取不到时 failback 到最新 snapshot。
  • 恢复时自动重连目录：恢复流程基本是备份的逆过程，多出的一步是 Rubrik 把目录重新拼好并自动重注册表，Athena、Spark、Trino 立即可查，不需要人工做目录手术。
  • 沙箱分支降低恢复风险：可在 schema 变更或大批量写入这类高风险操作前触发一次按需备份，恢复时先落到隔离的 Iceberg 分支上校验数据与 schema，确认无误后再 promote 到生产。
  • 覆盖粒度可继承：支持账户级覆盖，避免下季度新建的表因为没人打标签而裸奔；需要精细控制时，可用 namespace 级或表级 SLA 覆盖账户级策略。

行业影响

这条动态指向开放表格式的一个真实盲区：格式本身提供了 time travel、rollback、分支等能力，社区讨论也几乎全集中在查询性能与互操作上，但”表被整体毁掉之后怎么办”长期依赖各团队自建脚本。Rubrik 的切入角度是把 catalog 当成一等保护对象——这恰好与过去几期观察到的趋势同向：Vol.59 里 Iceberg REST Catalog 的 Read Restrictions 把治理下沉到 loadTable 响应，Vol.60 里 EMR Trino 通过标准 REST 端点连 S3 Tables，目录正在从”存表名的地方”变成整个湖仓的控制平面。控制平面一旦承担了这个角色，它的可用性就成了新的单点。

需要注意的是成熟度：该能力在发布时尚未 GA，官方口径是本月晚些时候正式可用；上述能力描述全部来自厂商单方口径，尚无第三方实测。跨账户 AssumeRole 加临时 EKS Pod 的架构也意味着一次额外的角色信任与网络路径，这是引入这类方案时不能跳过的评估项。

相关链接

编者评

把这四条放在一起看，会发现数据栈的四个层级在同一周里为同一位新使用者做了改造，而这位使用者的特点只有一个：它等不起，也不会自我克制。存储层的回应是不再复制第二份数据，让运营数据的冷层直接以列式落盘，代价是冷层刷新带来的延迟；执行层的回应是把 agent 的控制流、运营状态与审计轨迹拆给不同系统托管，应用只留业务判断，代价是”两个系统不共享事务”这一前提必须被整个团队理解和接受；接入层的回应是把跨库排查折叠成 IDE 里的一段自然语言，代价是人类审批被挪到了每一次工具调用之前；恢复层的回应最直白——承认开放表格式的原生机制保护不住目录，于是把目录条目一并纳入备份，代价是一次跨账户角色信任和一组临时计算资源。

值得留意的是这四家给出的答案形态高度一致：都不是再加一层，而是把原本由人或应用代码承担的判断，改写成可声明、可配置、可审计的基础设施能力。统一发生在存储而非引擎、重试策略按操作粒度声明、权限在每次工具调用前确认、备份范围从文件扩到目录条目——四处动作不同，方向相同。对从业者而言，本期真正可以立刻用上的或许不是任何一个新产品，而是那几条被明写出来的边界：冷层有延迟所以 UI 别查它，0 行写入不等于成功所以生产代码要自己确认终态，agent 写的 dbt 模型仍然要靠唯一性测试兜底，Iceberg 的 snapshot 不是备份所以目录必须单独保护。这些边界被写进文档，比它们被留在某次事故复盘里要好得多。