当前位置：首页 > news >正文

ClickHouse 分布式表：从分片路由到副本同步，列式存储的分布式查询引擎

news 2026/7/1 4:53:32

ClickHouse 分布式表：从分片路由到副本同步，列式存储的分布式查询引擎

一、单机瓶颈与跨节点聚合：OLAP 查询的横向扩展困境

ClickHouse 以单机查询性能著称，但在实际生产中，单机容量很快成为瓶颈。一张日增 5 亿行的日志表，单机存储在 3-6 个月内就会触及磁盘上限；而跨时间范围的聚合查询（如 90 天留存分析）需要扫描数十亿行数据，单机的 CPU 和内存带宽无法在可接受的时间内完成。

分布式表是 ClickHouse 横向扩展的核心机制，但它的"分布式"与传统数据库的分布式有本质区别——ClickHouse 的分布式表不存储数据，它只是一个查询路由层，将查询分发到各分片的本地表上并行执行，再在发起节点上汇总结果。这种架构简洁但暗藏陷阱：数据写入的幂等性、副本同步的延迟、分布式 JOIN 的性能，都需要在存储引擎层面深入理解才能正确使用。

二、分片键、本地表与 Distributed 引擎：查询路由的底层机制

ClickHouse 分布式表的查询执行流程，需要从 Distributed 引擎的内部机制理解。

flowchart TB Client[客户端查询] --> DistTable[Distributed 表<br/>查询路由层] DistTable --> Shard1[分片 1<br/>本地表 on ch-node-01] DistTable --> Shard2[分片 2<br/>本地表 on ch-node-02] DistTable --> Shard3[分片 3<br/>本地表 on ch-node-03] Shard1 --> Replica1_1[副本 1<br/>ch-node-01:9000] Shard1 --> Replica1_2[副本 2<br/>ch-node-04:9000] Shard2 --> Replica2_1[副本 1<br/>ch-node-02:9000] Shard2 --> Replica2_2[副本 2<br/>ch-node-05:9000] Shard3 --> Replica3_1[副本 1<br/>ch-node-03:9000] Shard3 --> Replica3_2[副本 2<br/>ch-node-06:9000] Replica1_1 --> LocalResult1[分片 1 局部结果] Replica2_1 --> LocalResult2[分片 2 局部结果] Replica3_1 --> LocalResult3[分片 3 局部结果] LocalResult1 --> Merge[发起节点结果合并] LocalResult2 --> Merge LocalResult3 --> Merge Merge --> FinalResult[最终结果] style DistTable fill:#e1f5fe style Merge fill:#fff3e0

Distributed 引擎的工作原理：当查询命中分布式表时，ClickHouse 的执行步骤如下：

分片裁剪：若查询条件包含分片键（sharding_key），ClickHouse 会计算分片键的哈希值，确定数据所在分片，跳过不相关分片。若查询不包含分片键，则广播到所有分片。
副本选择：每个分片有多个副本时，ClickHouse 根据负载均衡策略（随机、轮询、最短队列）选择一个副本执行查询。默认策略为随机选择。
本地执行：各分片在本地表上独立执行查询，生成局部结果。
结果合并：发起节点收集所有分片的局部结果，执行最终的聚合、排序和 LIMIT 操作。

分片键的选择是分布式表设计中最关键的决策。分片键决定了数据在各分片上的分布方式，直接影响查询裁剪效率和数据倾斜程度。常用的分片键策略：

随机分片（rand()）：数据均匀分布，但无法做分片裁剪，所有查询都广播。适用于无明确查询维度的场景。
哈希分片（intHash32(user_id)）：按用户 ID 哈希分片，同一用户的数据在同一分片，支持按用户 ID 裁剪。适用于用户维度的分析查询。
时间分片（toYYYYMM(event_date)）：按月分片，支持按时间范围裁剪。适用于时间序列数据，但可能导致热点分片（当月数据集中在单个分片）。

三、生产级分布式表配置与数据写入实践

以下展示一个完整的生产级 ClickHouse 分布式表配置，包含分片定义、副本配置、写入策略和查询优化：

-- ============================================================ -- 第一步：定义集群拓扑（在 config.xml 或 metrika.xml 中配置） -- 以下为等价的 DDL 方式定义（ClickHouse 21.3+ 支持） -- ============================================================ -- 集群定义：3 分片 x 2 副本 -- 实际生产中在 /etc/clickhouse-server/config.d/cluster.xml 配置 -- <cluster_3s2r> -- <shard> -- <replica><host>ch-node-01</host><port>9000</port></replica> -- <replica><host>ch-node-04</host><port>9000</port></replica> -- </shard> -- <shard> -- <replica><host>ch-node-02</host><port>9000</port></replica> -- <replica><host>ch-node-05</host><port>9000</port></replica> -- </shard> -- <shard> -- <replica><host>ch-node-03</host><port>9000</port></replica> -- <replica><host>ch-node-06</host><port>9000</port></replica> -- </shard> -- </cluster_3s2r> -- ============================================================ -- 第二步：创建本地表（ReplicatedMergeTree） -- 每个分片的每个副本上都需要创建 -- ============================================================ CREATE TABLE IF NOT EXISTS event_log_local ON CLUSTER 'cluster_3s2r' ( event_date Date DEFAULT toDate(event_timestamp), event_timestamp DateTime64(3, 'Asia/Shanghai'), event_id String, user_id UInt64, event_type LowCardinality(String), -- 低基数字符串，字典压缩 event_source LowCardinality(String), payload String, duration_ms UInt32 DEFAULT 0, -- 使用 Materialized 列预计算常用聚合维度 event_hour UInt8 MATERIALIZED toHour(event_timestamp), is_error UInt8 MATERIALIZED if(event_type IN ('error', 'crash', 'timeout'), 1, 0) ) ENGINE = ReplicatedMergeTree( '/clickhouse/tables/{shard}/event_log_local', '{replica}' ) PARTITION BY toYYYYMM(event_date) -- 分区内排序键：高频过滤字段在前，低频在后 ORDER BY (event_type, user_id, event_timestamp) -- 稀疏索引粒度：默认 8192，高基数字段可调小 SETTINGS index_granularity = 8192, -- 允许复制延迟的最大块数，超过则拒绝查询 max_replica_delay_for_distributed_queries = 300, -- 副本间的数据同步模式：异步（性能优先） replicated_deduplication_window = 1000; -- ============================================================ -- 第三步：创建分布式表（查询路由层） -- ============================================================ CREATE TABLE IF NOT EXISTS event_log_dist ON CLUSTER 'cluster_3s2r' ( event_date Date, event_timestamp DateTime64(3, 'Asia/Shanghai'), event_id String, user_id UInt64, event_type LowCardinality(String), event_source LowCardinality(String), payload String, duration_ms UInt32, event_hour UInt8, is_error UInt8 ) ENGINE = Distributed( 'cluster_3s2r', 'default', 'event_log_local', -- 分片键：按 user_id 哈希，支持按用户维度裁剪 intHash32(user_id) ) SETTINGS -- 副本选择策略：随机（默认） -- 可选：in_order（按配置顺序）、first_or_random、local_hostname load_balancing = 'random', -- 发起节点优先选择本地副本，减少网络传输 prefer_localhost_replica = 1; -- ============================================================ -- 第四步：数据写入策略 -- ============================================================ -- 方案 A：写入分布式表（简单但有陷阱） -- ClickHouse 会将数据暂存在本地目录，异步转发到对应分片 -- 优点：客户端无需感知分片逻辑 -- 缺点：本地暂存目录可能膨胀、写入非原子性、重复写入风险 INSERT INTO event_log_dist (event_timestamp, event_id, user_id, event_type, event_source, payload, duration_ms) VALUES ('2025-06-30 10:30:00.123', 'evt-001', 12345, 'click', 'web', '{"page":"/home"}', 45), ('2025-06-30 10:30:01.456', 'evt-002', 67890, 'error', 'api', '{"code":500}', 1200); -- 方案 B：写入本地表（生产推荐） -- 客户端根据分片键计算目标分片，直接写入对应分片的本地表 -- 优点：写入原子性、无暂存目录膨胀、可精确控制写入路由 -- 缺点：客户端需要实现分片路由逻辑 INSERT INTO event_log_local (event_timestamp, event_id, user_id, event_type, event_source, payload, duration_ms) VALUES ('2025-06-30 10:30:00.123', 'evt-001', 12345, 'click', 'web', '{"page":"/home"}', 45); -- ============================================================ -- 第五步：查询优化实践 -- ============================================================ -- 优化 1：利用分片键裁剪（仅扫描 user_id 所在分片） SELECT event_type, count() AS event_count, avg(duration_ms) AS avg_duration FROM event_log_dist WHERE user_id = 12345 AND event_date >= '2025-06-01' GROUP BY event_type ORDER BY event_count DESC; -- 优化 2：分布式查询的 max_parallel_replicas -- 启用后，同一分片的多个副本并行执行查询，提升扫描速度 SET max_parallel_replicas = 2; SELECT toStartOfHour(event_timestamp) AS hour_slot, count() AS total_events, sum(is_error) AS error_count FROM event_log_dist WHERE event_date BETWEEN '2025-06-01' AND '2025-06-30' GROUP BY hour_slot ORDER BY hour_slot; -- 优化 3：避免分布式 JOIN（性能杀手） -- 反模式：两个分布式表直接 JOIN -- SELECT * FROM dist_a JOIN dist_b ON dist_a.id = dist_b.id; -- 极慢！ -- 正确做法：使用本地表 JOIN + 分布式表聚合 SELECT a.event_type, count() AS cnt FROM default.event_log_local AS a INNER JOIN default.user_profile_local AS b ON a.user_id = b.user_id WHERE b.user_tier = 'premium' AND a.event_date = today() GROUP BY a.event_type; -- ============================================================ -- 第六步：副本健康检查与数据一致性验证 -- ============================================================ -- 检查各分片副本同步状态 SELECT database, table, is_leader, is_readonly, absolute_delay, -- 副本落后的秒数 queue_size, -- 待同步的块数 inserts_in_queue -- 待同步的 INSERT 块数 FROM system.replicas WHERE table = 'event_log_local' ORDER BY absolute_delay DESC; -- 验证各分片数据行数一致性 SELECT hostName() AS node, count() AS row_count FROM clusterAllReplicas('cluster_3s2r', default.event_log_local) GROUP BY node ORDER BY node;

写入策略的选择是生产环境中最关键的决策。方案 A（写入分布式表）虽然简单，但存在三个隐患：本地暂存目录（默认/var/lib/clickhouse/data/_temporary_and_dictionaries/staging/）在写入高峰期可能膨胀到数十 GB；异步转发过程中节点故障会导致数据丢失；重复写入（网络超时后客户端重试）会产生重复数据。方案 B（直接写入本地表）是生产推荐方案，但需要客户端或中间件层实现分片路由——根据intHash32(user_id) % shard_count计算目标分片。

四、分布式表的性能陷阱与架构边界

ClickHouse 分布式表的设计哲学是"简单至上"，但这种简洁性带来了明确的边界条件：

分布式 JOIN 的性能灾难。两个分布式表 JOIN 时，ClickHouse 需要将右表数据广播到所有分片，网络传输量等于右表大小乘以分片数。对于大表 JOIN，这可能导致网络带宽成为瓶颈。解决方案是：将小表转换为字典（Dictionary），在各节点本地完成 JOIN；或使用 Colocate JOIN（确保 JOIN 键与分片键一致，避免数据重分布）。

副本同步延迟的查询影响。ReplicatedMergeTree 的副本同步是异步的，在高写入速率下，副本可能落后主副本数秒到数分钟。如果查询命中了延迟副本，可能读到过期数据。通过max_replica_delay_for_distributed_queries设置最大允许延迟，超过延迟的副本会被排除在查询之外——但这会降低查询的并行度和可用性。

分片再均衡的缺失。ClickHouse 不支持在线分片再均衡。当数据分布倾斜时（如某个 user_id 范围的数据量远超其他），无法通过在线迁移数据来均衡负载。唯一的解决方案是新建一个分片键不同的集群，通过 INSERT SELECT 迁移数据，然后切换查询路由。这个过程需要停写或双写，运维成本极高。

ALTER TABLE 的分布式执行风险。在集群上执行 ALTER TABLE 时，如果某个分片执行失败，其他分片可能已经完成变更，导致集群元数据不一致。ClickHouse 的ON CLUSTERDDL 不是原子的——它逐个分片执行，没有分布式事务保证。生产环境中建议通过 ZooKeeper 的 DDL 队列机制（distributed_ddl配置）确保 DDL 的最终一致性，但仍需监控执行状态。

五、总结

ClickHouse 分布式表的架构本质是"查询路由层 + 本地表"的分离设计。Distributed 引擎不存储数据，仅负责查询分发与结果合并，这种设计简洁但要求使用者深入理解其边界。分片键的选择决定了查询裁剪效率，写入策略（分布式表 vs 本地表）决定了数据一致性和可靠性，副本同步延迟影响查询时效性。生产环境的核心建议是：写入走本地表、查询走分布式表、JOIN 用字典替代、分片键按查询维度选择。ClickHouse 的分布式不是传统数据库的分布式事务，而是"尽力而为"的最终一致——理解这一点，才能避免在分布式表上构建超出其能力边界的业务逻辑。

查看全文

http://www.jsqmd.com/news/1100328/