ClickHouse（二）双分片双副本集群配置优化与性能调优

1. 集群搭好了，然后呢？从“能用”到“好用”的调优之路

上次咱们一起把ClickHouse的双分片双副本集群给搭起来了，看着system.clusters表里整整齐齐的节点列表，心里是不是挺有成就感？我当时也是，感觉大功告成，可以开始跑业务了。但很快我就发现，事情没那么简单。集群是能跑了，但一上真实数据，问题就来了：写入速度时快时慢，复杂查询偶尔会卡住，ZooKeeper的连接数时不时就飙高报警。这让我明白，搭建集群只是第一步，就像刚组装好一台新电脑，不装驱动、不调系统，根本没法流畅打游戏。真正的挑战，是让这个集群在真实的生产压力下，依然能稳如老狗，快如闪电。

所以，这篇文章咱们不聊搭建，专门聊聊“调优”。我会把我在实际项目中踩过的坑、试出来的有效参数，以及一些“压箱底”的优化思路，毫无保留地分享给你。我们的目标很明确：让已有的双分片双副本集群，从“能工作”的状态，进化到“高性能、高稳定”的生产级状态。这中间涉及到配置文件的精细调整、系统资源的合理分配、查询语句的优化技巧，甚至是一些监控和排错的心得。别担心，我会尽量用大白话和实际案例来解释，保证你跟着做就能看到效果。

2. 基础配置调优：给ClickHouse一个舒适的“家”

集群跑起来后，第一件要做的事不是急着灌数据，而是先看看它的“居住环境”舒不舒服。很多性能问题，根源都在基础配置没到位。

2.1 内存与并发配置：别让资源“打架”

ClickHouse是个内存消耗大户，尤其是在做聚合、排序和JOIN的时候。默认配置比较保守，我们需要根据机器实际资源来调整。核心配置文件还是config.xml，但这次我们得更精细。

首先看内存限制。max_memory_usage这个参数控制单次查询能用的最大内存，默认是10GB。对于一台有64GB内存的机器，这个值可以设到40GB甚至更高，给复杂查询留足空间。但要注意，设得太高，万一有个“坏”查询，可能直接把机器内存吃光，导致OOM（内存溢出）。我的经验是，设置为物理内存的50%-70%比较安全。

<!-- 在 config.xml 的 <profiles> -> <default> 段落中修改，或直接在users.xml里为用户设置 --> <max_memory_usage>40000000000</max_memory_usage> <!-- 40GB -->

另一个关键参数是max_concurrent_queries，它控制最大并发查询数。默认是100，看起来不小，但在高并发场景下，如果每个查询都很重，100个并发足以拖垮集群。我建议根据CPU核心数来设置，比如32核的机器，可以设置为50-80。同时，要搭配max_threads（单个查询能用的最大线程数，通常设为CPU核数）一起看，避免线程过多导致频繁上下文切换，反而降低性能。

<max_concurrent_queries>50</max_concurrent_queries> <max_threads>16</max_threads> <!-- 假设是16核CPU -->

对于写入，background_pool_size这个参数至关重要。它控制后台合并（Merge）和突变（Mutation）操作的线程数。默认是16，在写入量大的场景下，可以适当调大，比如调到32或64，能显著加快数据落盘和合并的速度，避免产生过多的小分区。

<background_pool_size>32</background_pool_size>

2.2 ZooKeeper连接优化：稳住“指挥部”

在双分片双副本架构里，ZooKeeper（ZK）就是集群的“指挥部”，负责副本间的元数据同步和状态协调。ZK一旦不稳，整个ClickHouse集群就会出各种诡异问题。原始配置里我们只配了ZK地址，但连接参数没细调。

首先，会话超时时间（session_timeout_ms）和操作超时时间（operation_timeout_ms）需要关注。默认值在网络不太稳定或者ZK压力大时，容易导致会话超时，进而引发“Table is in readonly mode”这种错误。我一般会把它们调大一些。

<zookeeper> <session_timeout_ms>30000</session_timeout_ms> <!-- 默认30秒，可适当延长 --> <operation_timeout_ms>10000</operation_timeout_ms> <!-- 默认10秒 --> <node> <host>node1</host> <port>2181</port> </node> ... <!-- 其他节点 --> </zookeeper>

其次，最大并发请求数（max_requests）默认是100，对于副本表多的集群，可能不够。可以观察ZK的监控，如果经常有请求排队，可以适当提高到200或300。但别盲目调太高，会给ZK带来额外压力。

还有一个实战中容易忽略的点：避免所有ClickHouse实例同时向ZK发起大量请求。比如在凌晨做批量数据导入或后台合并时，如果所有节点同时动作，ZK可能成为瓶颈。可以通过错峰执行任务，或者调整不同实例上表的合并计划来缓解。

3. 表引擎与数据结构优化：从根源提升效率

配置调好了环境，接下来就要优化数据本身了。ClickHouse的性能极度依赖表引擎的选择和表结构的设计，这一步做得好，查询速度能有数量级的提升。

3.1 MergeTree家族引擎选型与参数

我们搭建副本集群，核心表引擎肯定是ReplicatedMergeTree。但光指定引擎还不够，建表时的参数才是精髓。

分区键（PARTITION BY）：这是最重要的优化手段之一。分区相当于把一张大表按时间或其他维度切分成独立文件夹。查询时如果能命中分区，可以极大减少数据扫描量。常见的做法是按天（toYYYYMMDD(date)）或按月分区。但分区不是越细越好，分区太多（比如按小时），会导致文件数爆炸，增加ZK负担和合并开销。我的一般原则是，单个分区内的数据量最好在1GB到10GB之间。

排序键（ORDER BY）：这决定了数据在磁盘上的物理存储顺序，是ClickHouse查询快的核心秘诀。排序键应该选择你最常用来过滤（WHERE）和分组（GROUP BY）的列。比如你的查询总是按user_id和event_time过滤，那么ORDER BY (user_id, event_time)就是最佳选择。排序键的列数不宜过多，通常1-3列就够了，太多会影响写入速度。

索引（INDEX）：ClickHouse的主索引就是排序键，但我们可以通过SETTINGS index_granularity = 8192来调整索引粒度。默认值8192意味着每8192行数据生成一个索引标记。对于数据量特别大、且查询筛选率很高的场景，可以尝试调小这个值（比如4096），让索引更“密集”，但代价是索引文件会变大。反之，如果数据量不大或查询较粗放，可以调大以节省内存。

一个优化后的建表示例：

CREATE TABLE user_behavior_local ON CLUSTER ck_2shard_2replica_cluster ( `user_id` UInt32, `event_time` DateTime, `event_type` String, `page` String, `device` String ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/default/user_behavior', '{replica}') PARTITION BY toYYYYMM(event_time) ORDER BY (user_id, event_time) SETTINGS index_granularity = 8192, storage_policy = 'default'; -- 存储策略，后面会讲

3.2 数据类型与编码选择

选择合适的字段类型能直接节省存储空间和内存，提升IO效率。有几个原则：

1. 能用数值型就不用字符串：比如IPv4地址可以用IPv4类型或UInt32（通过函数转换）存储，比String省空间，查询也快。
2. 使用低基数编码：对于像城市、性别、状态码这种取值有限的字符串列，使用LowCardinality(String)类型。ClickHouse会为其创建字典编码，大幅压缩存储并加速查询。
3. 避免Nullable：Nullable类型会带来额外的存储和计算开销。如果业务允许，尽量用默认值（如0、空字符串）代替NULL。
4. 日期时间用专门类型：一定要用Date、DateTime类型，不要用String或UInt32来存时间戳，前者有大量的优化函数和分区支持。

4. 查询性能深度调优：让SQL飞起来

集群和表都优化好了，最后也是最关键的一环，就是优化查询本身。再好的车，司机乱开也跑不快。

4.1 利用Explain查看执行计划

ClickHouse提供了EXPLAIN语句（特别是EXPLAIN PIPELINE和EXPLAIN ESTIMATE），这是性能调优的“显微镜”。在跑一个慢查询前，先看看它的执行计划。

EXPLAIN PIPELINE SELECT user_id, count(*) FROM user_behavior WHERE event_time > '2023-10-01' GROUP BY user_id;

通过执行计划，你可以看到：

• 是否用到了分区裁剪：如果WHERE条件里的分区键能有效过滤，会显示ReadFromMergeTree步骤中扫描的分区数量大大减少。
• 是否用到了索引：会显示KeyCondition，说明利用了排序键进行数据过滤。
• 聚合和排序发生在哪个阶段：是在分布式节点上局部聚合，还是所有数据拉到一处再聚合？理想情况是尽可能“下推”计算。

我遇到过一种情况，查询很慢，用EXPLAIN一看，发现因为JOIN子句的顺序问题，导致右表全部被拉取到左表节点进行处理，产生了巨大的网络传输。调整JOIN顺序和改用GLOBAL JOIN后，速度立刻提升了几十倍。

4.2 避免常见的“性能杀手”

根据我的踩坑经验，下面几种写法要特别小心：

1. **SELECT ***：这是大忌。ClickHouse是列式存储，你查多少列，它就读多少列的数据。只查询需要的列，能极大减少IO。比如你有一张100列的表，但查询只需要其中3列，用SELECT *会比指定列慢几十倍。
2. 在WHERE条件中对非索引列做函数计算：比如WHERE toDate(event_time) = '2023-10-01'，这会导致索引失效，全表扫描。应该写成WHERE event_time >= '2023-10-01' AND event_time < '2023-10-02'。
3. 大表JOIN大表：ClickHouse的JOIN性能是弱项。如果必须JOIN，尽量确保右表是小表（可以放进内存），并使用JOIN或GLOBAL JOIN。更好的设计是，通过ETL过程将需要关联的数据扁平化，存成一张宽表。
4. 频繁的小批量插入：每次插入都会在磁盘生成一个数据块（part），后台需要合并。频繁插入会产生大量小part，加重合并负担。应该尽量批量插入，比如攒够1万或10万行数据再写一次。

4.3 分布式查询优化

在我们的双分片集群上，查询有两种模式：分布式表查询和直连本地表查询。

• 分布式表：通过Distributed表引擎创建，它是一个逻辑视图，写查询时像操作单表一样简单。但它的查询过程是：接收查询 -> 分发到所有分片 -> 收集结果 -> 返回。这多了一层网络开销和中心节点聚合压力。对于聚合查询，如果GROUP BY的键包含在分片键中，可以设置distributed_group_by_no_merge=2，让分片节点先做局部聚合，减少数据传输量。
• 直连本地表：在应用层自己做分片路由，直接查询每个分片上的本地表（*_local）。这种方式更灵活，性能可能更好，但应用逻辑变复杂了。

我的建议是：对于简单的点查和插入，可以用分布式表，方便。对于复杂的、重聚合的分析查询，最好在应用层做分片路由，直连本地表，或者对分布式表查询进行精心优化。

5. 监控、维护与故障排查

一个健康的集群离不开持续的监控和日常维护。这里分享几个我常用的“工具箱”。

5.1 关键监控指标

1. 系统层面：CPU使用率、内存使用率（重点看ClickHouse进程）、磁盘IOPS和空间使用率（特别是数据盘和日志盘）。ZooKeeper的连接数、延迟和节点数也要重点监控。
2. ClickHouse层面：
   • system.metrics：查看每秒查询数（Query）、插入行数（InsertedRows）、合并操作数（Merge）等。
   • system.events：查看查询耗时（QueryTime）、磁盘读写次数等。
   • system.merges：查看当前正在进行的合并任务，合并是常态，但要警惕长时间不结束的合并或队列里堆积了大量合并任务，这可能意味着background_pool_size设置太小或磁盘IO瓶颈。
   • system.replication_queue：对于副本表，这里可以看到副本同步队列的状态。如果future_parts或parts_to_check数量持续增长，说明副本同步可能出了问题。

我习惯用Grafana搭配ClickHouse自带的system库做仪表盘，把上述关键指标都可视化出来，有问题一眼就能看到。

5.2 日常维护操作

• 定期清理旧数据：使用ALTER TABLE ... DROP PARTITION或ALTER TABLE ... DELETE来清理过期数据，比直接DELETE效率高得多。
• 监控并优化ZooKeeper：定期清理ZK上ClickHouse留下的旧元数据（/clickhouse/tables/...下的过期节点），但操作要极其谨慎，最好在ClickHouse官方文档指导下进行。
• 留意后台合并：如果发现查询突然变慢，可以查一下是不是正在跑一个非常大的合并任务，占用了大量IO。可以通过system.merges表观察。

5.3 常见故障与应急处理

• 副本不同步：检查ZK连接是否正常，查看system.replication_queue。可以尝试在落后副本上执行SYSTEM SYNC REPLICA table_name进行手动同步。
• “Too many parts”错误：说明表的小块（part）太多了，通常是写入太频繁或合并跟不上。临时解决可以增大background_pool_size，长远需要优化写入批次。
• 内存不足（Memory limit exceeded）：调整max_memory_usage，或者优化查询，减少单次查询的数据处理量。对于GROUP BY查询，可以尝试使用distributed_aggregation_memory_efficient设置。
• ZooKeeper连接失败：检查ZK集群健康状态，调整ClickHouse中ZK的session_timeout_ms等超时参数。网络分区也会导致这个问题。

调优是个持续的过程，没有一劳永逸的“银弹”。我的经验是，每上线一个新的数据模式或查询类型，都要结合监控仔细观察一段时间。性能优化就像给汽车做保养和改装，你得先了解它的脾气（监控指标），再针对性地调整（修改配置和查询），最后上路实测（压测和业务验证）。双分片双副本的架构给了我们冗余和扩展能力，而细致的调优则能榨干每一分硬件潜力，让集群在面对真实业务洪流时，真正做到从容不迫。