ClickHouse 分区设计：分区不是越细越好

ClickHouse 分区设计：分区不是越细越好

一、分区设计决定后续运维难度

ClickHouse 常用于大规模分析查询，分区是控制数据管理和查询裁剪的重要工具。但分区不是越细越好。过细分区会产生大量小 part，增加元数据管理、合并压力和查询开销；过粗分区又会降低裁剪效果，让删除和归档成本上升。

分区设计要从数据生命周期和查询条件出发。按天、按月、按业务线或按租户分区，没有绝对答案。关键是看数据写入量、查询时间范围、删除归档策略和分区基数。一个漂亮的分区表达式，如果让后台 merge 忙到喘不过气，就是坏设计。

二、存储结构：分区、part 和 merge 要一起看

flowchart TD A[写入数据] --> B[分区] B --> C[多个 Part] C --> D[后台 Merge] D --> E[更大 Part] E --> F[查询扫描] B --> G[TTL 删除]

ClickHouse 写入后会形成 part，后台不断合并。分区过细时，每个分区内 part 数量可能少，但整体分区数巨大；分区过粗时，单分区内 part 和数据量过大。两种情况都会影响性能，只是表现不同。监控 part 数量比单纯看表大小更有意义。

查询裁剪依赖分区键和主键。分区键用于粗粒度跳过数据，主键排序键用于更细粒度裁剪。不要把分区键当成万能索引。若查询常按event_date过滤，按月分区通常合理；若还要按用户或租户查询，应考虑排序键设计，而不是继续把分区拆碎。

三、建表示例：按月分区，按查询路径排序

下面是一个常见的事件表设计。它不一定适合所有场景，但展示了分区和排序键的分工。

CREATE TABLE user_event ( event_date Date, tenant_id UInt64, user_id UInt64, event_name String, event_time DateTime, properties String ) ENGINE = MergeTree PARTITION BY toYYYYMM(event_date) ORDER BY (tenant_id, event_date, event_name, user_id);

如果按天分区，每年会产生 365 个分区；按月分区则是 12 个。对于每天数据量极大的表，按天可能合理；对于中等规模数据，按月更稳。判断依据不是日历，而是每个分区的数据量、part 数量、查询范围和 TTL 策略。

排序键要服务高频查询。若查询总是带租户条件，把tenant_id放在前面能提升裁剪效果。若查询主要按时间范围聚合，时间字段位置要更靠前。排序键选择错误，分区再合理也救不了查询。

四、运维检查：part 数量和 TTL 压力要监控

ClickHouse 表需要监控system.parts。活跃 part 数量过多时，查询会变慢，后台 merge 压力增加。可以按表、分区统计 part 数量和大小，发现异常写入模式。很多性能抖动不是查询突然变复杂，而是小批量写入把 part 打碎了。

TTL 删除也要考虑分区。按分区粒度删除通常更高效，如果 TTL 条件和分区键对齐，删除历史数据成本更低。若 TTL 条件很细碎，后台 mutation 可能消耗大量资源。数据生命周期设计不好，后面只能靠运维硬扛。

最后，分区调整不是小改动。历史数据重分区通常需要重建表、导数据和校验。上线前用真实数据量做 benchmark，观察写入、查询、merge 和 TTL，而不是在小样本上凭感觉决定。

五、总结

ClickHouse 分区设计要平衡查询裁剪、part 数量、merge 压力和数据生命周期。分区不是越细越好，排序键也不能被忽略。用真实数据监控 part、查询和 TTL，才能判断设计是否靠谱。