ClickHouse的分布式表引擎选择，核心就三个：Distributed、ReplicatedMergeTree（配合分布式查询）、以及基于MaterializedView的手动分片方案。如果你是刚搭建ClickHouse集群，最直接的答案就是用Distributed引擎作为查询层，底层每个节点用ReplicatedMergeTree保证数据同步，这是目前生产环境最主流、最稳妥的架构。别纠结太多，先把这个组合跑起来，再根据业务场景微调分片策略和副本数。

很多人一上来就问"ClickHouse分布式表引擎怎么选"，其实这个问题要拆开看。ClickHouse本身不是一个天然的分布式数据库，它是一个单机性能极强的列式数据库，分布式能力是通过"表引擎"这个机制叠加上去的。所以你选的不是"一个分布式引擎"，而是选一套分布式架构方案。下面我把几种主流方案逐个拆解，讲清楚适用场景、优缺点和具体配置方法。

一、Distributed引擎：最标准的分布式查询方案

Distributed是ClickHouse官方提供的分布式表引擎，它本身不存储数据，只是一个"代理层"或者叫"路由层"。你在某个节点上创建一张Distributed表，它会把查询请求自动分发到集群中所有（或指定）节点上执行，然后把结果汇总返回。这是最经典的用法。

具体怎么建表？语法很简单：

CREATE TABLE default.distributed_log ON CLUSTER my_cluster
(
    event_date Date,
    user_id UInt64,
    event_type String,
    value Float64
)
ENGINE = Distributed(my_cluster, default, local_log, rand());

这里面几个参数要理解清楚：第一个参数my_cluster是集群名称，在config.xml里定义的；第二个参数default是远程数据库名；第三个参数local_log是每个节点上实际存储数据的本地表名；第四个参数rand()是分片键，决定数据往哪个节点写。

Distributed引擎的优点很明显：配置简单、官方支持、查询自动并行、对应用透明。缺点也有：它依赖本地表的存在，如果本地表挂了或者数据不一致，查询就会出问题。而且它不保证数据写入时的强一致性，只是"尽力分发"。

二、ReplicatedMergeTree：分布式存储的基石

严格来说，ReplicatedMergeTree不是分布式表引擎，它是一个带副本同步能力的本地表引擎。但它是构建ClickHouse分布式架构的地基，没有它，Distributed就是空中楼阁。

ReplicatedMergeTree通过ZooKeeper（或ClickHouse Keeper）来协调多个副本之间的数据同步。每个节点上都有一份完整的数据副本，写入时先写本地，再通过ZooKeeper通知其他副本拉取最新数据块。

建表示例：

CREATE TABLE default.local_log ON CLUSTER my_cluster
(
    event_date Date,
    user_id UInt64,
    event_type String,
    value Float64
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/local_log', '{replica}')
PARTITION BY toYYYYMM(event_date)
ORDER BY (user_id, event_date)
TTL event_date + INTERVAL 90 DAY;

这里的ZooKeeper路径包含了{shard}和{replica}宏，用来区分不同分片和副本。PARTITION BY和ORDER BY决定了数据的物理组织方式，直接影响查询性能。TTL是数据过期策略，生产环境一定要配，不然磁盘会爆。

ReplicatedMergeTree的核心价值在于：高可用。任何一个节点挂了，其他节点还有完整数据，查询不中断。但要注意，它的副本同步是异步的，极端情况下可能有短暂的数据不一致窗口。

三、Distributed + ReplicatedMergeTree：生产环境黄金组合

把上面两个组合起来，就是目前ClickHouse集群最主流的架构：每个节点上建ReplicatedMergeTree本地表负责存储，再建一张Distributed表负责统一查询入口。应用层只需要连接任意一个节点，对Distributed表发查询，ClickHouse自动完成分发和聚合。

这个方案的架构图逻辑是这样的：

应用层 → Distributed表（任意节点） → 分发到各节点 → ReplicatedMergeTree本地表（各节点独立查询） → 结果汇总返回

为什么说这是黄金组合？因为它兼顾了查询便利性和数据可靠性。Distributed解决了"怎么查"的问题，ReplicatedMergeTree解决了"数据怎么存"的问题。而且ClickHouse 22.x以后的版本对这个组合做了大量优化，查询计划下推、本地表预聚合都支持得很好。

四、分片键（Sharding Key）怎么选才对

分布式表引擎选好了，分片键选错，性能直接打折。ClickHouse的分片键决定了数据往哪个节点写、查询时哪些节点需要参与。选分片键的核心原则是：让查询尽可能只命中少量节点。

常用的分片策略有这么几种：

第一种，rand()随机分片。适合写入均匀、查询不带过滤条件或者过滤条件覆盖全表的场景。优点是写入压力均匀，缺点是任何查询都要扫所有节点。

第二种，按日期或时间范围分片。比如用toYYYYMM(event_date)作为分片键，同一月份的数据落在同一个节点。适合时间序列数据，按时间范围查询时只需要命中一个节点。但如果查询跨月，就要扫多个节点。

第三种，按业务ID哈希分片。比如用user_id的哈希值取模。适合按用户维度查询的场景，同一个用户的数据在同一个节点，查询效率高。但要注意数据倾斜问题，如果某个用户数据量特别大，对应节点会成为热点。

实际生产中，很多团队用的是组合策略：先按时间做分区（PARTITION BY），再用rand()或哈希做分片。这样既能利用分区裁剪减少扫描量，又能保证写入均匀。

五、MaterializedView方案：手动分片的替代思路

除了Distributed引擎，还有一种老派但依然有效的方案：用MaterializedView手动实现数据分发。思路是在每个节点上建一张本地表，然后用MaterializedView把写入的数据按规则路由到对应节点的本地表。

这种方案的好处是：你对数据分布有完全的控制权，可以实现非常精细的分片逻辑。坏处是：配置复杂、维护成本高、扩容麻烦。现在除非有特殊需求（比如跨集群同步、多活架构），一般不推荐作为首选。

六、集群规模和副本数怎么定

选好了引擎和分片策略，还得定集群规模。这里给几个实操建议：

副本数方面，生产环境建议至少2副本，重要业务3副本。副本数越多，数据越安全，但写入性能会下降，因为每个写入都要同步到多个节点。2副本是性价比最高的选择。

节点数方面，小规模场景（日增量几十GB以内）3-5个节点足够。中等规模（日增量几百GB）建议8-12个节点。大规模场景要考虑分片数和副本数的平衡，别把所有鸡蛋放一个篮子里。

还有一个容易忽略的点：Distributed表本身也可以设置副本数。如果你的Distributed表指定了多个副本节点，查询时会优先选择本地副本，减少网络开销。这个细节很多人不知道，但对性能影响不小。

七、几个容易踩的坑和避坑指南

第一，别把Distributed表和本地表搞混。Distributed表不存数据，删了它不影响本地数据，但删了本地表，Distributed表就废了。很多人运维时误删本地表，导致查询全部报错。

第二，ZooKeeper（或Keeper）是命脉。ReplicatedMergeTree依赖它做副本同步，如果ZooKeeper集群出问题，副本同步会中断，数据一致性无法保证。一定要给ZooKeeper单独部署高可用集群，别和ClickHouse节点混在一起。

第三，分片键一旦定了就很难改。ClickHouse不支持在线改分片键，改了就要重新建表、重新导入数据。所以前期设计一定要想清楚，宁可多花时间做压测和评估，也别上线后才发现分片不合理。

第四，注意网络带宽。分布式查询意味着节点之间要传输大量中间结果，如果节点之间是千兆网络而不是万兆，查询性能会被网络瓶颈卡住。生产环境节点间通信建议万兆起步。

第五，监控要到位。每个节点的磁盘使用率、副本同步延迟、查询队列长度都要监控。ClickHouse自带的system表和Prometheus exporter都能用，别等磁盘满了才发现问题。

八、总结：怎么选，一张表说清楚

如果你是新项目起步，直接用Distributed + ReplicatedMergeTree，2副本起步，分片键用rand()或者按业务哈希，先跑起来再说。如果你是时间序列场景为主，分片键按时间范围走，配合PARTITION BY效果更好。如果你有跨集群、多活之类的特殊需求，再考虑MaterializedView方案。引擎选择不是一次性的决定，而是随着业务增长不断调优的过程。先把基础架构搭稳，再根据实际查询模式和数据量做针对性优化，这才是正确的路子。