ClickHouse 集群部署方案：双分片还是四节点？一份可落地的容量规划

部署 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 Node1Shard1-Replica1Node1 通过 ZooKeeper 通知数据变化CH Node2Shard1-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 台 ClickHouse4 个 CH 节点组成 2 个分片、每分片 2 副本。写入可以打到 Shard1 和 Shard2 两个分片实现写入负载均衡副本同步逻辑与两节点方案相同只是并行了两份跨分片查询可并行执行查询性能更好ClickHouse 节点配置与两节点方案相同8C/32G/4TBZooKeeper 适当放大到 4 核 8GB。总资源需求CPU 32 核、内存 128GB、存储 8TB双副本后可用 4TB。四、方案对比与选型建议维度两节点方案四节点方案写入性能15-20MB/s30-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 是几个节点踩过国产化环境的兼容坑吗评论区聊聊。本文容量数字来自实际部署验证环境不同业务模型请按自身写入量重新推算。