ClickHouse v22.7.7.24-stable 版本解析：LowCardinality 聚合、备份 4GB 大文件与 Distributed 过滤等 Bug 修复详解

ClickHouse v22.7.7.24-stable 版本解析：LowCardinality 聚合、备份 4GB 大文件与 Distributed 过滤等 Bug 修复详解

【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse

本文基于 ClickHouse 官方变更日志docs/changelogs/archive/v22.7.7.24-stable.md，逐项解析 v22.7.7.24-stable（提交02ad1f979a8）相对上一稳定版 v22.7.6.74-stable（提交c00ffb3c11a）引入的全部变更：1 个聚合方法 Bug 修复、5 个用户可见行为的 Bug 修复、2 个构建/测试改进，以及 CI 脚本层面的收尾工作。读完后，你将明确每个修复解决了什么真实故障场景、涉及哪些底层设置与源码路径，从而判断自己的 22.7 环境是否有必要升级。

一、版本定位：22.7 分支的维护性小版本

v22.7.7.24-stable 是 ClickHouse 22.7 系列的一个维护补丁版本，属于典型的“Backport”发布：所有变更均从主干回合（changelog 中每条都标注了 “Backported in #xxxxx” 的上游 PR 编号），不包含任何新功能。这意味着它的风险极低，而收益集中在生产稳定性上——尤其适合运行在长期支持分支上、需要规避特定故障的用户。

该版本的变更日志位于仓库的 docs/changelogs/archive/v22.7.7.24-stable.md，按 ClickHouse 变更日志的惯例分为三类：

类别	含义	本版条目数
Bug Fix	开发分支上的 Bug 修复（尚未随 stable 暴露给用户）	1
Bug Fix (user-visible misbehavior in official stable release)	正式稳定版中用户可观测到的错误行为	5
Build/Testing/Packaging Improvement	构建、测试、打包与依赖更新	2
NOT FOR CHANGELOG / INSIGNIFICANT	不影响行为的收尾工作（CI 脚本等）	2

二、Bug Fix：LowCardinality 与 BigInt 组合下的聚合方法选择

变更日志条目：

Choose correct aggregation method for LowCardinality with BigInt.

这条修复针对的是聚合执行引擎在选择聚合方法（aggregation method）时，遇到LowCardinality修饰的BigInt类型键列可能选错策略的问题。

从源码结构看，聚合方法的选定逻辑集中在聚合执行器中，例如 src/Interpreters/Aggregator.cpp 中就包含chooseAggregationMethod的选择分支，以及对LowCardinality列的专门处理路径（如对非LowCardinality列执行recursiveRemoveLowCardinality后再走哈希路径）。LowCardinality本质上是用字典编码压缩低基数列，聚合时必须根据键的基数、键宽、是否可哈希等因素在多种方法（单列哈希、多列哈希、序列化键、溢桶两级聚合等）中做取舍；当键是LowCardinality(BigInt(...))这类宽整型且带字典包装时，方法选择的判断条件若不覆盖该组合，就可能落入不正确的分支。修复后的行为是：对这种类型组合选用正确的聚合方法，保证聚合结果正确与性能合理。

对使用者的实际影响：如果你的表以LowCardinality( BigInt )列做 GROUP BY 键，并运行在 22.7.6.x 及更早版本上，升级到 v22.7.7.24-stable 可消除该类查询潜在的聚合方法误选问题。

三、用户可见修复一：从基础备份（base backup）复用超过 4GB 的文件

变更日志条目：

Fix reusing of files > 4GB from base backup.

ClickHouse 的备份体系（SYSTEM BACKUP/SYSTEM RESTORE及其增量链）位于 src/Backups 模块。其增量备份机制会把与基础备份中内容相同的文件做“引用复用”而非重新写入，以节省空间和时间。本条修复的问题是：在增量备份复用基础备份中的大文件时，对体积超过 4GB 的文件处理有误。

从源码结构看，备份条目在生成与校验时会附带 checksum（参见 src/Backups/BackupEntryWithChecksumCalculation.h），而跨 4GB 边界的偏移/长度表示（32 位与 64 位计数）是此类“大文件复用”故障的典型诱因。如果你的备份集里存在单个超过 4GB 的数据文件（大 MergeTree 数据分片的 part 文件、大的字典文件等），且依赖增量备份链，这一修复值得单独作为升级理由。

四、用户可见修复二：Projections 与aggregate_functions_null_for_empty的冲突

变更日志条目（原文较长，完整保留其要点）：

Fix a bug with projections and theaggregate_functions_null_for_emptysetting. This bug is very rare and appears only if you enable theaggregate_functions_null_for_emptysetting in the server's config. This closes #41647.

该 Bug 的触发条件非常苛刻：只有在服务器级配置中开启了aggregate_functions_null_for_empty（它让聚合函数对空输入返回NULL而非默认值，从而改变聚合函数的返回类型）时，才会与表投影（Projection）机制产生冲突。

仓库中的 src/Storages/ProjectionsDescription.cpp 体现了投影构建对这类“改变函数类型”的设置的处理策略：在执行投影相关的上下文构建时，会显式把aggregate_functions_null_for_empty强制置为 0，并附有注释说明原因——“We ignore aggregate_functions_null_for_empty cause it changes aggregate function types”。也就是说，投影数据是在该设置被关闭的前提下物化的；如果查询侧带着该设置去匹配投影，投影的物化结果与查询期望的函数类型就不一致，可能造成错误的结果或匹配失败。本版本修复的正是这种边角冲突。

实操建议：如果你没有在服务器配置中开启aggregate_functions_null_for_empty，此条与你无关；若确实开启了，建议升级到本版本以消除该罕见但可能影响数据正确性的隐患。

五、用户可见修复三：attached part 上执行 ALTER UPDATE 可能写出非法的 columns.txt

变更日志条目：

ALTER UPDATEof attached part (with columns different from table schema) could create an invalidcolumns.txtmetadata on disk. Reading from such part could fail with errors or return invalid data. Fixes #42161.

这条修复涉及 MergeTree 表分片（part）的元数据一致性：

• 通过ATTACH PART附加的分片，其列集合可能与当前表结构不完全一致（这是ATTACH PART允许的灵活用法）；
• 在此类 part 上执行ALTER TABLE ... UPDATE（轻量更新之外的 mutation）会触发对该 part 的改写；
• 修复前，mutation 过程中生成的columns.txt（part 目录内的列元数据文件）可能写成了非法内容，后续读取该 part 时要么直接报错，要么返回无效数据——后者比报错更危险，因为它不显式失败而是静默出错数据。

从源码结构看，part 的列元数据管理归属于 MergeTree 存储层（如 src/Storages/MergeTree/MergeTreeData.h 所声明的表数据管理逻辑），mutation 对 part 的改写会重新生成 part 目录内的元数据文件。本版本修复后，对列结构与表 schema 不同的 attached part 执行ALTER UPDATE时，落盘的columns.txt元数据保持合法，消除了“读时报错或返回脏数据”的风险。

六、用户可见修复四：additional_table_filters未作用于 Distributed 表

变更日志条目：

Settingadditional_table_filterswere not applied toDistributedstorage. Fixes #41692.

additional_table_filters是一个“按表名指定强制过滤条件”的会话设置，典型用于多租户场景：为每个租户会话注入形如Map('db.table', 'tenant_id = 42')的额外过滤条件，让该租户的所有查询自动带上租户隔离谓词。

仓库源码中可以清楚看到该设置的注入链路：在 src/Interpreters/InterpreterSelectQuery.cpp 中，parseAdditionalFilterConditionForTable函数会遍历设置中的每个(表名, 过滤表达式)元组，通过表别名、库名.表名等方式匹配目标表，把过滤字符串解析为 AST 后并入查询；当设置非空且查询涉及连接表时，也会取第一个表来尝试匹配。修复前的问题在于：当查询的目标存储引擎是Distributed时，这条强制过滤没有被应用——对多租户隔离场景而言，这等于隔离策略被绕过。本版本修复后，additional_table_filters对Distributed存储的查询同样生效。

如果你的部署依赖该设置做行级租户隔离，并且链路中包含Distributed表，那么这条修复属于安全相关的修复，应视为强制升级项。

七、构建与测试改进：时区数据更新到 2022e

变更日志中两条 Build/Testing/Packaging 改进都与时间/时区依赖相关：

1. 更新 cctz 到最新 master，tzdb 更新到 2020e：cctz 是 ClickHouse 用于高精度时区换算的 C++ 时区库，仓库以第三方子模块形式内置于 contrib/cctz，构建规则见 contrib/cctz-cmake。该条目属于依赖库的例行跟进。
2. tzdata 更新到 2022e：这是本版本里对终端用户最有感知的一条，变更日志直接引用了 IANA tzdb NEWS 的要点：
   • 巴勒斯坦（Palestine）的夏令时切换时间调整为周六 02:00；
   • 乌克兰的三个时区合并为一个；
   • 约旦（Jordan）与叙利亚（Syria）不再使用 +02/+03 加夏令时的方案，改为全年固定 +03。

对 ClickHouse 的实际影响：涉及Timezone参数、Date/DateTime到带时区类型换算、以及按toTimezone等函数跨上述地区历史/未来时间换算的结果，都会以新的 tzdata 2022e 为准。如果你的业务按中东/东欧地区时区做时间切片报表，这一更新保证了与 IANA 官方数据的同步。

八、其他修复与 CI 收尾工作

• 无详细描述的上游修复（closes #42453）：changelog 中该条目仅标注 “This closes #42453”，是随主干回合但未附详细说明的修复，属于维护性内容。
• release.py 增加发布类型校验：为发布脚本增加警告信息并强制要求填写 release 类型，属于发布流程的防呆措施，不影响服务端行为。
• 回滚 #27787：以 revert 形式撤销了此前一个改动，属于“先回滚、后重新评估”的常见维护手法，用户侧无功能变化。

九、升级建议与适用前提

综合以上变更，v22.7.7.24-stable 对以下几类 22.7 用户具有明确的升级价值：

场景特征	对应修复	紧急程度
依赖additional_table_filters做多租户隔离，且涉及Distributed表	Distributed 过滤未生效	高（正确性/隔离）
使用ATTACH PART附加列结构不同的 part 并执行ALTER UPDATE	columns.txt元数据非法	高（可能静默返回错数据）
备份集含 >4GB 单文件并依赖增量备份复用	大文件复用错误	中
服务器开启aggregate_functions_null_for_empty且使用 Projection	投影与设置冲突	低（触发条件苛刻）
LowCardinality(BigInt)列做聚合键	聚合方法误选	中
业务时区涉及巴勒斯坦、乌克兰、约旦、叙利亚	tzdata 2022e	低（数据同步性）

适用前提说明：本文所有解析均以当前仓库中 v22.7.7.24-stable 的变更日志原文与仓库源码结构为依据，行级细节（如投影上下文中强制关闭aggregate_functions_null_for_empty的代码）取自当前仓库快照，与 22.7 发布时的代码可能存在版本差异；如需在 22.7 分支上定位修复，建议以 changelog 中列出的 PR 编号（#42146、#42198、#42319、#42322、#42327、#42342、#42573）为检索关键词。

【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse