Parallel Replicas

• parallel_replicas_count 指定参与并行查询的副本数
• parallel_replicas_mode 指定数据分布方式
• sampling_key 模式使用采样键拆分数据

Parallel Replicas 是 ClickHouse 在分片内加速单表扫描的功能。parallel_replicas_count 指定一个查询要利用多少个副本（replica）并行处理；parallel_replicas_mode 决定数据如何在副本间拆分，常见的 sampling_key 模式使用表的采样键（或主键）把数据按范围划分到不同副本，每个副本只处理自己负责的数据范围，从而并行读取同一分区的数据。

该功能把「同一分片的多个副本」从「冗余备份」变成「并行计算资源」。parallel_replicas_count 越大，并发度越高，但受限于副本数量与数据量。sampling_key 模式需要表具备采样键或合理的分布键，使数据能均匀拆分，否则可能出现数据倾斜。它适用于单表大范围扫描，加速线性扩展。

• 各副本返回局部结果
• 按 ORDER BY/LIMIT/聚合语义正确合并
• 合并阶段由 coordinator 完成

Parallel Replicas 中，各副本并行执行查询并返回各自的局部结果，协调节点（coordinator）负责按查询语义合并。对于 ORDER BY，做全局排序（可用归并排序）；对于 LIMIT，需在合并后取全局前 N 行；对于聚合，各副本先做局部聚合，再对局部聚合结果做全局聚合（如 sum 再 sum、uniq 用状态合并）。合并阶段必须保证最终结果与单副本执行一致。

合并正确性是 Parallel Replicas 的难点。不同查询语义的合并方式不同：聚合需用状态合并（尤其是 uniq、quantile 等有状态聚合），ORDER BY/LIMIT 需全局归并。若合并逻辑错误，结果会失真。ClickHouse 通过把各副本的局部结果流式归并，保证语义等价。理解合并阶段是理解 Parallel Replicas 正确性的关键。

• ReplicatedMergeTree 依赖 ZooKeeper/Keeper 协调
• 副本间数据同步与协调
• Parallel Replicas 借助副本协调

Parallel Replicas 通常作用于 ReplicatedMergeTree 表，因为其多个副本天然存在。ReplicatedMergeTree 通过 ZooKeeper（或 ClickHouse Keeper）协调副本间的 part 日志、mutation 与数据同步，保证各副本数据一致。Parallel Replicas 借助这种协调机制，让查询节点知道各副本的 part 分布，从而把查询任务正确分发到各副本并行执行。

依赖 ZooKeeper 是因为副本间的一致性协调需要中心化服务。Parallel Replicas 需要知道各副本的 part 集合与数据分布，才能合理拆分查询。ZooKeeper 的可用性影响 Parallel Replicas 的可用性，因此生产上常用 ClickHouse Keeper 替代 ZooKeeper 降低运维成本。协调机制是副本一致性的基础。

• 23.3+ 版本实验/生产可用
• 单查询利用多个副本并行
• 与旧版本差异

Parallel Replicas 在 23.3 版本开始正式支持（此前为实验特性，需 allow_experimental_parallel_reading 等开关）。它让单个查询可以利用同一分片的多个副本并行处理，把原本串行扫描一个副本的任务拆分到多个副本上，从而显著加速大表扫描。该功能在 23.3+ 可以稳定使用，无需实验性开关。

23.3 是 Parallel Replicas 的重要里程碑，去掉了实验性限制。其价值在于「用副本的冗余算力换查询速度」，无需扩大分片即可加速大表扫描。但也需注意：副本数越多，ZooKeeper 协调与网络开销越大，且需数据的副本完整性。适用于单表大范围扫描、聚合查询。

• 大表全表/大范围扫描的并行化
• 副本算力复用
• 不适合小查询/点查

Parallel Replicas 尤其适合大表扫表场景，因为大表扫描是 IO/CPU 密集操作，把数据按范围拆分到多个副本并行读取，可把吞吐量线性扩展。相比单副本扫描，多个副本同时读不同数据范围，大幅缩短执行时间。它适合聚合、大范围过滤、全表统计等读取强度高的查询。

大表扫描的瓶颈在于单副本的 IO 与 CPU 带宽，Parallel Replicas 通过多副本并行突破该瓶颈。但对小查询、点查、数据量小的场景，并行协调与网络开销反而可能超过收益，收益有限。因此该功能定位为「大表扫描加速器」，需结合数据量与查询强度判断是否启用。

• 分片内跨副本并行原理
• max_parallel_replicas 配置上限
• 并发度与开销权衡

Parallel Replicas 的分片内并行查询原理是：同一分片的多副本同时参与一个查询，把该分片的数据按范围拆分到各副本并行读取，各副本返回局部结果后由协调节点合并。max_parallel_replicas 控制单查询最多利用的副本数，即并发度上限。配置权衡在于：副本数越多，并行度越高、查询越快，但 ZooKeeper 协调、网络传输与内存开销越大，且受数据量限制。

max_parallel_replicas 是并发度与开销之间的平衡点。太小则无法充分利用副本算力，太大则协调开销与资源竞争加剧，甚至因副本数据量不足而浪费。需结合数据量、副本数、查询类型与资源状况设置。通常与 parallel_replicas_count 配合，配置合理的并发度。

• Parallel Replicas：分片内副本并行
• Distributed：跨分片并行
• 两者差异与边界

Parallel Replicas 是「分片内」的并行：在同一个分片的多个副本间并行读取同一份数据，适用于单分片多副本、大表扫描加速。Distributed 表是「跨分片」的并行：把查询分发到多个分片的本地表并行执行，适用于多分片水平扩展。两者关注维度不同：Parallel Replicas 用副本冗余算力，Distributed 用分片数据拆分。数据重分布方面，Distributed 涉及分片间按 sharding_key 分配，Parallel Replicas 只在一个分片内拆分，不涉及跨分片重分布。

边界在于：若要加速单分片内的大表扫描，用 Parallel Replicas；若要跨分片并行或需要水平扩展，用 Distributed 表。二者可组合：分布式表跨分片并行，每个分片内再用 Parallel Replicas 副本并行，实现「跨分片 × 分片内」双重并行。理解两者维度差异是正确设计并行架构的关键。

• 查询按数据范围分片到同一分区的多副本
• 副本并行执行与结果合并
• 与分布式表（跨分片）的差异

Parallel Replicas 中，一个查询会基于同一分区的数据范围，把不同的数据段（range）分派给同一分区的多个副本并行执行。各副本只读取自己负责的数据段，返回局部结果，再由协调节点合并。这与分布式表不同：分布式表把查询分发到不同分片（不同数据），并行执行的是跨分片的数据；Parallel Replicas 并行的是同一分片内多个副本，处理的是同一份（冗余）数据的不同范围。

核心差异是「并行对象」：分布式表并行的是分片（数据拆分），Parallel Replicas 并行的是副本（数据冗余）。两者都需合并阶段保证语义正确。Parallel Replicas 依赖副本间的数据一致性，若副本不同步会读到不一致数据。组合使用可同时获得跨分片与副本内的并行度。

• 大表扫描/聚合可线性加速
• 单副本场景无收益
• 小查询、点查、与分布式表组合的收益有限

能线性加速的查询：大表全表/大范围扫描、对数据量大的聚合、大范围过滤等 IO/CPU 密集查询，在这些场景下多副本并行能接近线性提升吞吐。收益有限的场景：单副本（无副本可并行）、小查询与点查（协调开销大于收益）、数据量小、以及数据分布不均导致部分副本空闲。与分布式表组合时，若分片内副本数少或数据量小，Parallel Replicas 的边际收益有限。

收益取决于「是否被单副本瓶颈限制」。大表扫描被单副本 IO/CPU 限制，最受益；小查询本身很快，并行协调反成负担。单副本场景无法并行，无收益。数据倾斜会降低部分副本利用率。因此需评估数据量、副本数、查询类型后决定是否启用 Parallel Replicas。

• 同一分区数据按范围拆分到多副本
• 各副本并行读取不同数据段
• 结果合并保证语义

Parallel Replicas 把同一分区的数据按一定的数据范围（如基于主键或采样键的区间）拆分成多个数据段，每个段分派给一个副本读取。各副本并行读取自己负责的段，互不重叠，最后把各副本的局部结果合并。拆分只在同一分区内进行，不跨分区，因此同一分区的数据能同时被多个副本并行处理。

查询拆分的核心是「数据不重叠 + 并行读取 + 语义合并」。拆分粒度影响并行度与负载均衡：段越细，并行度越高，但协调与合并开销越大；段太粗则部分副本空闲。数据需均匀分布才能高效并行。拆分基于主键或采样键，保证各段可独立读取。多副本并行读取同一分区的冗余数据，是 Parallel Replicas 的核心价值。

• max_threads：每副本并行线程数
• parallel_replicas_count：参与副本数
• 总并发度 = 副本数 × 每副本线程数

一次查询的总并发度由两个维度共同决定：parallel_replicas_count 决定参与查询的副本数量，每个副本内部又按 max_threads 决定并行线程数。因此总并发度近似为「副本数 × 每副本线程数」。例如 parallel_replicas_count=2、max_threads=8，则总并发线程约 16（2 副本 × 8 线程）。但实际受数据量、CPU 核数、IO 限制，可能无法达到理论值。

两个参数分别控制「横向并行」（副本间）与「纵向并行」（副本内线程）。合理配置需平衡：副本数受副本数量与协调开销限制，每副本线程数受 CPU 核数限制。总并发度过高会导致资源竞争与调度开销，过低则无法充分利用。需结合机器资源与数据量调整。

• allow_experimental_parallel_reading 实验开关
• 副本读取的一致性与读取放大
• 读取放大：同一数据被多副本读取

早期版本用 allow_experimental_parallel_reading_from_replicas 开启实验性并行读取，23.3+ 后该功能正式化。Parallel Replicas 下，同一份数据被多个副本读取，造成读取放大（read amplification）：多个副本读取同一分区数据，总读取量是单副本的 N 倍（N 为副本数）。评估读取放大需权衡：查询速度提升 vs 集群总 IO 增加。数据量越大、副本越多，读取放大越明显。

读取放大是 Parallel Replicas 的固有代价，本质是「用冗余 IO 换查询延迟」。评估时需关注命中率与 IO 带宽：若有缓存或磁盘 IO 充足，放大可接受；否则可能拖垮集群。一致性方面，需保证各副本读取的数据版本一致，否则合并结果出错。监控可以量化读取放大与收益。

• cluster 配置中的 secret 用于认证
• 权重用于负载均衡
• 副本故障时的切换语义

Parallel Replicas 依赖集群配置，cluster 中的 secret 用于副本间认证与安全通信，权重用于控制副本承担的负载比例。当某个副本故障时，查询协调会避开故障副本，把任务分配给其他健康副本，保证查询可用性。故障切换语义：协调节点会感知副本不可用，重试或重新分配任务，避免因单副本故障导致查询失败。

集群配置的 secret 与权重影响并行查询的分配与安全。副本故障时，协调需能检测并剔除故障副本，保证查询不中断。但若故障副本过多、健康副本不足，则 Parallel Replicas 退化为普通查询或失败。权重可调整负载均衡，避免副本间负载不均。故障切换是可用性的关键保障。

• 多副本并行读（Parallel Replicas）与分布式表并行
• 两者可叠加
• 并行度维度

多副本并行读（Parallel Replicas）与分布式表并行度是正交的两个维度：分布式表把查询分发到多个分片并行（跨分片并行），Parallel Replicas 在单个分片内利用多个副本并行（分片内并行）。两者可组合：一个分布式查询跨分片并行，每个分片内再用多个副本并行，从而实现「分片 × 副本」的多维并行。

理解两个并行度维度是关键：分片维度是数据水平拆分，副本维度是数据冗余并行。组合使用时，总并行度 ≈ 分片数 × 每分片副本数。但并行度越高，协调、网络、合并开销越大，需权衡。实际配置要结合集群规模与数据量。

• 单分片多副本是 Parallel Replicas 的典型场景
• 需表为 ReplicatedMergeTree
• 副本数限制与数据一致性

单分片多副本是 Parallel Replicas 最典型的适用场景：一个分片的数据有多份副本，Parallel Replicas 利用这些副本并行读取。适用限制包括：表必须是 ReplicatedMergeTree（否则无副本可并行）、副本必须同步一致（否则读到不一致数据）、副本数决定并行度上限、数据需能均匀拆分。若副本数少或数据量小，并行收益有限。

单分片多副本场景下，Parallel Replicas 把副本从冗余备份变成并行计算资源。但前提是副本数据一致、类型为 ReplicatedMergeTree。若副本不同步或数据倾斜，并行效果差。单分片多副本是水平扩展受限时的替代方案，用于提升单分片查询性能。

• 分布式表跨分片并行
• 分片内 Parallel Replicas 副本并行
• 组合设计

组合设计：在分布式表上发起查询，分布式表把查询分发到各分片（跨分片并行）；每个分片内再启用 Parallel Replicas，让该分片的多个副本并行处理本分片数据（分片内并行）。这样实现「跨分片 × 分片内副本」的双层并行，最大化查询并行度。设计时需配置好 cluster 与分片内副本数，并保证各分片数据均匀。

组合使用的核心是「分层并行」：外层分布式表负责分片间并行，内层 Parallel Replicas 负责分片内副本并行。设计需注意：分片内副本数由 parallel_replicas_count 控制，分片数由集群决定。两者叠加提升吞吐，但协调与合并开销也叠加，需在超大查询场景下权衡。数据均匀分布是高效组合的前提。

• 各副本 parts 集合需一致
• 读取一致性保证
• 副本延迟的影响

Parallel Replicas 要求各副本的 parts 集合（数据版本）一致，否则不同副本读取的数据范围不同，合并结果会出错或遗漏。读取保证依赖副本间的数据同步：通过 ZooKeeper 协调保证各副本看到一致的 part 集合。若某副本数据滞后（parts 未同步），并行读取可能读到不一致数据。因此副本同步延迟是 Parallel Replicas 正确性的关键前提。

数据版本一致性是 Parallel Replicas 正确性的基础。各副本读取同一数据的不同范围，只有 parts 集合一致才能保证合并结果与单副本一致。副本延迟会导致读取不一致，因此需保证副本及时同步，或通过配置避免读取滞后副本。读取保证本质是「副本间数据版本一致 + 协调合并正确」。