ClickHouse 分区机制详解：规则、合并与实践指南

在 ClickHouse 中，分区是提升查询性能的核心机制之一，但它的设计逻辑与传统 OLAP 引擎存在显著差异。本文将从分区规则、目录命名、合并过程到开发实践，全面解析 ClickHouse 的分区机制，帮助你合理设计分区策略，避免常见陷阱。

一、前言：分区的核心作用与特殊性

ClickHouse 的分区功能仅由 MergeTree 家族表引擎支持，其本质是对本地数据的纵向切分——通过将数据按规则划分为独立的分区目录，实现查询时的分区过滤，减少无效数据扫描。

需要特别注意的是：

• 分区≠分片（Shard）：分区是单节点内的数据切分，而分片是多节点间的横向扩展，二者作用维度不同。
• 分区依赖数据写入动态创建：不同于多数 OLAP 引擎在表创建时预建分区，ClickHouse 的分区仅在数据写入时生成，无数据则无分区。

本文将围绕以下四个核心点展开：分区规则、分区目录命名、合并过程、开发实践注意事项。

二、数据分区规则：分区键如何决定分区 ID？

分区的核心是分区键（PARTITION BY 表达式），它决定了数据如何划分到不同分区，而每个分区的唯一标识是分区 ID。分区键支持单个或多个字段（通过元组组合），分区 ID 的生成逻辑根据字段类型分为四类：

1. 不指定分区键

若未通过 PARTITION BY 声明分区，则默认分区名为 all，所有数据均写入该分区。

2. 整数类型作为分区键

当分区键为整数（兼容 UInt64、有符号/无符号整数），且无法转换为 YYYYMMDD 格式的日期时，分区 ID 直接为整数字符串。
例如：PARTITION BY age，当 age=18 时，分区 ID 为 18。

3. 时间类型作为分区键

若分区键是时间类型（如 Date、DateTime），或可转换为 YYYYMMDD 格式的整数（如 20240101），则分区 ID 为对应的时间格式字符串。
例如：

• PARTITION BY create_time（create_time=2024-01-01）→ 分区 ID 为 20240101。
• PARTITION BY toYYYYMM(create_time) → 分区 ID 为 202401（按月聚合）。

4. 其他类型作为分区键

对于字符串（String、Varchar）、浮点型（Float）等既非整数也非时间的类型，分区 ID 为其 128 位哈希值。
例如：PARTITION BY username，若 username="clickhouse"，分区 ID 可能为 a1b2c3...（哈希结果）。

多字段分区键

若通过元组指定多个分区字段（如 PARTITION BY (age, create_time)），则分区 ID 为各字段生成的 ID 以 - 拼接。
例如：age=18 且 create_time=2024-01-18 时，分区 ID 为 18-20240118。

三、分区目录命名规则：不止于分区 ID

在 ClickHouse 的数据存储目录中，分区目录的命名并非直接使用分区 ID，而是包含额外信息，格式为：
PartitionId_MinBlockNum_MaxBlockNum_Level

以 20240118_1_1_0 为例，各部分含义如下：

• PartitionId：即上文生成的分区 ID（如 20240118）。
• MinBlockNum/MaxBlockNum：数据块编号范围。BlockNum 是单表全局自增的整数（初始为 1），新写入数据时生成新编号。新增分区目录时，MinBlockNum 与 MaxBlockNum 相等（如 1_1）；合并后会更新为合并前的最小/最大编号。
• Level：合并层级，记录分区内的合并次数。初始值为 0，每合并一次累加 1（仅对当前分区有效，非全局唯一）。

四、分区目录的合并过程：LSM 特性的体现

MergeTree 引擎的分区机制体现了 LSM（Log-Structured Merge Tree）的设计思想——数据写入时先生成小文件，后台再异步合并，以优化写入性能并减少碎片。

合并的触发与过程

1. 写入即生成新目录：每次写入数据（如 INSERT），即使属于同一分区，也会生成新的分区目录。例如，两次写入 20240118 分区，会生成 20240118_1_1_0 和 20240118_2_2_0。

2. 后台自动合并：写入后 10~15 分钟，ClickHouse 会触发后台任务，将同一分区的多个目录合并为一个新目录。也可通过 OPTIMIZE TABLE table_name PARTITION partition_id 手动触发。

3. 合并后目录命名规则：

   • MinBlockNum = 合并前所有目录的最小 MinBlockNum；
   • MaxBlockNum = 合并前所有目录的最大 MaxBlockNum；
   • Level = 合并前所有目录的最大 Level + 1。

   例如，合并 20240118_1_1_0（Level=0）和 20240118_2_2_0（Level=0）后，新目录为 20240118_1_2_1。

4. 旧目录的清理：合并后旧目录不会立即删除，默认保留 8 分钟（可通过 merge_tree.max_sleep_time_before_drop_old_parts 调整），以应对合并过程中的查询需求。

五、实际开发注意事项：避免踩坑的关键

合理的分区策略是 ClickHouse 性能优化的核心，以下是实践中需重点关注的问题：

1. 避免过细的分区粒度

建议：分区粒度不细于“月”（如 toYYYYMM(date)），避免按日、按时分区。
原因：

• 查询性能下降：过多分区（超过 1000 个）会导致文件系统中文件数量激增，增加 I/O 压力和文件描述符开销，显著拖慢查询速度。
• 维护成本高：过细分区可能导致部分分区数据量过大，影响备份、迁移效率；同时，大量分区会增加元数据管理复杂度。

2. 分区键需作为 ORDER BY 的首列

建议：将分区字段作为 ORDER BY 表达式的第一列（如 ORDER BY (create_month, id)）。
原因：ClickHouse 的主键索引依赖 ORDER BY，分区字段前置可确保同分区数据物理连续存储，提升查询时的分区过滤效率。

3. 禁止客户端指定分区标识符

建议：分区逻辑由表结构（PARTITION BY）固化，而非由客户端动态指定。
原因：

• 客户端指定可能导致分区冲突、元数据混乱（如重复分区）。
• 统一由表结构管理可简化权限控制和数据一致性维护。

4. 批量写入减少碎片

建议：使用 JDBC 等工具写入时开启攒批（如 rewriteBatchedStatements=true），避免单条插入。
原因：单次写入生成一个分区目录，批量写入可减少目录数量，降低后台合并压力。

总结

ClickHouse 的分区机制是一把“双刃剑”：合理设计可显著提升查询性能，反之则可能成为性能瓶颈。核心原则是：以业务查询模式为导向，选择合适的分区粒度（如按月），避免过度拆分，同时遵循 MergeTree 的 LSM 特性优化写入方式。

通过理解分区规则、合并过程及实践注意事项，你可以更好地驾驭 ClickHouse 的分区功能，为大规模数据场景提供高效支持。

参考资料：
ClickHouse 分区机制深度解析