ClickHouse集群部署【从零搭建到高可用】

Lindsay Zou

1. ClickHouse集群部署前的思考

第一次接触ClickHouse集群部署时，我被它惊人的查询性能所震撼，但同时也被复杂的配置过程搞得焦头烂额。记得当时为了搭建一个三节点的生产环境，整整折腾了一个周末。现在回想起来，如果能提前了解这些关键点，至少能节省80%的时间。

ClickHouse集群的核心在于**分片(Shard)和副本(Replica)**的设计。分片解决数据水平扩展问题，副本则保障高可用性。想象一下，这就像把一本厚厚的电话簿拆成多册（分片），每册又复印几份（副本）存放在不同地方。当需要找人时，可以同时查阅多册；当某册丢失时，还能用它的复印件顶上。

对于初创公司处理海量实时数据的场景，我建议至少准备4台物理服务器：

2台作为ClickHouse数据节点（建议配置32核CPU+128GB内存+NVMe SSD）
1台作为ZooKeeper协调节点（16核CPU+64GB内存足够）
1台作为监控/管理节点

提示：生产环境千万不要把ZooKeeper和ClickHouse装在同一台机器，我曾因此遭遇过性能雪崩

2. 基础环境准备

2.1 操作系统优化

在CentOS 7上实测发现，默认内核参数会严重制约ClickHouse性能。这是我优化过的/etc/sysctl.conf配置：

bash复制# 增加文件描述符限制
fs.file-max = 1000000

# 内存相关优化
vm.swappiness = 1
vm.dirty_ratio = 20
vm.dirty_background_ratio = 10

# 网络优化
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 1024
net.core.somaxconn = 2048

执行sysctl -p生效后，别忘了设置用户限制。在/etc/security/limits.conf中添加：

code复制clickhouse soft nofile 262144
clickhouse hard nofile 262144

2.2 安装最新稳定版

官方仓库的版本往往滞后，我推荐直接用下面的方式安装最新稳定版：

bash复制sudo yum install -y yum-utils
sudo rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPG
sudo yum-config-manager --add-repo https://repo.clickhouse.tech/rpm/stable/x86_64
sudo yum install -y clickhouse-server clickhouse-client

安装完成后，先别急着启动。有次我直接启动服务，结果默认配置把32核机器全部用满，直接导致SSH都连不上。正确的做法是先调整/etc/clickhouse-server/config.xml中的资源限制：

xml复制<max_server_memory_usage_to_ram_ratio>0.7</max_server_memory_usage_to_ram_ratio>
<max_concurrent_queries>100</max_concurrent_queries>

3. ZooKeeper集群配置

3.1 三节点部署

ClickHouse的副本同步完全依赖ZooKeeper，这是整个集群最脆弱的环节。我吃过亏后总结出黄金法则：ZooKeeper节点数必须是奇数，且至少3个。这是最小可用的配置示例（/etc/zookeeper/conf/zoo.cfg）：

properties复制tickTime=2000
initLimit=10
syncLimit=5
dataDir=/var/lib/zookeeper
clientPort=2181
server.1=zk1:2888:3888
server.2=zk2:2888:3888
server.3=zk3:2888:3888

每个节点需要创建myid文件：

bash复制echo "1" > /var/lib/zookeeper/myid  # 在zk1上执行
echo "2" > /var/lib/zookeeper/myid  # 在zk2上执行
echo "3" > /var/lib/zookeeper/myid  # 在zk3上执行

3.2 监控与调优

ZooKeeper监控常被忽视，直到出现脑裂问题才追悔莫及。建议在每个节点部署以下监控项：

通过echo mntr | nc localhost 2181获取关键指标
设置watch数报警（超过5000就危险）
监控延迟：zk_ping应小于50ms

遇到同步问题时，可以尝试调整：

properties复制# 增加超时容错
tickTime=4000
initLimit=20

# 优化JVM参数
export JVMFLAGS="-Xms4G -Xmx4G -XX:+UseG1GC"

4. ClickHouse集群配置实战

4.1 分片与副本设计

假设我们有两台数据节点（ch01, ch02），想要实现分片+副本的高可用架构。关键配置在/etc/clickhouse-server/config.d/remote_servers.xml：

xml复制<yandex>
    <remote_servers>
        <my_cluster>
            <shard>
                <replica>
                    <host>ch01</host>
                    <port>9000</port>
                </replica>
                <replica>
                    <host>ch02</host>
                    <port>9000</port>
                </replica>
            </shard>
            <shard>
                <replica>
                    <host>ch02</host>
                    <port>9000</port>
                </replica>
                <replica>
                    <host>ch01</host>
                    <port>9000</port>
                </replica>
            </shard>
        </my_cluster>
    </remote_servers>
</yandex>

这种互为主备的"环形复制"设计，既能实现数据分片，又确保每个分片有两个副本。我在电商公司就用这种方案扛住了双11流量。

4.2 分布式表引擎

配置好集群后，需要通过Distributed表引擎来使用它。创建示例：

sql复制CREATE TABLE db.local_table ON CLUSTER my_cluster (
    id UInt32,
    event_time DateTime,
    user_id String
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/local_table', '{replica}')
ORDER BY (event_time, user_id);

CREATE TABLE db.dist_table AS db.local_table
ENGINE = Distributed(my_cluster, db, local_table, rand());

这里有几个坑要注意：

ReplicatedMergeTree路径中的{shard}和{replica}必须使用变量
ON CLUSTER语法需要提前配置好集群通信
分布式查询的负载均衡策略要慎重选择

5. 高可用验证与故障处理

5.1 模拟节点故障

真正的生产环境必须经过故障演练。我常用的测试方法：

bash复制# 随机杀死一个节点进程
ssh ch01 "sudo systemctl stop clickhouse-server"

# 观察查询是否自动路由到健康节点
clickhouse-client --query "SELECT count() FROM db.dist_table"

# 检查副本同步状态
SELECT database, table, is_leader, is_readonly 
FROM system.replicas
WHERE is_readonly = 1;

5.2 数据一致性检查

副本间数据不一致是最危险的情况。这个查询能帮你快速发现问题：

sql复制SELECT 
    database,
    table,
    absolute_delay,
    replica_is_active
FROM system.replicas
WHERE absolute_delay > 60;  # 延迟超过60秒视为异常

遇到不一致时，我通常先用SYSTEM SYNC REPLICA db.local_table尝试修复，如果无效再考虑重建副本。

6. 性能调优实战技巧

6.1 内存管理

ClickHouse默认会贪婪地占用所有内存。这是我验证过的生产配置（/etc/clickhouse-server/users.xml）：

xml复制<profiles>
    <default>
        <max_memory_usage>10000000000</max_memory_usage> <!-- 10GB -->
        <max_bytes_before_external_sort>5000000000</max_bytes_before_external_sort>
        <max_threads>16</max_threads>
    </default>
</profiles>

6.2 查询优化

分布式查询常见性能问题多源于网络传输。通过EXPLAIN能发现潜在问题：

sql复制EXPLAIN PIPELINE
SELECT user_id, count()
FROM db.dist_table
GROUP BY user_id
SETTINGS distributed_group_by_no_merge = 1;

看到Converting阶段特别耗时？可以尝试：

增加distributed_aggregation_memory_efficient设置
使用GLOBAL IN代替JOIN
调整max_bytes_in_join和join_algorithm

7. 监控与告警体系

7.1 Prometheus监控

这是我在用的scrape_config配置：

yaml复制scrape_configs:
  - job_name: 'clickhouse'
    static_configs:
      - targets: ['ch01:9363', 'ch02:9363']
    metrics_path: '/metrics'
  - job_name: 'zk'
    static_configs:
      - targets: ['zk1:7000', 'zk2:7000', 'zk3:7000']

关键监控指标：

ClickHouse: Query, ReplicatedPartChecks, Merge
ZooKeeper: znode_count, avg_latency, outstanding_requests

7.2 关键告警规则

这些规则帮我多次避免了生产事故：

yaml复制groups:
- name: clickhouse-alert
  rules:
  - alert: ClickHouseReplicasNotActive
    expr: sum(clickhouse_metric_ReplicasMaxAbsoluteDelay) by (instance) > 300
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "ClickHouse replica delay too high on {{ $labels.instance }}"

8. 备份与灾难恢复

8.1 增量备份策略

我设计的时间点恢复方案：

sql复制CREATE TABLE db.backup_log (
    backup_time DateTime,
    backup_type String,
    path String
) ENGINE = MergeTree()
ORDER BY backup_time;

BACKUP TABLE db.local_table 
TO Disk('backup_disk', '20230715/')
SETTINGS base_backup = '20230714/';

8.2 跨集群同步

当需要迁移数据时，这个命令比INSERT SELECT高效得多：

bash复制clickhouse-client --query "SELECT * FROM db.local_table" \
| clickhouse-client --host=new_cluster --query "INSERT INTO db.local_table FORMAT TSV"

配合--max_insert_block_size=500000参数，我曾在30分钟内迁移了2TB数据。