ZooKeeper 在 ClickHouse 中的核心作用

原创于 2025-09-07 07:22:13 发布 · 1k 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#zookeeper #clickhouse #分布式 #学习

OLAP 专栏收录该内容

34 篇文章

订阅专栏

在 ClickHouse 集群中，ZooKeeper（或 ClickHouse Keeper）是“集群的大脑”，它虽然不直接存储业务数据，但承担着至关重要的协调与元数据管理职责。理解它的作用，是掌握 ClickHouse 集群和复制机制的关键。

🧠 一、ZooKeeper 在 ClickHouse 中的核心作用

ZooKeeper 是一个分布式协调服务，ClickHouse 利用它来实现 多副本数据一致性、故障恢复、任务调度 等功能。

🔁 简单说：ZooKeeper 不存数据，但管“谁该做什么”。

🏗️ 二、ZooKeeper 的三大核心职责

1. 存储元数据（Metadata Storage）

ZooKeeper 存储 ClickHouse 副本的结构化元信息，包括：

元数据类型	说明
数据部分（Parts）信息	每个副本有哪些数据片段（Part）
副本状态	哪个副本是 Leader，是否在线
复制队列（Replication Queue）	待执行的操作（如写入、合并、删除）
表结构版本	表结构变更的协调
分布式 DDL 队列	`ON CLUSTER` 命令的执行记录

✅ 举例：当一个副本重启时，它会从 ZooKeeper 获取“我应该有哪些数据”，然后自动补同步。

2. 协调数据复制（Replication Coordination）

这是 ZooKeeper 最关键的作用 —— 确保多个副本之间的数据一致。

工作流程（以写入为例）：

客户端写入 Replica 1
         │
         ↓
Replica 1 将“写入任务”写入 ZooKeeper（含数据路径、校验和）
         │
         ↓
Replica 2 和 Replica 3 监听 ZooKeeper，发现新任务
         │
         ↓
Replica 2/3 从 Replica 1 P2P 下载数据块（.part）
         │
         ↓
所有副本本地应用该操作，保持数据一致

✅ 特点：

数据不经过 ZooKeeper 传输（只传指令）
实际数据通过 P2P（点对点） 在副本间传输
ZooKeeper 只负责“通知”和“协调”

3. 选举与故障恢复（Leader Election & Failover）

在 ReplicatedMergeTree 中，某些任务（如合并 Parts）需要一个“协调者”。
ZooKeeper 通过 分布式锁机制 选出一个副本作为临时 Leader。
如果 Leader 宕机，ZooKeeper 会触发重新选举，确保任务继续执行。

✅ 效果：自动故障转移，无需人工干预。

🧩 三、ZooKeeper 协调的关键操作

操作	是否通过 ZooKeeper 协调
`INSERT` 写入	✅
数据合并（Merge）	✅
分区删除（`DROP PARTITION`）	✅
表结构变更（`ALTER TABLE`）	✅
副本故障恢复	✅
`SELECT` 查询	❌（不涉及）
本地聚合计算	❌

✅ 所有影响数据一致性的操作都必须通过 ZooKeeper 协调。

📦 四、ZooKeeper 数据结构示例

ZooKeeper 中的路径结构如下：

/clickhouse/
└── tables/
    └── shard1/
        └── user_log_replicated/
            ├── metadata          → 表结构
            ├── log/              → 操作日志（写入、合并等）
            ├── leader_election   → Leader 选举
            ├── blocks/           → 数据块唯一性检查
            └── replicas/
                ├── replica1.clickhouse.com/
                │   ├── parts/    → 该副本的数据片段列表
                │   └── queue/    → 待执行任务队列
                └── replica2.clickhouse.com/
                    ├── parts/
                    └── queue/

✅ 每个副本独立维护自己的 queue，从 log 中拉取任务。

🔁 五、ZooKeeper vs ClickHouse Keeper

对比项	ZooKeeper	ClickHouse Keeper
类型	独立的分布式协调服务	ClickHouse 内置的替代品（v21+）
部署	需单独部署 3~5 节点	内嵌在 ClickHouse 中，可独立运行
协议	ZAB	自研 Raft 协议
配置	外部管理	在 `config.xml` 中定义
维护成本	较高（需监控、调优）	更低，与 ClickHouse 统一运维
性能	稳定	接近 ZooKeeper，更轻量

✅ 新集群推荐使用 ClickHouse Keeper，老集群可继续使用 ZooKeeper。

⚠️ 六、ZooKeeper 的注意事项

问题	建议
必须高可用	至少 3 节点，避免单点故障
网络延迟敏感	ZooKeeper 与 ClickHouse 节点应低延迟（同机房）
不要过载	避免过多表共用同一 ZooKeeper 集群
监控关键指标	`queue_size`, `delay`, `is_session_expired`
路径唯一性	每个 `ReplicatedMergeTree` 表必须有唯一 ZooKeeper 路径

📊 七、如何监控 ZooKeeper 对 ClickHouse 的影响？

1. 查看副本状态

SELECT 
    table,
    queue_size,           -- 待处理任务数（积压）
    absolute_delay,       -- 同步延迟（秒）
    is_session_expired    -- 是否与 ZooKeeper 断开
FROM system.replicas 
WHERE database = 'default';

✅ 健康状态：queue_size ≈ 0, absolute_delay < 10, is_session_expired = 0

2. 检查 ZooKeeper 自身状态

echo stat | nc zookeeper-host 2181

输出包含：

客户端连接数
延迟（Latency）
是否 Leader/Follower

🎯 八、总结：ZooKeeper 的核心价值

能力	说明
🧩 元数据中枢	存储副本状态、数据片段、操作日志
🔄 复制协调器	确保多副本数据一致
🗳️ 选举机制	自动选主，实现故障转移
🛠️ 分布式锁	防止并发冲突（如重复合并）
📦 轻量指令通道	不传数据，只传“做什么”