datainfra前沿动态 · Vol.80

Databricks 把向量与 BM25 检索收进 Postgres；Apache Polaris 1.8.0 把提交冲突从致命 400 改成可重试 409；DuckDB v2.0 alpha 在 Windows 上跑出 6 倍；腾讯云 DataBuddy 用统一语义层换问数准确率

本期聚焦四件事：检索回到 OLTP 数据库内部、目录层的错误语义被逐个改对、查询引擎的性能收益落到编译器与分配器、云厂商把 Agent 的语义与权限收进平台。

DataInfra Databricks Lakebase pgvector 向量检索 Apache Polaris Iceberg REST DuckDB 腾讯云 DataBuddy 语义层

本期四条来自四个不同的层，动作却是一致的：都在把边界上原本含糊的地方改写成明确契约。Databricks 让 Lakebase Postgres 自带向量与 BM25 索引，检索不再是外挂的第三个系统；Apache Polaris 1.8.0 几乎没加新能力，改的全是状态码与权限边界的措辞；DuckDB 1.5.6 是个补丁版，真正的看点是 v2.0 alpha 把 TPC-H SF300 从 822 秒压到 129 秒，收益来自 clang-cl 与新分配器；腾讯云 DataBuddy 正式发布，把指标口径与 Agent 权限收进平台语义层。

Databricks Lakebase Search：把检索系统收进 Postgres

事件概述

2026 年 9 月 28 日，Databricks 宣布 Lakebase Postgres 自带检索引擎，通过两个扩展交付：lakebase_vector（近似最近邻）与 lakebase_text（BM25 全文）。两者在 AWS 与 Azure 上正式可用（GA）。语义检索、关键词检索与混合检索都能在同一条 SQL 里完成，并与运营表直接 join，不再需要外挂一套搜索引擎加一条 ETL。

GCP 上的节奏不同。同日的 Databricks 发布说明把 GCP 版标为 Beta，并给出三个扩展：除上述两个外还有 lakebase_tokenizer，通过 tokenizer_wholeword 模板做可配置的整词分词，与标准 to_tsvector、@@ 算子、排序函数和 GIN 索引配合，供 lakebase_text 做自定义分词下的 BM25 排序。GCP 说明还给出两个 AWS/Azure 稿里没有的数字：单个索引可扩展到 10 亿以上向量，索引构建比 HNSW 快 50 到 100 倍。

官方先把 pgvector 的三条墙摆出来，再讲自己的做法。pgvector 是 Lakebase Postgres 里安装量最大的扩展，Databricks 从客户那里归纳出三个反复出现的问题：成本随数据量而不是随用量增长、索引维护昂贵且阻塞数据库、检索质量与性能互相牺牲。

技术解析

  • 第一条墙是内存：HNSW 依赖随机访问的图遍历，索引一旦溢出到磁盘，查询退化成一串随机读，性能掉 10 到 50 倍。768 维 float32 向量算上图链接与 Postgres 开销后单条约 3.3 KB，1 亿行需要约 330 GB 内存才能常驻，无论实际查不查都得按整个索引 provisioning。
  • 第二条墙是维护：构建一旦溢出到磁盘就是数百万次随机 I/O，官方称在标准云实例上建一个 pgvector 索引要近 50 小时。写入端同样受制于多层图的随机访问修改。HNSW 没有全局再平衡，想恢复检索质量只能全量 REINDEX，这个操作锁表并阻断生产写入。
  • 第三条墙是并行：一个 pgvector 查询跑在单个 Postgres backend 进程里，HNSW 索引扫描无法并行。要提高召回就得访问更多图节点，延迟上升、QPS 下降，扩吞吐只剩加连接或加只读副本这一条路。
  • lakebase_vector 的两个手法：层次化 IVF 聚类把向量分组成连续块，查询先在内存里给质心打分，只读少数几个有希望的块，把数百次随机跳变成几次大的顺序读；RaBitQ 二值量化把每个向量压到约每维 1 bit，比 float32 小约 32 倍，查询先扫紧凑编码筛出候选，再对一份有界的短名单用全精度重排。
  • 实测口径：VectorDBBench 的 LAION 100M 数据集上，吞吐是次优系统的 2 倍，成本是某家云 Postgres 加 pgvector 的 四分之一（未计入 autoscaling 带来的额外节省）；P99 延迟 71 毫秒时召回 97%。官方注明 pgvector 与 DiskANN 只在单个大实例上测过。
  • 缩容到零的代价：存算分离让节点完全无状态，空闲时挂起、下次查询再拉起。100M × 768 维数据集上，scale-to-zero 后第一个查询的 P90 是 1.13 秒；1 亿向量可用 1 个 Lakebase Compute Unit 承载，计费只跟随实际查询活动。
  • 索引构建：质心只在一个小的随机样本上训练一次，这是唯一需要扫全量数据的步骤；之后每条向量独立分配到最近质心、量化、写入所属块，可以按核铺开。更进一步是把构建从主库卸载到 Spark 这类分布式引擎，官方称可把构建时间压到分钟级——这一条标注为”敬请期待”，尚未落地。
  • lakebase_text：BM25 用全局 IDF 打分，重权重罕见的高意图词、惩罚常见填充词。遍历时计算分数上界，跳过进不了 Top-K 的整个 posting block，官方称比传统 tsvector + GIN 更快。过滤在扫 cluster block 时就地做，避免多取候选，让带谓词的查询保持高召回。
  • 客户侧数字：Conexiom（AI/ML Architect Jordan Voves）在 1 亿多行的表上做 BM25 混合检索，算力占用是原 pgvector 方案的一半；官方另称其基础设施成本下降 3 倍、吞吐提升 5 倍。这两条是厂商提供的单方数据，未附测试方法与基线。
  • 官方自陈的适用边界：文末注明 Databricks AI Search 是开箱即用的托管检索引擎，不想手工调优时更合适；Lakebase Search 适合希望运营数据与检索数据放在同一个数据库里的场景。GCP 版仍是 Beta。

行业影响

检索从”独立的第三个系统”降级为”数据库里的一种索引类型”，省掉的是一条 ETL 和两套权限模型。代价是召回不再是一个可以按需调高的旋钮，而是由量化与聚类决定的 97%，且这个数字由供应商在自己的基准上给出，pgvector 与 DiskANN 的对照只跑了单实例。

更值得留意的是计费模型的转向：按查询付费而非按数据量付费，把”存着但没人查的向量”从成本项里删掉了。这对 Agent 场景那种一次 workflow 触发数千次并发检索的突发形态非常划算，对稳定高 QPS 的常驻负载则未必更省——省下的那部分本质上是从”为容量付费”换成了”为使用付费”，两种负载的账单形状不同。

相关链接

Apache Polaris 1.8.0：把冲突与失败的措辞逐个改对

事件概述

Apache Polaris 于 2026 年 9 月 28 日发布 1.8.0，距 1.7.0（8 月 2 日）约两个月。这一版的 release notes 里大量条目是 renovate 机器人的依赖升级，真正有内容的部分集中在三类：提交冲突的语义、权限与认证的边界、以及一批 HTTP 状态码的纠正。语义模型（semantic model）拿到了独立的权限体系，是唯一称得上新增能力的一项。

对一个 Iceberg REST 目录来说，这些改动的分量不比新特性轻。多个引擎共写一张表时，引擎靠状态码决定是重试还是报错；状态码错了，重试逻辑就整个失效。

技术解析

  • 提交冲突从 400 变 409：并发提交撞上 stale sequence number 时，单表提交与 commitTransaction 都从 fatal 的 400 改为 retryable 的 409。进一步，base metadata 已 stale 的提交会在写新 metadata 文件之前就失败，每次冲突省掉一次对象存储的写入和一次删除，409 也更快回到客户端。
  • 权限输入去掉合成 ROOT：PolarisAuthorizer 的输入更直接地反映 intent-based 授权 SPI，资源目标与父路径不再包含 Polaris 内部的合成 ROOT 容器——catalog 目标的父路径变成空，LIST_CATALOGS 这类 root 作用域操作不再带合成的 ROOT 目标。
  • 多意图请求逐个评估：带多个 intent 的请求改为一次评估一个 intent。OPA 部署会观察到每个 intent 一次独立查询，依赖旧合并输入形状的 Rego 策略需要改写，其他 PolarisAuthorizer 实现同理。
  • JDBC 不再在 bootstrap 时建 schema：建 schema 属于 DBA 的特权操作。全新安装必须先 CREATE SCHEMA polaris_schema;（PostgreSQL 默认值）再跑 admin tool 的 bootstrap。已在跑的部署不受影响，但有一个陷阱：JDBC URL 里若已设 currentSchema，以前 Polaris 给每条查询都加上 POLARIS_SCHEMA 限定、这个设置被忽略，现在它决定 Polaris 读写哪个 schema，且驱动让 URL 里的值优先于默认配置——升级会把 Polaris 指向空 schema，再 bootstrap 会在另一处建出第二套空表。
  • 滚动升级期的 token exchange：凭据生成绑定之前签发的内部 JWT（缺 polaris-cv claim）不能再作为 token exchange 的 subject token，作为 bearer token 则在到期前仍有效。滚动升级期间旧节点仍在签发此类 token，在已升级节点上交换会以 invalid_grant 失败，客户端看到间歇性失败，直到最后一个旧节点下线后才转为一致拒绝。
  • 语义模型权限：列出、创建、读取、更新、删除各有独立特权，可按单个模型授予，也可在 namespace 或 catalog 范围授予，另有管理模型 grant 的独立控制项。
  • 服务端分页上限：新增 LIST_PAGINATION_MAX_PAGE_SIZE（可按 catalog 覆盖），默认 -1 即不限，设了才生效。超限请求被压到上限而不是拒绝，因为 Iceberg REST 规范把请求的 page size 当作上界。但这偏离规范：规范要求不带 pageToken 的请求返回完整结果且 next-page-token 为 null，现在会被截断并返回 continuation token，不跟随 continuation 的客户端只看到第一页。本地目录下该上限仅在 LIST_PAGINATION_ENABLED 为真时生效，联邦目录则始终生效。
  • 一批状态码纠正：畸形 pageToken 从 500 改 400（Invalid page token）；rename 表或视图缺 source/destination 从 500 改 400；policy、视图、通用表在解析后被删除、删除尚未持久化的情形从 500 改 404；服务端 JSON 处理失败改为返回标准 Iceberg 错误信封 {"error": {...}} 而不是扁平的 {"code","message"}。
  • GCS 桶根路径：表位置或 write.data.path/write.metadata.path 指向桶根且无尾斜杠（如 gs://bucket）时，解析出空路径曾在构建访问边界规则时触发 StringIndexOutOfBoundsException，现在按 AWS 集成的方式处理。
  • 一个默认配置下的 bug：DROP_WITH_PURGE_ENABLED 现在只作用于 Iceberg 表。此前它连视图删除时的元数据 purge 一并管，在该项默认 false 而 PURGE_VIEW_METADATA_ON_DROP 默认 true 的组合下，默认配置删任何视图都以 HTTP 403 失败。
  • 运维侧：异步文件清理新增 polaris.tasks.file-deletion-timeout（默认 1 小时），避免存储端点卡住时无限期占住任务执行线程；超时对当前 run 是终态而非立即重试。JDBC schema 升到 v6，修正 Postgres/CockroachDB 上的 idx_locations 索引，并为 CockroachDB 补齐三个索引——Polaris 没有自动 schema 迁移，存量部署要按 changelog 里给的 SQL 手工重建。
  • CLI：catalogs update 支持 --no-sts/--no-kms；新增 gcp 作为外部目录认证类型，可建 BigLake 一类目录而不用在命令行传 Google 凭据；新增全局 --page-size；新增 --storage-name。setup export 把 namespace 路径改写成层级列表、把 catalog 的 policies 改成列表，旧版 CLI 无法 apply 新格式。

行业影响

这一版几乎没加新能力，改的全是”边界上的措辞”：冲突该重试还是该失败、找不到该是 404 还是 500、请求畸形该是 400 还是 500、schema 归谁建。对一个被多个引擎共写的目录来说，这些措辞正是真正会出事的地方——引擎按状态码做事，状态码错了，重试逻辑就白写了。

代价集中在升级路径上：Rego 策略、setup export 文件、JDBC URL 里的 currentSchema、滚动升级期的 token exchange，四处都要人工介入，且 Polaris 明确说自己没有自动 schema 迁移。把语义改对，顺带把所有依赖旧措辞的东西一次性暴露出来，这是这类改动的常态，也是它必须写进升级说明而不只是 release notes 的原因。

相关链接

DuckDB 1.5.6 收尾，v2.0 alpha 在 Windows 上跑出 6 倍

事件概述

DuckDB 于 2026 年 9 月 28 日发布 v1.5.6，是 1.5（Variegata）线的第六个补丁版，内容包括缺陷修复、性能改进与安全补丁。官方博客按正确性、崩溃与内部错误、通用修复、杂项四组列出约二十个 PR 号。

真正的看点写在博客末尾的”抢先看”里。团队在 Windows 上测了 v2.0.0-dev（alpha43586）与 v1.5.6 的对比：Windows 11 25H2、128 GB 内存、12 核 AMD Ryzen AI 300（SMT 后 24 线程），TPC-H SF300，每个查询跑两次取热跑成绩。v1.5.6 总耗时 822 秒，v2.0.0-dev 是 129 秒，超过 6 倍。团队把收益归因于两项改动：切换到 clang-cl 编译器（PR #24391）与新分配器（PR #24036），并在同一段里写明”不要指望 6 倍能推广到所有负载”。v2.0.0 计划 10 月发布。

技术解析

  • 与湖仓读写直接相关的修复：Parquet VARIANT shredding 对 REQUIRED 字段与 element groups 的处理（#26162）；Parquet v2 中 NULL 填满一个 page 时的 value count 不匹配（#26027）；TIME_NS 的读写（#25728）；文件剪枝后 Hive 分区列上的 max（#25766）；GEOMETRY 行组剪枝在含 NULL 与空几何时的问题（#24845）。
  • 优化器与正确性：LIMIT 下推穿过带 OFFSET 的 volatile projection（#24240）；volatile group 上的过滤不下推穿过聚合（#24239）；UNNEST 下推（#24119）；UNION ALL 分支共享同一 join 子树时 common subplan elimination 给出错误结果（#25831）；Top-N window elimination 在 ORDER BY 表达式无列引用时保留 NULL（#24399）与可空排序表达式下的处理（#24551）；超长整数字面量静默截断为 HUGEINT（#25714）。
  • 崩溃与内部错误：Top-N 里 LIMIT 0 崩溃（#25103）；字典编码列上 TRY(url_decode) 段错误（#24427）；失败的 checkpoint 标记恢复（#24447）；WAL 恢复时先关闭主 WAL 句柄再 rename 覆盖（#25490）。
  • 杂项里两条值得记：新增 enable_optimistic_write 设置（#26102）；C API 符号版本化在客户端与扩展之间统一，全部 v1 API 稳定化（#24362）。另有打开 v2.0+ 数据库文件时报告真实存储版本（#25573）、错误信息里标识符一律加引号（#25214）。
  • 6 倍的口径：Windows 11 25H2、128 GB 内存、24 线程、TPC-H SF300、取热跑成绩，v1.5.6 的 822 秒对 v2.0.0-dev alpha43586 的 129 秒。官方未给 clang-cl 与新分配器各自的贡献拆分，也未给其他平台或数据集上的数字。

行业影响

一个补丁版本通常会把性能收益归到具体算子或格式上，这次的 6 倍来自编译器与内存分配器——收益不在查询层，在运行时层。对用户的意义是同一份 SQL 换个版本就快一个数量级，写法一行都不用改。

这类收益也最难迁移。clang-cl 与新分配器都是平台相关改动，Windows 上测出的倍数不该被当成 Linux 或 macOS 的预期。团队把”不要指望 6 倍能推广”写进正文，比给一个漂亮倍数更值得信任；这也说明这个数字的适用范围被限定得非常窄——它是某一台机器、某一个数据集、某一次热跑下的结果，不是一条可外推的规律。

相关链接

腾讯云 DataBuddy：把口径与权限收进平台语义层

事件概述

腾讯云于 2026 年 9 月 22 日通过新闻稿宣布 DataBuddy 正式发布，是继腾讯 CodeBuddy、WorkBuddy 之后的第三款助手类产品，定位为全托管、Agent 原生的 Data + AI 工作台。新闻稿给出四类 Agent 场景与三个核心底座，并称已在中国、泰国、韩国、印度尼西亚上线，欧洲、北美、南美在推进中。

需要先把时间线说清楚：DataBuddy 作为 WeData 平台内置的大数据智能体工作台，2026 年 5 月就已对外；9 月这次是作为独立产品形态的正式发布，四大场景中新增了数据科学一条。

技术解析

  • 三个内置 Agent：Engineering Agent 面向数据工程师，做数据接入、数仓分层设计、ETL 任务生成与编排、工作流调度、智能运维；Governance Agent 面向数据管理员，做敏感字段 AI 识别与分级、质量规则推荐、数仓质量诊断、元数据补全、根因诊断；Analysis Agent 面向分析师与业务人员，做自然语言问数、分析报告生成、指标波动归因、AI 看板与主动推送。
  • DIOps：把 DataOps（Studio 开发、Workflow 编排调度、CI/CD 发布、Ops 监控）、MLOps（特征管理、模型实验、模型管理、模型服务、AI 网关）、AIOps（AI 智能诊断、根因分析、自动修复）合进一套工程框架。官方称 60%+ 的问题由 AI 自愈，端到端模型部署周期从 30 天缩短到 7 天，特征复用率提升 1.5 倍——均为厂商口径。
  • Unity Semantics 的三类幻觉对应三类语义对象：指标歧义（同一个”营收”存在八种算法，Agent 随机选一个）用标准化的指标、实体与业务口径解决；JOIN 混乱（join key 靠猜，SQL 能跑但结果错）用语义模型固定关联关系；查询条件写错（“上季度""华东”映射到哪个字段靠猜）用本体建模定义维度绑定。官方给的两个区间是：无语义层时 NL2SQL 准确率 60%–70%，有完整语义层时 90%+。
  • TCCatalog 管四类资产：表目录（表、视图、函数）、Volume 目录（日志、图片、PDF、视频、音频）、模型目录（ML 模型与版本管理）、外部目录（外部数据源镜像，不经过 ETL 即可查询）。配套端到端血缘、全链路数据质量、敏感数据 AI 识别与分级、Catalog/Schema/Object 三级级联权限。
  • Agent 侧护栏：prompt 注入检测、OBO（On Behalf Of）权限强绑定、高危 SQL 拦截、“三要素”精确拦截，官方称覆盖 OWASP LLM Top 10 的风险面。
  • 三种接入形态：全栈数据湖（数据入 Lakehouse 存储，用 DataBuddy 计算与三个 Agent）、联邦分析（全栈数据湖加客户数据源统一管理，数据不动）、直接分析（通过语义层直连客户已有的 OLAP 引擎，只引入 Agent 智能分析能力）。数据源覆盖六类 47+ 种，含 Iceberg、Hudi、Delta Lake、StarRocks、ClickHouse、Doris 等。
  • 计价：CU 为统一计量单位（1 CU ≈ 1 vCPU + 4 GB），按量 ¥0.35/CU/小时起，包年包月 ¥150/CU/月起；Agent 订阅 ¥198/用户/月，另有五档算力包。
  • 需要打问号的数字：新闻稿中的 95.9% 分析准确率对 83.5% 纯 NL2SQL、模型部署 30 天→7 天、数据团队效率 5–10 倍，全部由腾讯云单方给出，未附评测集、基线口径与测试方法。官方产品文档里那组 60%–70% 对 90%+ 的区间比 95.9% 更接近可讨论的形式，但同样没有评测集。

行业影响

这与 Lakebase 是同一个动作的两个方向：Lakebase 把检索搬进数据库，DataBuddy 把”问数的口径”搬到平台层。两者的共同前提是让 Agent 少猜一次——一次是猜要不要外挂检索系统，一次是猜”营收”到底指哪个营收。

语义层这个位置正在变成必争之地：谁定义指标口径，谁就定义了 Agent 看到的业务现实。风险也在同一处。95.9% 与 83.5% 的差值是官方口径，没有评测集就无法复现；而一旦口径错了，错的不是一条 SQL，是一整层的答案。对国内团队来说，更有参考价值的是那部分可核对的工程信息——三种接入形态决定了要不要先搬数据，OBO 与高危 SQL 拦截决定了 Agent 能碰到什么，这两项比任何准确率数字都更早影响落地方式。

相关链接

编者评

本期四条来自四个层，动作一致：把边界上含糊的地方写成明确契约。Lakebase 把”检索由谁负责”写进数据库，换来的是召回从可调旋钮变成由量化与聚类决定的 97%，且这个数字只在自己的基准上成立；Polaris 把”冲突与失败由谁负责”写进状态码，换来的是 Rego 策略、导出文件、JDBC URL 与滚动升级期四处必须人工介入；DuckDB 把”快从哪来”写到编译器与分配器上，换来的是这个倍数只在 Windows 的 TPC-H SF300 上成立，团队自己把这句话写进正文；DataBuddy 把”口径由谁定义”写进平台语义层，换来的是 95.9% 这个数字只能信官方。四处都省掉了一次转译或一次猜测，四处也把原先可以含糊过去的那部分交了出去——交出去的方式是把它变成一个可验证的数字，而这个数字从现在起要自己负责。

几条本期未采用的线索，留给下期。Apache Iceberg 1.12.0 RC2 的投票到 9 月 29 日截止，截至发稿收到 Xuanwo、Maximilian Michels、huaxin gao、Anoop Johnson、Anurag Mantripragada、Andrei Tserakhau 等人的 +1（多为 non-binding）；期间出现过一次关于 Spark 4.2 模块的告警，随后由 huaxin gao 撤回报假警、Neelesh Salian 让投票继续。Amazon Redshift 的 Iceberg 写入系列在 9 月 28 日出到 Part 3，覆盖 ALTER TABLE 的 schema 与分区演进（ADD PARTITION FIELD、REPLACE PARTITION FIELD 做日分区到月分区的原子替换，新旧两套布局透明共存），以及在 S3 Tables 目录里建 Lake Formation 资源链接做跨引擎治理。中文源方面，阿里云与火山引擎在本扫描窗口内没有可核实的新的技术发布，火山引擎公开文档入口本期仍无法解析出发布记录正文，腾讯云 DataBuddy 是本窗口唯一够分量的中文条目。