部署 ClickHouse 之前，最常被问的三个问题：选哪个版本？两节点还是四节点？每台机器配多大？本文给出一套经过实际验证的部署方案与容量估算方法，双方案对比直接可抄。

一、版本选择

• ClickHouse 版本：22.10.1.1877
• 兼容性：ARM 麒麟 V10 和 x86 架构均已验证可用

选这个版本的理由：在 ARM 麒麟 V10 环境下稳定运行过完整业务周期，且能保证 ARM 和 x86 平台的指令与 API 一致性。国产化环境部署 ClickHouse 最怕的就是版本兼容坑，一个验证过的版本能省掉大量排查时间。

二、写入需求怎么估

容量规划从写入量开始，方法是当前实际值 × 增长预留：

• 当前实际写入：500KB/s
• 预留 20 倍增长空间应对突发峰值：10MB/s
• 期望集群写入上限：30MB/s

也就是说，集群按 10MB/s 的常态写入设计、30MB/s 的峰值兜底设计，日常负载率控制在三分之一以内，给业务增长留足余量。

三、两种架构方案

3.1 两节点方案（单分片双副本）

结构：3 台 ZooKeeper + 2 台 ClickHouse。

• 数据写入 CH Node1（Shard1-Replica1）
• Node1 通过 ZooKeeper 通知数据变化
• CH Node2（Shard1-Replica2）感知变化后从 Node1 刷新副本数据

每个 ClickHouse 节点配置：8 核 CPU / 32GB 内存 / 200GB SSD 系统盘 / 4TB SATA SSD 数据盘 / 万兆网卡。

ZooKeeper 节点可以砍到很小：2 核 / 4GB 内存 / 50GB SSD / 千兆网卡，3 台共 6 核 12GB。

总资源需求：CPU 16 核、内存 64GB、存储 8TB（双副本后可用 4TB）。

3.2 四节点方案（双分片双副本）

结构：3 台 ZooKeeper + 4 台 ClickHouse，4 个 CH 节点组成 2 个分片、每分片 2 副本。

• 写入可以打到 Shard1 和 Shard2 两个分片，实现写入负载均衡
• 副本同步逻辑与两节点方案相同，只是并行了两份
• 跨分片查询可并行执行，查询性能更好

ClickHouse 节点配置与两节点方案相同（8C/32G/4TB），ZooKeeper 适当放大到 4 核 8GB。

总资源需求：CPU 32 核、内存 128GB、存储 8TB（双副本后可用 4TB）。

四、方案对比与选型建议

维度	两节点方案	四节点方案
写入性能	15-20MB/s	30-40MB/s
可用性	99.9%，节点故障影响全部数据	99.99%，节点故障只影响部分数据
成本	基准（约四节点的 55%）	约为两节点的 180%
扩展性	受限，增长后需整体迁移	加分片即可横向扩展
运维复杂度	低，小团队可维护	高，需管理更多节点和副本协调

选型经验：

• 月增量 500GB 以下、写入小于 10MB/s、预算有限、团队小 → 两节点
• 月增量超 1TB、写入大于 10MB/s、需要高并发查询、后续要扩展 → 四节点

一个容易忽略的点：两节点方案虽然写入弱，但节点间同步延迟小，对数据一致性敏感的场景反而更稳。

五、单节点配置的评估依据

8 核怎么来的：

用途	核数
写入处理	2 核
查询处理	4 核
系统开销	1 核
预留	1 核

32GB 内存怎么来的：

用途	内存
数据缓存（活跃数据）	16GB
写入缓冲	8GB
查询缓存	4GB
系统开销	2GB

六、存储容量估算实例

按"流水数据保留 6 个月、聚合数据保留 1 年"的策略估算：

项目	容量
流水数据（6 个月）	2.6TB
小时聚合（1 年）	433GB
天聚合（1 年）	3.6GB
索引开销（约 20%）	608GB
系统开销（约 10%）	304GB
预留空间（35%）	1.38TB
合计	约 5.47TB

这套算法的关键是三个系数：索引开销按 20%、系统开销按 10%、预留按 35%。预留给到 35% 是因为 ClickHouse 的 merge 过程需要临时空间，磁盘写满会直接触发只读保护。

对照硬件：每节点 1 块 2TB SATA SSD，四节点物理 8TB，双副本后可用 4TB——够用但不算宽裕，如果聚合策略放松到流水保留 12 个月，就要加盘。

七、性能预期

• 写入：SATA SSD 顺序写理论约 300MB/s，实际可用写入按 15-20MB/s 规划（单节点），双分片集群 30-40MB/s
• 查询：32GB 内存可缓存全部活跃数据，SATA SSD 读取约 250MB/s，聚合查询基本跑在内存里

理论值和实际值之间 15 倍的折减不是保守，而是给副本同步、后台 merge、异常重试留出的余量——按理论值做容量规划的系统，上线第一周就会被打爆。

八、总结

这套方案的核心思路：从实际写入量出发推算集群能力，用验证过的版本锁定兼容性，用两节点/四节点的分界线（月增量 1TB、写入 10MB/s）做架构决策，存储按保留策略+三个系数估算。整套方法不绑定具体业务，换成你自己的写入量数字就能直接复用。

你们生产上的 ClickHouse 是几个节点？踩过国产化环境的兼容坑吗？评论区聊聊。

---

本文容量数字来自实际部署验证环境，不同业务模型请按自身写入量重新推算。