ClickHouse 25.2 版本发布说明

本文字数：7668；估计阅读时间：20 分钟

作者： ClickHouse Team

本文在公众号【ClickHouseInc】首发

新的一月，新版本如期而至！

发布概要

ClickHouse 25.2 版本正式发布，本次更新带来了12项全新功能🐣、15项性能优化🥚、72个bug修复🌷

本次更新提升了并行哈希连接（parallel hash join）性能，支持 Parquet 布隆过滤器（bloom filter）写入，增强了查询的传递条件推理（transitive condition inference），新增数据库备份引擎（backup database engine），集成了 delta rust 内核（delta rust kernel），还有更多改进等你来体验！

新贡献者

特别欢迎所有 25.2 版本的新贡献者！ClickHouse 社区的不断壮大令人欣喜，我们衷心感谢每一位贡献者，正是你们的努力让 ClickHouse 变得更加出色。

以下是本次发布的新贡献者名单：

Artem Yurov, Gamezardashvili George, Garrett Thomas, Ivan Nesterov, Jesse Grodman, Jony Mohajan, Juan A. Pedreira, Julian Meyers, Kai Zhu, Manish Gill, Michael Anastasakis, Olli Draese, Pete Hampton, RinChanNOWWW, Sameer Tamsekar, Sante Allegrini, Sergey, Vladimir Zhirov, Yutong Xiao, heymind, jonymohajanGmail, mkalfon, ollidraese

更快的并行哈希连接

贡献者：Nikita Taranov

每次新版本发布，我们都会对 join 性能进行底层优化。在上一个版本中，我们优化了并行哈希连接的查询（probe）阶段。而这次，我们进一步优化了构建（build）阶段，消除了不必要的 CPU 线程争用，使其运行更加高效、无阻塞。

在上一次发布文章中，我们详细介绍了并行哈希连接算法的构建和查询阶段。简单回顾一下，在构建阶段，N 个线程会并行地向 N 个哈希表插入右表数据，按数据块（row-block）逐步处理。构建完成后，查询阶段开始，N 个并发线程会遍历左表的行，并在构建阶段填充的哈希表中查找匹配项。

N 的值由 max_threads 参数控制，默认情况下，它等于执行 join 操作的 ClickHouse 服务器上的可用 CPU 核心数。

此外，ClickHouse 提供了两个参数来限制基于哈希的连接中哈希表的大小：max_rows_in_join 和 max_bytes_in_join。默认情况下，它们的值均为 0，表示不限制哈希表的大小。这些限制有助于控制连接时的内存使用，防止过度分配。如果超出限制，用户可以选择让 ClickHouse 抛出异常（默认行为），或者基于已处理的数据返回部分结果。

下图来自上一篇文章中的完整示意图，展示了并行哈希连接的构建（build）阶段（max_threads 设为 4），并标注了这些大小限制如何控制内存使用：

每个处理线程执行以下循环：

① 从输入表加载下一块数据行，② 按照前述方式将其插入哈希表。

如果设置了 ③ max_rows_in_join 或 max_bytes_in_join，则处理线程 ④ 从所有哈希表实例中统计总行数和总字节大小。为避免并发修改，当前线程会依次锁定每个哈希表的互斥锁（mutex），导致其他线程需等待统计完成。如果行数或字节大小超过阈值，join 操作将被终止。

在此版本之前，即使没有