datainfra前沿动态 · Vol.110

ClickHouse 26.10 把基于代价的连接重排优化器设为默认，非内连接第一次进入搜索空间，冲突检测器在 28 亿候选计划上验证零错误；Databricks 给 serverless 补齐三层成本控制，约束从机型上限换成身份、标签与速率限额；Apache RocketMQ 把 LiteTopic 并入主线，百万级 Agent 会话各自拥有独立通道，推理网关误拒率降到约十分之一；Materialize 用自管 buffer pool 接管操作系统 swap 的分页决策，upsert 源水合时间砍半、峰值内存降六成

本期聚焦粒度的细化：优化器把「非内连接不可重排」的类型级屏障换成逐规则的代数判断，成本治理从集群粒度换到计算对象与人，消息系统的隔离边界从 Topic 下沉到会话，流式引擎的冷热分页从内核收回引擎自己手里。四处都在为细一级的粒度付出新的机制成本。

DataInfra ClickHouse 查询优化器 CBO DPsub Databricks Serverless 成本治理 Apache RocketMQ LiteTopic 多智能体 Materialize Buffer Pool Upsert

数据基础设施本期的四个动作共用一个方向：把控制的粒度做细一级。ClickHouse 的查询优化器放弃了「非内连接一律不可重排」的类型级屏障，换成逐规则的代数性质判断，搜索空间在 7 表查询上扩大 11.5 倍，靠一个经过 28 亿候选计划验证的冲突检测器保证不出错；Databricks 承认 serverless 把机型上限这道旧的预算闸门拆掉之后，成本控制必须挂在计算对象、人身上，访问控制已 GA、速率限额进 Beta；Apache RocketMQ 把隔离边界从 Topic 下沉到会话，每个 AI 会话一条独立通道，索引层换成 RocksDB、调度层换成事件驱动的 Ready Set，已并入 master 主线；Materialize 把冷热分页的决策从内核 swap 收进引擎自己的 buffer pool，upsert 源水合时间从 206 分钟降到 108-113 分钟。四个系统都在为细粒度新建机制，也把各自的代价写在明处。

ClickHouse 26.10 默认启用 DPsub 优化器：非内连接第一次进入重排搜索空间

事件概述

ClickHouse 工程博客刊出长文《The new cost-based join optimizer with reordering support for non-inner joins》（Fisnik Kastrati，署期 10 月 28 日，页面发布元数据为 11 月 1 日），详解 26.10 版起设为默认的连接重排优化器。核心变化有两层：搜索算法从贪心换成 DPsub——一个穷举式动态规划算法，对不超过 12 张表的查询在现有代价模型下找到严格最优计划；搜索范围从内连接扩展到 LEFT、RIGHT、FULL 外连接与 SEMI、ANTI 连接，后者在过去是优化屏障（optimization barrier），被钉死在 SQL 书写的位置上。

这件事的背景是连接顺序对性能的决定性影响：n 张表的连接允许 n! 种线性顺序，一旦允许两个中间结果直接连接（bushy plan），join tree 数量变成 (2n-2)!/(n-1)!——10 张表是超过 176 亿棵树，12 张表约 28 万亿。贪心算法快但每步只看眼前，一个局部便宜的连接能把整棵计划树锁死在坏布局上。DPsub 按子集大小递增求解，对每个子集只解一次并复用答案，是经典的精确解法。

技术解析

  • 非内连接为什么一直是屏障：内连接满足交换律与结合律，任意重排结果不变。左外、semi、anti 连接不满足交换律，常常也不满足结合律——(A LEFT JOIN B) JOIN C ON B.x = C.x 里 A 中无匹配的行会拿到 B.x 为 NULL，随后被内连接丢弃；先算 B JOIN C 再左接 A，这些行就活了下来。两个计划结果不同，重排非法。
  • 冲突检测器的四条规则：检测器基于 SIGMOD 2013 论文《On the Correct and Complete Enumeration of the Core Search Space》实现，用四个性质判定相邻两个连接能否交换或重组：comm（单算子交换律）、assoc（重组）、l-asscom、r-asscom，后三个存成按算子对索引的矩阵，判定结果还取决于谓词是否拒绝 NULL（assoc(⟕, ⟕) 只在 NULL 拒绝条件下成立）。整个判定是几次位掩码操作，对枚举开销几乎无感。
  • 验证规模：正确性靠穷举对拍——对 3 到 7 张表生成全部初始 join tree（小算子集 30 到 11,010 棵，大算子集含 full/semi/anti 最多 72,320 棵），枚举各自完整的 core search space，用三个独立途径（在产检测器、参考实现、带 NULL 随机数据上的真实执行）比对；累计 9 万多棵 join tree、280 万个 core plan，非法计划 0、遗漏计划 0、执行失败 0。差分模糊测试另跑 1,200 条混合六种连接类型的随机查询，0 次结果不一致。
  • 收益数字：semi join 下推的例子里，最大中间结果从 503,768,186 行降到 1,015,092 行（约 496 倍）；3 张表各 300 万行、tiny 表 100 个 key 的实测，贪心 0.133s 对 DPsub 0.035s（关掉 runtime join filters，3.8 倍），开着 filters 时 1.2 倍——runtime join filters 本身能挽回部分坏顺序，新计划不依赖它。TPC 基准上 TPC-H Q2 降 55%、TPC-DS Q73 降 45%、TPC-H Q5 降 44%。
  • 开关与边界：query_plan_optimize_join_order_algorithm = 'dpsub,greedy'（贪心作为大查询回退），query_plan_optimize_join_order_conflict_detector = 'c' 可关。超过 12 张表退回贪心；query_plan_optimize_join_order_limit 可上调到 12。

行业影响

连接重排是数据库优化器最老的问题之一，ClickHouse 这篇的价值不在发明——DPsub 与冲突检测器都是教科书与论文里的成熟件——在于把「带形式化正确性保证的非内连接重排」做到了默认开启、验证规模公开可查的程度。对 OLAP 引擎的使用者来说，semi/anti 连接大量出现在 EXISTS/NOT EXISTS 语义的报表与漏斗查询里，这类查询过去只能靠手工改写顺序或加过滤条件自救。工程方法论上值得注意的一点是验证方式：论文级性质用论文级穷举对拍来背书，280 万个计划零非法零遗漏，这种「每个默认开启的优化都必须有正确性账本」的做法，正在成为 OLAP 引擎竞争的一个新维度。

相关链接

Databricks 给 serverless 补齐三层成本控制：约束从机型上限换成身份、标签与限额

事件概述

10 月 29 日，Databricks 发布《Smarter cost controls for serverless》（Piyush Singh、Vijay Raja），把 serverless 计算的成本治理框架一次性摆上台面。文章先给出规模注脚：Databricks 自家 serverless 计算用量过去一年增长超过 3 倍，数千客户在其上跑关键业务 notebook、作业与管道。平台团队随之而来的问题只有一个——serverless 拆掉了机型、节点数、自动伸缩上限这些旧的预算闸门，成本约束要挂到哪里去。

Databricks 的回答是把成本控制上移一层：从挂在机器上，改为挂在工作负载与人身上。具体拆成三个目标——归因（每个 DBU 属于哪个团队、项目、用户）、准入（谁可以运行 serverless）、限额（一个工作负载或团队能花多快）。三个目标对应三套机制，成熟度不一：访问控制已 GA，标签归因与速率限额在 Beta，团队共享预算在路线图上。

技术解析

  • 归因：标签跟着计算对象走。给 serverless 计算对象打一次标签，其上运行的 workload 产生的每个 DBU 都带着标签进账单；所有 serverless DBU 落入 system.billing.usage 系统表，可按用户、产品、标签切分。新增 serverless_compute_id 列把归因细化到计算对象粒度，「按计算对象看成本」与「按团队看成本」一样容易。标签归因目前 Beta，可观测性（系统表、成本面板）已 GA。
  • 准入：entitlement 模型，SQL warehouse 的既视感。每个工作区默认有两个 serverless 计算对象——Default Serverless Interactive Compute（notebook 与 Databricks Connect）与 Default Serverless Automated Compute（作业与 Spark Declarative Pipelines），权限就是仓库时代的那两个：Can Use、Can Manage。默认所有用户有 Can Use，管理员收回 All Users、换成特定组之后，组外用户在 notebook 计算选择器里看到 serverless 置灰，已在跑的负载不受打断。已 GA。
  • 限额：T 恤尺码作为消费上界。速率限额（Beta）落在与准入同一个计算对象上，按 S/M/L/XL 档位限制作业或管道「能花多快」。关键澄清：对 notebook 与作业，尺码是最大自动伸缩天花板而非固定规格——XL 档的作业实际只需要 M 时就分配 M。管理员建自定义计算对象、按团队共享，各团队各有限额，这正是集群策略模式在 serverless 上的移植。交互式负载的共享预算 coming soon：单会话上限护不住团队预算，方向是组级共享限额加会话级护栏。
  • 监控只是事后。系统表上的预算告警、成本面板、SQL 告警都属于「第二天早上告诉你昨天贵了」，文章明确把主动控制的存在理由建立在这个缺口上。

行业影响

这篇公告标志着 serverless 叙事进入第二阶段。第一阶段卖的是「不用管机器」，第二阶段要回答的是「不管机器之后凭什么管预算」。Databricks 给出的答案——归因靠标签、准入靠 entitlement、限额靠对象级速率上限——本质上把 FinOps 的控制面从基础设施团队手里交给了平台治理团队，控制粒度从集群变成计算对象加身份。对正在做平台工程的企业，这里有一个直接的对照实验机会：经典计算上靠集群策略、标签强制执行建立的成本纪律，能否无损迁移到 serverless；迁移不了的部分（机型上限这类物理约束）用什么补。Databricks 的答案是限额与共享预算，这两个都还不是 GA。

相关链接

RocketMQ LiteTopic 并入主线：把会话边界从应用代码搬进消息系统

事件概述

阿里云云原生社区 10 月 29 日刊出《Apache RocketMQ’s Evolution for AI: LiteTopic Powers Million-Scale Multi-Agent Session Collaboration》（李周，改编自 Apache 2026 演讲）。LiteTopic 是 RocketMQ 面向 AI 负载的轻量消息模型，核心思想是把每个 AI 会话映射为一条独立通道，替代「所有会话共享一个业务 Topic」的传统结构。文章确认 LiteTopic 已并入 Apache RocketMQ master 分支成为主线能力，配套的 RocketMQ-A2A 论文被 FSE 2026 接收，另获 CAICT 2025 OSCAR「开源 + AI」峰会案例奖与 InfoQ AI 开源之星奖。

两个已在阿里云内部生产的案例给出动机：编码智能体 Qoder Cloud Agents 的单个任务跑数小时到数天；Model Studio 推理网关要在数百万租户间调度请求。两者形态迥异，对消息系统的要求却一致——会话状态、任务交接、失败恢复应该由基础设施承载，而不是在每个应用里重写一遍。

技术解析

  • 传统事件驱动模型的三处断裂：积压速率（单消息处理从毫秒级涨到分钟级，队列堆积速度换了一个量级）；队头阻塞（一条消息就是某个用户某个会话，长运行是任务属性而非故障，共享队列里它挡住后面所有会话，传统 Topic 的创建与元数据成本又让「一会话一 Topic」不可行）；推理重算成本（中间结果丢了就要重调模型，消息与事件的持久性直接挂钩 GPU 成本）。
  • 两级结构与索引层：LiteTopic 挂在 Parent Topic 下，Parent 是命名空间与控制面。索引层把文件式 ConsumeQueue 换成 RocksDB KV 引擎（Key 为 Topic + QueueID + Offset，Value 是 CommitLog 物理偏移），百万通道共享一个 KV store，单次查找 O(1)，元数据不再随通道数膨胀——这是百万通道共存的前提。存储内核（顺序写、零拷贝、主从复制、刷盘策略）不动。
  • Ready Set 换掉全量轮询：长轮询下 broker 周期性扫描相关队列，百万队列时 CPU 大量浪费在空扫描上。LiteTopic 用 Lite Subscription Set 存订阅、Ready Set 聚合真正有消息待投递的通道，消息写入触发事件匹配，消费者只从 Ready Set 取活——类比 epoll 对 select 的改进，调度成本从 O(总订阅数) 降到 O(活跃数)。百万会话中给定时间窗内活跃通道往往只有数千。
  • 四个面向应用的能力：首条消息到达时通道自动创建（不用预注册）；空闲通道按 TTL 自动回收（只创建不回收，历史会话元数据会无限累积）；消费者组内实例可订阅不同 LiteTopic 子集（会话级隔离）；消费者返回 Suspend(N) 只暂停当前通道 N 毫秒，线程立刻回池服务其他会话——替代 sleep 式限流，GPU 成本主导的场景里这直接决定利用率。
  • 两个生产案例：Qoder 用双 Parent Topic（请求/响应各一）承载 brain（Agent Runtime）与 hands（Sandbox Worker 池）的双向异步通信，每会话每方向一条 LiteTopic；消息里只走事实与事件，大对象进存储、进度以 Checkpoint 为权威源，实例重启与会话迁移不会扭曲进度；多智能体并行用 Mailbox 加 Barrier 做确定性派发与汇合，中止命令走独立控制通道。Model Studio 网关把限流从「允许或拒绝」的二值判断改造成按 user + model 维度的漏桶阵列——桶按需创建、TTL 回收，消费者组匀速消费并对单个组合返回 Suspend，误拒率降到约原来的十分之一，限流精度到毫秒级，已服务数百万租户。

行业影响

LiteTopic 的定位值得字斟句酌：它不是给消息系统加 AI 特性，而是承认 AI 负载把「会话」变成了与「队列」同等级的一等实体。传统模型里会话边界由应用层自己维护（一个消费者组、一套状态存储、一套恢复逻辑），LiteTopic 把这个边界下沉到 broker 的索引与调度层，应用只多一个 setLiteTopic(sessionId) 标签。对比本期 Databricks 把治理粒度从集群换到计算对象，两件事的形状一致：控制面在向「负载的自然语义单元」收敛。对消息系统的竞争格局而言，Kafka 生态近年靠存算分离与消息湖化回应数据面成本，RocketMQ 这条线押的是控制面——会话粒度的隔离、顺序与回收。MCP 传输层的探索已在进行，方向是 agent-to-tool 通信复用同一套传输。

相关链接

Materialize 用自管 buffer pool 接管 swap：upsert 源水合时间砍半、峰值内存降六成

事件概述

Materialize v26.48.2（Cloud 侧 10 月 29 日随 v26.48.0 推送，自管版 10 月 30 日发布）落了一项直接改写资源模型的改进：upsert source 的水合（hydration）路径改用引擎自管的 buffer pool，替代此前交给操作系统 swap 的做法，构建期数据加 LZ4 压缩。Materialize 自 v26.1.0 起按周发布，这属于机制层面的变更而非常规周更。

官方基准：单分区 Kafka topic、约 15 亿条消息（约 100 GB）、9.56 亿个不同 key、单条记录约 100 字节，跑在 98 GB 内存、586 GB 磁盘的 M.1-1.5xlarge 集群上。水合时间（从 CREATE SOURCE 到全部 key 建好索引并追平 topic）四次实测从 206 分钟降到 108-113 分钟；内存加磁盘的峰值用量从 542 GiB 降到 183-208 GiB。真实客户负载上水合时间改善 49%-88%，内存用量改善 13%-64%。

技术解析

  • 为什么不用 swap：机制细节在 9 月 29 日的博客《Materialize, Out-of-Core: Replacing Swap with a Buffer Pool》里。Materialize 的数据结构既要扛高吞吐扫描，也要扛低延迟点查，为此长期按主存假设设计；物理内存贵，客户宁愿用固定预算换大得多的工作集。关键的不对称在于：DRAM 访问约 100ns，本地 NVMe 随机读几十微秒（慢几百倍），带宽却是单位数 GB/s 对几十 GB/s（只差约 10 倍）——磁盘延迟对随机指针追踪是灾难，对大块顺序扫描只是不便。控制哪些字节落盘、以什么表示读回，内核 swap 两个都不给你。
  • buffer pool 换来的控制权：引擎自己管理冷热分页，热数据留在内存，顺序性工作从磁盘直供；配合构建期数据的 LZ4 压缩，落盘字节数先降一层。这套机制与 9 月博客的设计一脉相承，v26.48 把它落到了 upsert source 的水合路径上。
  • 适用范围：改进针对会溢出到磁盘的 upsert source（Materialize Cloud 侧先行）；不溢出的负载感受不到差异。基准里的集群内存 98 GB 而峰值用量曾达 542 GiB，说明这条路径服务的是工作集远超内存的重度管道。

行业影响

「让最懂数据访问模式的那一层做分页决策」是这个改进的全部理由，它和云数据库圈把冷热分层决策收进缓冲管理器（阿里云 CloudJump 系列的路线）是同一个判断在不同系统里的两次落地。对增量视图维护（IVM）这类新兴品类，内存预算是商业化绕不开的坎——工作集超内存就把延迟让给内核 swap，等于把产品体验交给了操作系统调度器。Materialize 把这层收回来之后，「固定预算换大工作集」才成为一个可以承诺的产品参数。代价也明确：自管 buffer pool 是一块不小的工程面，周更节奏下这类机制变更的回归风险要靠基准数字兜底，这次官方把四次实测的区间（108-113 分钟）而非单点值写进发布说明，是个诚实的好习惯。

相关链接

编者评

本期四个主题共用一个骨架：控制的粒度做细一级，机制成本跟着涨一级。ClickHouse 把「非内连接不可重排」的类型级判断细化成逐规则的代数判定，换来的是必须维护一张带 NULL 语义的规则矩阵并用 280 万个计划的对拍背书；Databricks 把预算约束从机型粒度换到计算对象加身份粒度，治理模型要重学一遍；RocketMQ 把隔离与顺序的边界从 Topic 细到会话，索引层与调度层整个换掉；Materialize 把分页决策从内核的页细化到引擎懂访问模式的 buffer pool。值得注意的是四条路径对「谁来兜底细粒度的正确性」的不同答案：优化器靠穷举验证，消息系统靠存储内核不动只动索引，流引擎靠公开的基准区间——细粒度不是免费的，各家的付费方式值得横向收藏。本期正值 11 月第一个周末，英文大厂博客普遍静默（Databricks feed 止于 10 月 31 日 Lakebase CI/CD 一文，Vol.109 已报；AWS 止于 10 月 30 日；GCP 抓到的两条转发均为 9 月旧文），主力选题来自上期标记的备选池。中文源方面，阿里云 10 月 29 日还刊出了 9 月数据库新特性月度盘点——五个数据库服务整体进入巴西圣保罗区域，PolarDB 增加 TTL 自动归档与不可变备份，RDS PostgreSQL 内核带来向量索引量化与基于 DuckDB 的慢 SQL 分析——作为组合拳的注脚一并记录。开源版本快照：Doris 打出 4.2.0-rc02、Arrow 进入 26.0.1-rc1，均未 GA。