ClickHouse分布式查询执行模型：从Query Plan到多节点并行调度的全链路深入解读

2026/7/13 11:00:17

ClickHouse分布式查询执行模型：从Query Plan到多节点并行调度的全链路深入解读

一、一条"简单"的COUNT查询暴露的架构复杂度

"就查一下全表行数，怎么要等三分钟？"——产品经理质疑的是这条SQL：SELECT COUNT(*) FROM user_behavior_log WHERE event_date BETWEEN '2024-01-01' AND '2024-06-30'。数据量不过200亿行，按ClickHouse的官方Benchmark，这种规模的聚合查询应该在一秒内完成。

排查后发现，问题不在ClickHouse本身，而在于集群配置：这个分布式表有24个分片，但查询只利用了其中3个节点的计算能力——其余21个节点要么在干等Coordinator分配任务，要么因为网络带宽瓶颈导致数据传输缓慢。ClickHouse的分布式查询执行模型远比单机查询复杂，从Query Plan的生成到多节点并行调度，每一个环节都可能成为瓶颈。

flowchart TB A[客户端提交查询] --> B[Coordinator节点] B --> C{解析与优化} C --> D[生成分布式Query Plan] D --> E[任务切分] E --> F1[Shard 1 Worker] E --> F2[Shard 2 Worker] E --> F3[Shard N Worker] F1 --> G1[本地执行] F2 --> G2[本地执行] F3 --> G3[本地执行] G1 --> H[中间结果汇聚] G2 --> H G3 --> H H --> I[Coordinator最终聚合] I --> J[返回结果] D -.-> K[Query Plan缓存] E -.-> L[节点健康度评估]

二、分布式Query Plan的生成：从AST到两阶段执行计划

ClickHouse的分布式查询采用经典的Scatter-Gather模式，但在具体实现上有其独特之处。

阶段一：Query Plan的生成与拆分。Coordinator节点收到SQL后，首先在本地完成语法解析和逻辑优化，生成单机版的Query Plan。然后，根据Distributed表引擎的配置，将这个单机Plan拆分为两部分：在每个分片上执行的子查询和最后在Coordinator上执行的合并查询。

这里的核心决策是如何下推计算。ClickHouse优先将聚合下推到每个分片执行，减少需要在网络上传输的中间结果。例如SELECT avg(amount) FROM distributed_orders，会先在每个分片上计算局部sum(amount)和count(*)，传输到Coordinator后再计算全局平均。

阶段二：节点选择与健康度评估。Distributed表引擎支持配置多副本，每个分片可能有2~3个副本节点。Coordinator需要从每个分片的副本列表中选择一个健康的节点发送子查询。ClickHouse内部维护了每个节点的连接错误计数和响应延迟统计，优先选择延迟最低的节点，并自动避开错误次数超过阈值的节点。

三、并行执行策略的调优要点

连接模式的选择。Distributed引擎支持两种分布式处理模式：local模式将查询发送到每个分片节点独立执行；global模式的GLOBAL IN和GLOBAL JOIN先将子查询的结果集广播到所有节点，再做本地关联。GLOBAL JOIN的性能陷阱在于：如果右表结果集很大，广播到所有节点的网络开销会压垮集群。

并发度的精细控制。max_distributed_connections参数控制同时向多少个分片发送子查询。默认值1024，但实际受限于max_threads和系统文件描述符数量。对于超过100个分片的大集群，建议将并发度设为分片总数的30~50%，分批发起子查询，避免瞬间的网络拥塞。

数据倾斜的处理。Distributed表的sharding_key如果选择不当，会导致某些分片数据量远超其他。在聚合查询中，数据倾斜意味着最慢的分片决定了总体查询时间。相比rand()随机分片带来的均匀分布，业务字段分片（如user_id）虽然支持高效的本地JOIN，但也引入了倾斜风险。通过监控system.query_log中每个分片的执行耗时，可以快速定位倾斜问题。

-- 分析分布式查询在各分片上的执行耗时分布 SELECT initial_query_id, shard_num(), count() as shard_rows, query_duration_ms / 1000 as duration_sec FROM cluster('my_cluster', system.query_log) WHERE query LIKE '%SELECT count()%' AND event_date >= today() - 7 GROUP BY initial_query_id, shard_num(), duration_sec ORDER BY duration_sec DESC;

四、分布式执行中的反直觉现象

现象一：增加节点不一定加速。在数据量不变的情况下，将分片从8个扩到16个，聚合查询可能变慢而不是变快。原因是：每个分片的局部聚合结果串行回传给Coordinator的开销随分片数线性增长，而计算并行度的提升边际递减。存在一个最优分片数，超过后Amdahl定律开始起作用——串行部分的代价成为瓶颈。

现象二：副本可能拖慢查询而非加速。当为分布式表配置多个副本时，Coordinator的节点选择算法可能选到一个正在进行后台Merge操作的节点，导致该分片的响应时间远超其他分片。相比轮询所有副本并取最快响应的策略，ClickHouse的选择算法偏向"避开已知故障节点"而非"选择最快节点"，在某些场景下并非最优。

现象三：本地表查询可能比分布式表更快。对于不涉及跨分片关联的简单查询，直接在本地表上执行可能比通过Distributed表引擎更快。原因是省去了Coordinator的任务分发和结果合并开销。

五、总结

ClickHouse的分布式查询执行模型体现了存储与计算分离架构的核心设计权衡：通过在Coordinator层面实现查询计划的拆分与聚合，获得了水平扩展能力，但代价是引入了数据倾斜、网络开销和并行协调的复杂度。对于运维ClickHouse集群的团队，理解Query Plan从生成到多节点并行的全链路，是进行性能调优的基础。

关键实践建议：关注分片间执行耗时的标准差而非均值、根据查询模式选择分片键和副本策略、对重大查询在EXPLAIN后检查每个分片的下推情况。