datainfra前沿动态 · Vol.73

ClickHouse 26.9 秋季版发布；RisingWave v3.1.0 打版；DuckDB-Wasm 支持 OPFS 持久化；Streamhouse 工作组成立

本期聚焦引擎与运行期的边界内移：ClickHouse 26.9 把 Iceberg 增量复制、Prometheus 接口与 Trino 方言收进引擎，RisingWave v3.1.0 让 sink 换源与并行度调整在流作业运行期完成，DuckDB-Wasm 借 OPFS 把数据库文件落进浏览器，五家流式厂商则为 Streamhouse 给出一份带商标承诺的公开定义。

DataInfra ClickHouse RisingWave DuckDB Iceberg Delta Lake 流处理 Lakehouse

本期四条指向同一个动作：把原本要跨一个系统才能完成的事，搬进自己这一层完成。ClickHouse 26.9 在稳定版打版的同一周，把 Iceberg 增量复制、Prometheus HTTP 接口和 Trino 方言收进引擎；RisingWave v3.1.0 让 sink 换源与并行度调整在流作业运行期完成，代价是五条破坏性变更；DuckDB-Wasm 借 OPFS 把数据库文件落进浏览器沙箱，代价是持久性降级为缓存；Aiven、Confluent、Redpanda、StreamNative 与 Ververica 五家则为 Streamhouse 给出一份带商标承诺的公开定义。四次收拢之后，原来那个系统不再是对等协作者，而变成被兼容的对象。

ClickHouse 26.9：引擎把外部系统的活接了进来

事件概述

ClickHouse 26.9 的稳定构建 v26.9.1.1629-stable 于 2026 年 9 月 21 日打版（UTC 21:25）。官方 Release Call 材料给这一版标了三个数字——56 个新特性、135 项性能优化、464 个缺陷修复，并称之为「Autumn Release 26.9」。同日还有 v26.8.10.6-lts 的补丁构建。

改动面铺得很宽，但有一半以上落在两个方向：一是把 Iceberg / Delta Lake / Prometheus / Trino 这些外部系统的接口做成引擎内部的一等公民，二是不改查询语义、只改「读多少、走几趟」的执行层优化。官方 changelog 页与 GitHub release 页均可查。

技术解析

  • 增量刷新的可刷新物化视图：REFRESH EVERY 1 HOUR APPEND INCREMENTAL 让物化视图每次只处理上次刷新以来源表新增的行。源表需开 enable_block_number_column 与 enable_block_offset_column，游标就是源表的 block number。官方给的头号用例是把 MergeTree 表复制进 Iceberg，并写明往 Iceberg 目标的追加是精确一次的——游标写在快照里。
  • Iceberg manifest 并行解码：查询规划要遍历 manifest（取回、解 Avro、按分区与 min/max 剪枝），这一步原先是串行的，26.8 只补了预取。26.9 改成并发解码，存活条目流式进一个有背压的有界队列。PR 给的例子：18 份 manifest、113 MB、约 7.5 万条目，串行 8.45 秒，4 线程 2.55 秒，16 线程 1.68 秒；并发度由 iceberg_manifest_decode_concurrency 控制，默认 4。另加一条：manifest list 里的 lower_bound / upper_bound / contains_null 现在能在打开任何 manifest 之前先剪掉整份 manifest。
  • Delta Lake 可以直接建表：打开 allow_delta_lake_writes 与 allow_delta_lake_create_table 后，ENGINE = DeltaLake(...) 可以 CREATE TABLE 并插入，写出的 _delta_log 里 commitInfo.operation 记为 CREATE TABLE、engineInfo 记为 ClickHouse。也能挂到已有的 _delta_log 或注册进 Unity catalog。
  • DISTINCT 落盘：3 亿 distinct key 的实测，纯内存 12.9 GB / 12.3 秒；设 1 GB 起落盘后为 1.14 GB / 12.1 秒——速度基本不变，内存降到约十一分之一，默认开启。
  • 聚合走列统计：26.4 起默认记录的每 part 精确 min/max，现在 min / max / count 直接读它，官方示例从 26.8 的 8–24 ms 降到 2 ms。缺统计的 part 仍按原路径读再合并。
  • 原生协议收尾合并：26.8 里 SELECT 1 的服务端回包是 7 个 TCP 包，26.9 合成 2 个。空闲后 Linux 会收缩拥塞窗口，超出窗口的突发要等一次 ACK；在 30 ms 链路上，这一处曾给空闲客户端带来约 2 倍延迟。
  • ARM 一批修复：memcpy 小拷贝辅助函数在 AArch64 上被编译成 libc memcpy 调用（x86 早在 2024 年修过），现已内联；WHERE 过滤改用 NEON 寄存器累加。官方自己给了两组量级不同的数字：Graviton3 单线程对 1 亿条短字符串做 DISTINCT 从 12.4 秒降到 7.6 秒；「最高 15 倍」出自 PR #119555 的微基准，PR #117353 在 Neoverse-V2 上 4–16 字节实测为 1.34–1.36 倍。页面上还写着 NVIDIA Grace 未测（NOT done），理由是手上没有机器。
  • 强制 analyzer：自 26.9 起 analyzer 是强制的，enable_analyzer 作废，设为 0 会被拒绝，24.3 之前的查询分析路径不再支持。这是升级前最该先核对的一项。
  • S3Queue 的第三种模式：mode = 'exclusive' 把已处理文件记在本机内存里，省掉每文件一次 Keeper 往返，适合一个 bucket 只归一台服务器摄取的场合。官方附了诚实备注：26.9.1.1592 里 CREATE 仍要求 server config 里有 Zookeeper 段（表注册与元数据还是进一次 Keeper），省掉的只是每文件的处理状态。
  • 作用域临时凭据：CREATE TOKEN VALID FOR INTERVAL 7 DAY GRANTS (SELECT ON default.sales) 生成的令牌只在现有授权子集内生效，在 query_log 里仍显示为原用户，用户被删即失效，授权收窄时令牌一并收窄。
  • 方言扩展：PromQL 从实验性进 private preview，官方称覆盖 85% 以上 PromQL 且语义与 Prometheus 一致，26.9 补了 absent、count_values、*_over_time、predict_linear；Trino 方言仍是实验性，走 token 级语法翻译加约 340 个函数的 AST 映射；KQL 方言重写了词法、语法与 AST 翻译。

行业影响

ClickHouse 在把「外部系统的接口」当成自己的功能面来做：Iceberg 是一个 ENGINE 而非需要外部调度任务的目标表，Prometheus 是一个 HTTP handler 而非要单独部署的组件，Trino 是一种 dialect 而非要迁移的集群。对使用者，省掉的是一层胶水；代价是兼容深度由 ClickHouse 自己定义——Trino 方言只映射了约 340 个函数且标注实验性，KQL 重写前曾注册 28 个什么都不做的函数。这类「部分兼容 + 标注成熟度」的组合会变成新的评估成本，选型时要按方言逐项核，不能按名字整体采信。

列统计、manifest 剪枝、原生协议收包、ARM memcpy 这一组优化有一个共通点：都不改查询语义，只改「读多少、走几趟」。这类优化的可迁移性最强，也能解释为什么一个季度版本能凑出 135 项性能优化——绝大多数是局部替换，不是架构改动。

相关链接

RisingWave v3.1.0：把运行期的调整权收进引擎，代价是五条破坏性变更

事件概述

RisingWave v3.1.0 的 GitHub 标签于 2026 年 9 月 21 日 11:00 UTC 打版。需要提醒的是，官方文档站的发布说明里 v3.1.0 一栏仍标着「Upcoming」，没有给出正式发布日期，升级前应以官方公告为准。

这一版的主线由官方文档概括为四项：新增 VARIANT 类型、周期性刷新的物化视图、分区间隙填充，以及对 backfill 与 sink 操作更多的控制。真正影响现有部署的是最后一项附带的一组破坏性变更。

技术解析

  • VARIANT 类型：配套 to_variant、variant_get、try_variant_get、variant_typeof，可与 varchar、jsonb 互相转换。官方写明 VARIANT 不能作键，也不能用于分组、排序或连接条件。
  • 周期性刷新的物化视图：通过 refresh.interval.sec 让物化视图消费上游快照并按间隔刷新。限制是这类视图需要 snapshot backfill，且不能有下游流作业。
  • 分区间隙填充：GAP_FILL(..., PARTITION_BY(...)) 为每个分区独立补点，支持 EMIT ON WINDOW CLOSE。窗口关闭的实现会保留分区列，并为每个分区分别保留前一行状态。
  • REPLACE SINK ... FROM ...：在 cut-over barrier 处切换现有 sink，不回填历史行。限制：不支持 exactly-once sink、sink-into-table 与 AS query 替换；旧 sink 的权限不会转移。
  • 创建中也能改：流作业还在创建时，就可以改运行时配置、并行度、resource group 与速率限制。重命名这类元数据变更仍需等创建完成。
  • 五条破坏性变更：① WebSocket ingestion 现在需要含 WebSocketIngest 的许可证，否则新建或重连返回 HTTP 403（HTTP webhook ingestion 不受影响）；② 移除了用 mysql-cdc / postgres-cdc / sqlserver-cdc 直连建 CDC 表的方式，必须先建共享 CDC source 再 CREATE TABLE ... FROM source TABLE（MongoDB CDC 不受影响）；③ Parquet 的 VARIANT 列从 struct<metadata bytea, value bytea> 改为原生 variant，仍按旧 struct 声明的列会读出 NULL，file_scan() 也推断为 variant；④ 弃用 no-shuffle backfill，改用 snapshot 或 locality backfill；⑤ release builds 默认禁用 posix_fs 与 fs 本地文件系统连接器，要用得开 frontend.unsafe_enable_local_fs_connector。

行业影响

把「停下来重做」换成「在线改」，是流式系统这一年最一致的方向。Databricks 在 9 月中旬为 Structured Streaming 加了按需状态重分区（本专栏 Vol.67 报过），RisingWave 这次落的是 sink 换源与参数调整，两者的账也很像：能力给了，边界写进文档。RisingWave 这版的边界尤其具体——五条破坏性变更里有三条会直接中断现有部署（WebSocket 403、CDC 建表方式、Parquet VARIANT），另两条改变默认行为。升级前逐条核对，比看特性清单重要。

相关链接

DuckDB-Wasm：数据库文件进了浏览器，持久性却降级为缓存

事件概述

DuckDB 官方博客 2026 年 9 月 18 日发文，说明 DuckDB-Wasm 如何用浏览器的 Origin Private File System（OPFS）打开一个持久化的数据库文件。OPFS 是 per-origin 的沙箱文件系统，支持随机读写，现代浏览器自 2023 年 3 月起普遍可用。

DuckDB-Wasm 在 2021 年上线时不能持久化，数据全在 Wasm 堆里，关标签页即消失；想留数据得把表序列化成 Parquet、塞进 IndexedDB、下次加载再注册回来。OPFS 把这件事从应用层搬进了引擎。

技术解析

  • 用法：db.open({ path: 'opfs://analytics.duckdb', accessMode: READ_WRITE })。opfs:// 前缀让文件系统层把路径解析到 origin 的私有文件系统，而不是默认的内存 Emscripten 文件系统。生成的是标准 .duckdb 文件加 .wal，从 OPFS 里取出来用 CLI 或 Python 客户端直接能开。
  • 一个必须知道的版本坑：官方明确写，撰写时 npm 上标为 latest 的 1.33.1-dev57.0 会创建 OPFS 文件但从不写入，原因是路径被规范化成 opfs:/analytics.duckdb（单斜杠），与 OPFS handle 不再匹配。要么钉 1.32.0，要么用 next 标签（1.33.1-dev64.0 及以后）。1.33.1-dev64.0 起还会多出 .wal.checkpoint 与 .wal.recovery 两个辅助文件。
  • 持久性语义：与本地 DuckDB 一致，先写 WAL，checkpoint 时落到主文件，阈值默认 16 MB。浏览器标签页很少干净关闭（用户关页、手机杀后台、合盖都不会可靠执行收尾代码），官方给的两条规则是「不能丢的写之后调 CHECKPOINT」和「按批 checkpoint 而不是按语句」；不想跟踪批次就 SET checkpoint_threshold = '0KB'，每条语句后落盘，代价是写吞吐。
  • 两种文件注册模式：opfs: { fileHandling: 'auto' } 会扫描语句里的 'opfs://...' 字面量并自动注册、用完释放；默认是手动注册，代码多但避免了每条语句重新获取一次 OPFS access handle。一个文件一次只能被一个 handle 持有，官方建议用完 db.dropFile()。
  • 导出：DuckDB-Wasm 自己还不能把文件搬进搬出 OPFS，需走浏览器 API（navigator.storage.getDirectory() 拿到 File 再 URL.createObjectURL），或者用 SQL 导出成 Parquet。反向也成立：可以把预建好的 .duckdb 随应用分发，首次启动拷进 OPFS，用户开局即有数据。
  • 限制：OPFS 是浏览器存储而非硬保证，磁盘紧张或长期未访问时会被驱逐，用户也能在站点设置里清掉。官方的定性是「把它当成本地缓存，不是唯一副本」，真正要留的底应放在 DuckLake catalog 或 s3:// 上。SQL 里的重命名只在两个已注册的 OPFS 文件之间有效。

行业影响

local-first 分析应用少掉了一个服务端：不用 IndexedDB 包装，不用自己做序列化，也不用起一个后端。代价是持久性的责任从数据库引擎转移到了应用——checkpoint 时机、版本钉法、导出通道、被驱逐后的恢复，这四件事都得由应用作者接住。版本坑尤其值得记：它出现在 npm 的 latest 标签上，而不是某个边缘构建上，凡是按默认安装走的应用都会踩到。

相关链接

Streamhouse 工作组：五家厂商给一个架构名词配了商标承诺

事件概述

2026 年 9 月 15 日，Aiven、Confluent、Redpanda、StreamNative 与 Ververica 联合宣布成立 Streamhouse Working Group，并发布一份厂商中立的 Streamhouse 定义。配套发布的还有一份有约束力的商标承诺。发起方覆盖的商业形态相当分散——托管服务、Kafka 商业版、自研引擎的 Kafka 兼容实现、Pulsar 商业版，以及 Flink 商业版。

技术解析

  • 三个定义属性：real-time（数据随业务事件持续更新，而非靠周期性批处理刷新）、production-native（按生产服务水平构建，因为关键应用、分析与 agent 持续依赖它）、decentralized（在数据已经在的地方对接，而不是先把全企业数据归拢到一个系统）。
  • 商标承诺：Streamhouse 这个词由 Ververica 提出。承诺规定任何人可以永久、免费地用这个名字描述、讨论、实现、销售或分析符合该定义的架构，无需许可、通知、注册或费用。
  • 治理形式：定义会以带版本的公开仓库维护，工作组负责推进相关技术、开放标准与互操作实践，并邀请客户、从业者与其他厂商参与。定义正文与商标承诺分别放在 streamhouse.com 的 /definition 与 /trademark 页，GitHub 上已有 streamhouse 组织。
  • 与 Lakehouse 的关系：官方定位是共存。Lakehouse 解决的是大规模历史数据的存储与分析，Streamhouse 解决的是应用与 agent 在事件发生时运行业务，两者通过开放格式交换数据。官方把 CDC、事件流、流处理、开放表格式、catalog 与低延迟服务列为该架构的典型组件，并强调没有一个单独的项目或厂商产品线能独自构成一个 Streamhouse。
  • 当前的交付物边界：这一批发布的是定义与商标承诺，没有规范文本、没有一致性测试套件、没有基准。

行业影响

五家互为竞争对手的流式厂商能为同一个名词签一份免费使用承诺，说明他们都判断这个品类的价值在「被共同做大」而不是「被一家占住」——这也是 AWS 收购 DuckLabs 之后开放表格式一侧已经发生的格局在流式一侧的回声。对使用者而言，眼下能拿到的只有一份定义：把它当选型依据还太早，把它当讨论实时架构的公共词汇已经够用。真正值得盯的是后续有没有出现规范与互操作测试，那才是这个工作组能否从市场动作变成技术动作的分水岭。

相关链接

编者评

四条放在一起看，是一次相当一致的边界内移：ClickHouse 把 Iceberg、Prometheus、Trino 从「要对接的外部系统」变成引擎里的一个 ENGINE、一个 HTTP handler、一种 dialect；RisingWave 把 sink 换源与并行度调整从「停机窗口里的操作」变成运行期的一条 DDL；DuckDB-Wasm 把数据库文件从服务端搬进浏览器沙箱；Streamhouse 工作组把一个架构名词从各家自己的市场话术搬进一份可公开引用、带商标承诺的定义。搬进来之后，原来那个系统不再是对等协作者，而变成一个被兼容的对象，兼容到什么深度由搬的这一方决定，也就由这一方负责——ClickHouse 的 Trino 方言只映射约 340 个函数且标注实验性，DuckDB 的持久化依赖应用自己掌握 checkpoint 时机，RisingWave 给出能力也列出五条会中断现有部署的变更，Streamhouse 目前只有定义没有规范。代价没有变小，只是从「跨系统协作的摩擦」变成了「写进文档的能力边界」，而后者至少是可以逐条核对的。本期没有中文厂商的产品级更新：阿里云社区站 9 月 21—22 日的新帖集中在模型与 API 网关，火山引擎与墨天轮的可见更新停在 9 月中旬，「EMR Serverless StarRocks 与 DLF 直连」一文的技术细节无法从官方页面核实发布时间，按不可核验处理未采用。还有一条留作下期线索：Apache Iceberg 1.12.0-rc1 于 9 月 22 日 00:05 UTC 打版，Vol.72 已报过 rc0，等官方 changelog 出来再展开。