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 暴露给用户1Bug Fix (user-visible misbehavior in official stable release)正式稳定版中用户可观测到的错误行为5Build/Testing/Packaging Improvement构建、测试、打包与依赖更新2NOT FOR CHANGELOG / INSIGNIFICANT不影响行为的收尾工作CI 脚本等2二、Bug FixLowCardinality 与 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 servers 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.txtpart 目录内的列元数据文件可能写成了非法内容后续读取该 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 改进都与时间/时区依赖相关更新 cctz 到最新 mastertzdb 更新到 2020ecctz 是 ClickHouse 用于高精度时区换算的 C 时区库仓库以第三方子模块形式内置于 contrib/cctz构建规则见 contrib/cctz-cmake。该条目属于依赖库的例行跟进。tzdata 更新到 2022e这是本版本里对终端用户最有感知的一条变更日志直接引用了 IANA tzdb NEWS 的要点巴勒斯坦Palestine的夏令时切换时间调整为周六 02:00乌克兰的三个时区合并为一个约旦Jordan与叙利亚Syria不再使用 02/03 加夏令时的方案改为全年固定 03。对 ClickHouse 的实际影响涉及Timezone参数、Date/DateTime到带时区类型换算、以及按toTimezone等函数跨上述地区历史/未来时间换算的结果都会以新的 tzdata 2022e 为准。如果你的业务按中东/东欧地区时区做时间切片报表这一更新保证了与 IANA 官方数据的同步。八、其他修复与 CI 收尾工作无详细描述的上游修复closes #42453changelog 中该条目仅标注 “This closes #42453”是随主干回合但未附详细说明的修复属于维护性内容。release.py 增加发布类型校验为发布脚本增加警告信息并强制要求填写 release 类型属于发布流程的防呆措施不影响服务端行为。回滚 #27787以 revert 形式撤销了此前一个改动属于“先回滚、后重新评估”的常见维护手法用户侧无功能变化。九、升级建议与适用前提综合以上变更v22.7.7.24-stable 对以下几类 22.7 用户具有明确的升级价值场景特征对应修复紧急程度依赖additional_table_filters做多租户隔离且涉及Distributed表Distributed 过滤未生效高正确性/隔离使用ATTACH PART附加列结构不同的 part 并执行ALTER UPDATEcolumns.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考