datainfra前沿动态 · Vol.88

Databricks 把 TB 级批量加载从 Postgres 主节点卸载给 Spark；EMR 8.1.0 用一个目录吃下四种表格式与跨账号查询；Weaviate 1.40.0 让向量索引可删可换；Lakebase 给每个编码 Agent 发一棵数据库分支

本期聚焦 10 月 6 至 8 日的四件事：Databricks 公开 LTAP 架构下的批量加载路径，让 Spark 直接生成合法的 Postgres 页面与索引，1TB 数据加载进入 5 分钟量级，主节点只写一条 WAL 记录；Amazon EMR 8.1.0 的 RedirectingSessionCatalog 把 Iceberg、Delta、Hudi、Hive 四种格式与跨账号 Glue 目录收敛到一个 spark_catalog；Weaviate 1.40.0 把向量索引从随表创建的对象变成可删除、可重建的独立资源；Lakebase 把数据库分支接进编码 Agent 的开发循环。

DataInfra Lakebase LTAP Postgres Databricks Amazon EMR Apache Spark Iceberg Delta Lake Apache Hudi Weaviate 向量索引 数据库分支 Agent Lakehouse

10 月 6 日到 8 日这几天，四件事指着同一个方向：把「生成状态」这件事从唯一的权威进程手里放出来，让可并行的参与者去生产，再把「确认」收缩成一次原子操作。Databricks 在 8 日给出 LTAP 架构下的批量加载细节：Spark 的每个 executor 起一个沙箱 Postgres，直接产出目标库能读的堆页面与 B 树索引，主节点最后只在 WAL 里写一条清单记录，1TB 数据加载从八小时以上进到 5 分钟量级。Amazon EMR 8.1.0 的 RedirectingSessionCatalog 把格式判定交给 Glue 元数据，四种表格式在一个 spark_catalog 下按表名直接 join，跨账号目录甚至可以在查询期动态注册。Weaviate 1.40.0 把向量索引从「建表时顺带生成、之后动不了」改成支持删除与重建的独立对象，并配上一套持久化迁移记录。Lakebase 则把数据库分支接进编码 Agent 的工作流：一个 Git worktree 配一棵数据库分支，一个 PR 配一棵临时分支，代价是分支不再被合并回去，schema 变更改由代码里的迁移来晋升。四处改动的形状一致——前面能并行的部分尽量并行，最后那一下确认要做小、做原子、并且可验证。

Databricks 用 LTAP 把 TB 级加载挪出 Postgres 主节点

事件概述

10 月 8 日，Databricks 四位工程师（Yecheng Yang、Nolan Biscaro、Szu-Po Wang、Pranav Aurora）发了一篇讲 Lakebase Postgres 批量加载的文章。问题是运营库的老问题：Postgres 的 COPY 对付常规摄入足够好用，但当客户开始把 Lakehouse 里的 gold 表回灌给应用，规模变了，两条硬性限制就露出来——每条导入的行都必须穿过同一个主写入者，而那台主节点上跑的正是应用的在线流量。批量加载要吃 CPU、I/O、连接数和 WAL 带宽，跟 OLTP 抢同一份资源。

文章里给了一个 beta 客户的数字：每天用 Synced Tables 往 Lakebase 灌约 10 亿行，此前一次批量加载要八小时以上，并且把 CPU 和内存打满；即便 Lakebase 有自动伸缩，他们仍被迫为 OLTP 资源大幅超配，只为扛住这一次同步。换成 LTAP 之后，内部基准是加载 1 TB 用时不到 5 分钟，官方口径是「最多 147 倍加速」，并且在线负载完全不受影响。

值得注意的是文章自己划了边界：这个基准测的是堆页面的构建时间，索引的并行构建还在做。全文把「还是不是 Postgres」也单独回答了一次——Spark 写出去的是 Postgres 页面，不是某种需要主节点二次翻译的导入格式。

技术解析

  • 沙箱 Postgres 与 OID 移植：每个 Spark executor 起一个二进制升级模式（binary-upgrade mode）的沙箱 Postgres，这是 pg_upgrade 用来跨大版本保留 catalog OID 的同一套机制。Lakebase 用它把目标库的 catalog OID 移植进每个沙箱，保证生成页面里嵌入的 OID 与目标库一致；driver 再给各沙箱分配互不重叠的 OID 区间，避免并发创建的对象撞号。
  • FREEZE 与校验和：沙箱内用二进制 COPY 加 FREEZE 构建该 executor 那一分片的堆。freeze 把导入的元组直接标记为已提交，目标库不必回溯沙箱的事务历史就能判定可见性。每个 worker 为生成的每一页算校验和，pageserver 在接纳文件时校验，损坏的页面不会变成权威数据。
  • 不下载堆就能建索引：B 树叶子项要的是 (key, ctid) 对，不是堆的内容。堆 worker 在构建分片时把键列与 tuple ID 额外导出到对象存储，索引侧用一张只含键列与 tuple ID 的辅助表（helper table）承载这些记录；CREATE INDEX 时一个自定义 table access method 按 heapam 的方式扫辅助表，但把 ctid 而不是辅助表自身的物理 TID 写进索引项，每个分片局部的 ctid 按前面所有堆分片的累计大小做偏移。结果是标准 B 树构建器不改一行代码，就能为一个它从未下载过的堆建出索引——搬运量从整份堆降到「键 + tuple ID」。
  • 交接只剩一条 WAL 记录：堆与索引分片落到对象存储后，Spark driver 写一份 manifest，在目标库上调一个 SQL 函数，主节点把这次导入记成一条紧凑的 WAL 记录。常规 COPY 会把全部数据量送过 safekeeper quorum，这里只送「这次导入的描述」。pageserver 认领上传文件为权威页面、校验、把页面预热到本地 SSD，主节点最后原子地把暂存数据换进用户可见的 synced table。
  • 不改 Postgres 内核：整条路径通过 Postgres extension 与 table access method 实现。沙箱里用 UNLOGGED 辅助表这类优化，官方明说是性能手段而非安全机制——沙箱没有应用流量共享，不需要 WAL 与锁竞争。

行业影响

这一步把「运营库能不能直接吃 Lakehouse 的产出」从工程纪律问题变成了架构问题。过去的做法是牺牲新鲜度、把加载排到业务低峰、手动管理回填与 checkpoint，本质上是让团队用流程去绕开单写入者瓶颈；现在这条路是让 Spark 这类为吞吐而生的引擎去生成状态，主节点退化成一个确认者。对做反向 ETL 的团队来说，Synced Tables 的适用场景被显著推宽。

代价也写得清楚：这次加速覆盖的是堆页面，索引并行化未完成，所以「分钟级」暂时不等于「端到端可用」；校验和、OID 区间分配、偏移换算都是新引入的 correctness 负担，一处算错就是静默的数据错位；并且这套能力目前绑定在 Lakebase 与 LTAP 上，不是任何 Postgres 都能享受。文章末尾说要把同一套协议推广到建索引、迁移这类大型操作，那是下一步要观察的地方。

相关链接

Amazon EMR 8.1.0 的 RedirectingSessionCatalog：一个目录，四种格式，跨账号 join

事件概述

AWS 在 10 月 6 日的 Big Data Blog 上介绍了 EMR 8.1.0 的 multi-catalog 能力，作者是 Suthan Phillips 和 Manjeet Chayel。它要解决的是 data mesh 场景下两个高频麻烦：同一个 Glue 库里混着 Iceberg、Delta Lake、Hudi、Hive 表时，查询要带格式前缀；数据域团队各自持有 AWS 账号，中心化的分析负载要跨账号 join。

此前这两件事都得靠流程兜：Spark 的 V1 catalog 是绑定单个账号单个 Glue Data Catalog 的单例，V2 catalog API 虽然支持具名目录，但只有 Iceberg 用了它，Delta、Hudi、Hive 仍走 V1。跨账号访问因此要靠 Lake Formation 授权、RAM 共享、resource link、逐表权限这一串组合。RedirectingSessionCatalog（RSC）把这三种能力合成一个可选项。

技术解析

  • 多格式路由：把 spark.sql.catalog.spark_catalog 设为 org.apache.spark.sql.connector.catalog.redirecting.RedirectingSessionCatalog。表解析时 RSC 调 Glue 读表元数据，检查 Parameters map 判定格式，缓存结果，再委派给对应的格式 catalog。原先要为每个格式注册一个 catalog 并在 SQL 里写 delta_catalog.db.delta_table，现在退化成一条配置加一句 SELECT * FROM db.delta_table，跨格式 join 也能写在一条语句里。
  • 跨账号具名目录：声明一个具名 RSC 目录指向远端账号的 Glue catalog（metastore.type = glue 加 metastore.hadoop.hive.metastore.glue.catalogid = 111122223333），本地 Iceberg 表可以直接 join 远端 Hudi 表，不复制数据。每个具名 RSC 实例自带 V1 metastore 委托并向全局 SessionCatalog 注册，绕开了单例限制。
  • 查询期目录发现：开启 spark.sql.catalogResolver = com.amazonaws.glue.catalog.redirecting.GlueCatalogResolver 后，查询引用未声明的目录时，EMR 调一次 Glue GetCatalog，按连接类型在查询现场注册——跨账号 Glue 注册成 redirecting catalog，Redshift Managed Storage 注册成 pushdown catalog，S3 Tables 注册成 Spark catalog。开启它是 opt-in 的，理由是避免为不存在的目录名产生意外 API 调用。
  • 自动装配 handler：把默认目录设成 RSC 就够了，EMR 自动填好 Iceberg、Delta、Hudi 三个 handler，不需要手写 handler.* 属性。
  • 覆盖范围：EMR 8.1.0 的 Serverless、on EC2、on EKS 三种部署形态都支持。

行业影响

这是把「格式差异」从 SQL 层面挪到元数据层面的典型动作。写查询的人不再需要知道自己 join 的那张表是 Iceberg 还是 Hudi，格式判定变成 Glue 元数据里一个字段的查表动作并带缓存；账号边界也从「先做一堆授权与共享配置」变成「在会话里声明一个目录」。对已经把数据按域拆到不同账号的组织，这类能力的价值不在性能，在于把跨账号分析从项目变成配置。

文章自己的限定同样重要：multi-catalog 是查询期解析，它不复制数据、不复制表、也不授予权限，跨账号读仍然需要 Lake Formation 授权、Glue 资源策略、S3 桶策略和 KMS 密钥策略配合。Delta 与 Hudi 需要额外加 OTF session extensions，Hudi 还要 KryoSerializer；异构格式 join 的代价也仍然存在于执行侧，RSC 解决的是寻址与委派，不是执行计划。

相关链接

Weaviate 1.40.0：向量索引可删可换，命名空间进 GA

事件概述

Weaviate 在 10 月 7 日发布 v1.40.0，标题里点出了三项：Alter Schema 删除向量索引、HFresh 的 MUVERA、RQ-4 量化。release notes 显示本次没有破坏性变更，四个主要板块分别是 Namespaces（GA）、删除向量索引（GA）、属性重建索引（Preview）、HFresh 与去重备份。对一个已经进生产的向量库来说，这批改动的共同点是：此前随表创建、之后基本动不了的索引与租户边界，开始变成能在线调整的对象。

技术解析

  • Namespaces 转 GA：在共享集群上提供控制面与数据面的租户隔离。相关改动包括按命名空间对 tenant 操作做门禁、把替换副本固定到该 namespace 的 home node、推导 effective-suspended 状态并为分片物化加护栏、以及修掉引用（references）相关的一批问题。这项能力被标为需要 license。
  • 删除向量索引转 GA：支持从已有属性上删掉倒排/向量索引以回收磁盘空间，并接进 RBAC 与多租户。工程细节里有几处是这类操作真正难的地方：中断的 strip 删除可以从记录的 pending set 恢复继续；leader 被杀后重试写入而不是直接判失败；删除多级向量索引时一并清掉 MUVERA bucket，删 HFresh 索引时清掉对应目录与 bucket；被删向量的 dimension 行也要清。该 endpoint 现已默认启用。
  • 属性重建索引（Preview）：允许改属性的索引类型。为了让它可恢复，团队加了一条持久化迁移记录：只在数据真正落盘后才 checkpoint 重建进度，用 RAFT 编号目录防止重启时对一个未建完的索引报成功，并拒绝与迁移目录同名的属性。顺带还上了节点级查询准入控制，以及删掉一批不可达的重建路径和 /debug/index/rebuild/inverted* 路由。
  • HFresh 与 MUVERA：HFresh 侧是大量性能与内存改进——带预算感知的并行 rescoring、通过单个 bucket view 与池化缓冲读 rescoring 向量、启动时后台预热 version map、posting 分裂改用全精度向量做聚类；还修了一个正确性问题：过滤搜索的结果此前依赖 posting 的探测顺序。MUVERA 这次的改动是把路由预算与重排预算解耦。
  • 去重备份：opt-in 的 dedupeReplicas——已收敛的分片只归档一次，恢复时再扇出到每个副本；未加载的分片依据持久化的 hashtree root 去重。同样按 license key 门禁。

行业影响

向量库此前长期处在「索引是建表副产品」的阶段，schema 一旦定错，修法往往是重建整张表。把删除与重建做成一等操作，等于把索引的生命周期从表的生命周期里剥离出来，这对长周期运行、schema 又要跟着业务演化的库是实质性的运维改善。Namespaces 与去重备份则是把多租户与成本两件事推进产品边界——代价是这两项都挂 license，开源路径与商业路径的差距在这里被明确画出。

需要留意的是：重建索引仍是 Preview，且它引入了一类新的状态机——迁移记录、RAFT 编号目录、swap window 期间落进来的写入——这些是新的故障域，升级前值得在副本上先跑一遍。

相关链接

Lakebase 把数据库分支接进编码 Agent 的开发循环

事件概述

同样在 10 月 8 日，Databricks 的 Thibaut Gourdel 发了另一篇 Lakebase 文章，方向不是恢复，而是开发流程。他的判断是：并行跑多个编码 Agent 正在变成常态，工具链也跟着演进（skills、hooks、MCP、subagent），但工作流里一个关键环节长期被忽略——数据库。每个并发 Agent 都要读 schema、改 schema、灌数据、跑测试；共享一个 dev/staging 库时，Agent 会在 schema 变更上互相冲突，或者退回使用与真实数据不符的 mock。

Lakebase 的做法是给数据库也开分支：copy-on-write，不论库多大都能在一秒内开出分支，父子分支共享数据、只在分化处消耗额外存储，空闲分支可缩到零因而无计算成本。文章给出了一条完整链路，并配了示例仓库。

技术解析

  • 一个 worktree 配一棵分支：代码侧用 Git worktree 给每个 Agent 一个独立目录，数据库侧靠仓库里的 post-checkout hook 自动建分支。流程是 Agent 执行带 worktree 的启动命令，Git 建目录，hook 触发，Lakebase 建分支，Agent 手里便有了一份独立的代码目录与一份独立的数据库。
  • 分支不合并，schema 走迁移：这是与 Git 最关键的差别——Lakebase 的分支不合并回父分支，因为父子两侧都可能独立变化，对账数据很快就不现实。schema 变更改以代码形式与应用逻辑放在一起（Drizzle、Flyway、Liquibase、Alembic 这类工具），部署时通过迁移晋升到父分支。
  • 每个 PR 一棵临时分支：PR 打开时 CI 调 Lakebase CLI 建一个以生产分支为父的临时分支，迁移工具在新分支上跑，预览应用指向该分支的连接串，CI 生成一份 schema diff 作为 PR 评论贴出来， reviewers 一次就能看到代码变更与数据库变更；PR 关闭或合并后删分支。
  • 分支的其他用法：从生产在故障前的时间点开分支做定点复现；发布前自动开分支跑迁移与测试；用 Unity Catalog 的 masking 从生产派生数据，从而在不碰线上库的前提下拿到接近真实的数据。
  • 配套仓库：databricks/tmm 下的 Lakebase-Agentic-CI 目录给出了 GitHub Actions 工作流与 hook 脚本的可运行示例。

行业影响

这篇的价值不在 Lakebase 的分支本身——分支式恢复此前已经讲过——而在于它把数据库分支定义成了 Agent 并发的基础资源。当并行 Agent 数量从一两个涨到十几个，共享环境的冲突概率是超线性上升的，而数据库恰好是那个最难隔离、又最容易污染的状态。把「给每个 Agent 一份隔离状态」做成秒级、零成本、可丢弃的操作，等于把并发规模的上限从数据库侧挪走。

代价是流程上多了一个必须认真对待的环节：既然分支不合并，schema 变更就必须以代码为唯一真相，迁移工具从「可选最佳实践」升级为「唯一晋升通道」。一个 Agent 如果绕开迁移直接改了分支里的表，那次改动在分支删除时就消失了。对已经有成熟迁移纪律的团队这是顺水推舟，对没有的团队，它要求先补上这门功课。

相关链接

编者评

把这四件事摆在一起，动作是一致的：谁有权生成状态，正在从「唯一的权威进程」下放给「可并行的参与者」，而确认动作被压缩成一次原子操作。LTAP 里，Spark 的一堆沙箱生成堆页面与 B 树，Postgres 主节点最后只写一条 WAL 清单记录；EMR 里，格式判定交给 Glue 元数据，目录本身甚至可以在查询现场注册；Weaviate 里，索引从建表副产品变成可删可换的独立对象，重建过程还配了持久化的迁移记录；Lakebase 里，每个 Agent 与每个 PR 都能拿到一份完整且可丢弃的数据库状态，唯一保留下来的是代码里的迁移。

有意思的是它们对「确认」的处理方式出奇地一致：不是靠更强的校验逻辑，而是靠把确认点变少、并把每次确认要做的事写清楚——pageserver 校验和、Parameters map 里的格式字段、RAFT 编号的迁移目录、PR 上贴出来的 schema diff。并行度上去以后，能被人读懂的那部分信息反而更重要了，因为它是唯一能判断「这次并行的结果能不能认」的东西。这大概是接下来一年做数据基建时最值得盯着的一条线：别只问能不能并行，要问并行之后那一下确认凭什么可信。

本期中文源仍然没有可用的新增内容——阿里云、火山引擎的数据类发布入口连续多期抓取无果，我们改以开源仓库的发布日期作为兜底核验，本期四条均来自英文一手源。另外本期未采用的两条线索记在这里备查：Vortex 0.88.0（10 月 8 日）以标量构造、统计读取与聚合合并的性能改动为主，另有 arrow 导出选项与 blocked BitPacked 的两处格式破坏性变更；ClickHouse 在 10 月 8 日给四条分支各打了一个补丁标签，模式与此前报道过的同日多分支补丁一致，未单独成篇。