ClickHouse分布式架构为何需要精细配置写入路由
ClickHouse单机写入性能出色，但单机存储和计算有天花板。分布式表（Distributed引擎）将数据分片到多个节点，突破单机瓶颈。分布式表本身不存储数据，只作为路由层——写入时根据分片键把数据分发到对应分片的本地表，查询时从各分片聚合结果。写入路由策略决定数据落在哪个分片，直接影响数据均衡度和查询效率。配置不当会造成数据倾斜、写入热点、查询性能退化。
ReplicatedMergeTree与Distributed引擎的关系
ClickHouse分布式表的标准架构是两层：底层每个分片使用ReplicatedMergeTree引擎实现副本高可用，顶层用Distributed引擎做路由。集群定义在config.xml中：
<remote_servers>
<analytics_cluster>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>ch-node-01</host>
<port>9000</port>
</replica>
<replica>
<host>ch-node-02</host>
<port>9000</port>
</replica>
</shard>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>ch-node-03</host>
<port>9000</port>
</replica>
<replica>
<host>ch-node-04</host>
<port>9000</port>
</replica>
</shard>
</analytics_cluster>
</remote_servers>internal_replication设为true表示ClickHouse假设副本间数据由ReplicatedMergeTree自行同步，Distributed引擎只写一个副本。设为false时Distributed引擎写入所有副本，性能差且已不推荐。
分布式表创建与分片键设计
-- 本地表（每个分片节点创建）
CREATE TABLE events_local ON CLUSTER analytics_cluster (
event_time DateTime,
event_type String,
user_id UInt64,
payload String
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}')
PARTITION BY toYYYYMM(event_time)
ORDER BY (event_type, event_time, user_id)
SETTINGS index_granularity = 8192;
-- 分布式表（任意节点创建）
CREATE TABLE events_dist ON CLUSTER analytics_cluster AS events_local
ENGINE = Distributed(analytics_cluster, currentDatabase(), events_local, rand());Distributed引擎最后一个参数是分片键。rand()表示随机写入，数据均匀分布但无法按分片键做查询裁剪。生产环境应选择业务维度的分片键：
-- 按user_id分片，查询带user_id条件时只命中对应分片
ENGINE = Distributed(analytics_cluster, currentDatabase(), events_local, user_id);分片键选择原则：高频查询条件字段优先，写入均匀分布其次。user_id是常见选择——按用户维度查询时只扫描一个分片，用户活跃度自然分散避免了写入热点。
写入路由策略：分布式表写入vs直接写本地表
通过分布式表写入是简单方案，写入请求发到任意节点，Distributed引擎负责路由。但这个方案有隐藏问题：分布式表写入会在接收节点缓存数据，后台线程异步转发到目标分片。缓存期间节点宕机数据丢失。对于写入可靠性要求高的场景，直接写本地表更稳妥：
# 写入时指定目标分片（应用层路由）
def get_shard(user_id, shard_count):
return user_id % shard_count
# 直连对应分片节点写入本地表
shard = get_shard(user_id, 2)
if shard == 0:
write_to('ch-node-01', 'events_local', data)
else:
write_to('ch-node-03', 'events_local', data)应用层直写本地表的优点：无异步转发延迟，写入即刻持久化；避免分布式表缓冲区内存压力。缺点：应用层需要感知集群拓扑，集群变更时应用需要同步调整。折中方案是引入代理层（如HAProxy），在代理层做分片路由。
数据均衡监控与修复
分片键不合理或业务流量特征变化会导致数据倾斜。通过system.parts表监控各分片数据量：
SELECT
hostName() AS node,
table,
count() AS part_count,
sum(rows) AS total_rows,
formatReadableSize(sum(bytes_on_disk)) AS total_size
FROM system.parts
WHERE table = 'events_local' AND active
GROUP BY node, table数据倾斜超过2倍时需要重新分片。ClickHouse没有自动resharding，需手动导出数据、修改分片键重新导入。因此在分片键设计阶段就要充分考虑数据增长模式，避免后期迁移。时间维度分片适合日志类数据按时间淘汰，用户维度分片适合业务数据长期保留。
原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/clickhouse-fen-bu-shi-biao-yin-qing-yu-ji-qun-xie-ru-lu-you/
