基于 Amazon EC2 和 Amazon EKS 一键部署可长期运维的 ClickHouse 集群：方案与实践
内容提要
本文介绍在亚马逊云科技上一键部署且可长期运维的ClickHouse集群方案，提供EC2和EKS两种形态。通过CloudFormation参数完成部署、升级、扩容、磁盘扩容、监控和备份，UpdateGuard拒绝危险变更，SSM或Operator逐节点执行。实测写入性能两者接近，EC2适合专用集群，EKS适合已有Kubernetes平台的团队。
延伸解读
运维自动化如何避免“一键部署”后的失控
方案把版本升级、扩容、磁盘调整等日常操作都收敛到 CloudFormation 参数变更，并由 UpdateGuard 在第一步拦截危险修改，如改集群名、减分片或降版本。实际执行时，SSM State Manager 以 MaxConcurrency=1、MaxErrors=0 逐节点处理，升级需等副本追平、无只读副本才继续。这种设计把“人肉逐台操作”变成可回滚的流水线，但前提是接受堆栈参数作为唯一入口，手工改配置可能被后续关联覆盖。
EC2 与 EKS 的性能差异主要来自资源预留
实测两者写入性能接近，差异在 ±6% 以内，瓶颈都是 gp3 磁盘吞吐。高并发读取时 EKS 低 5–13%，文章归因于 pod 只能使用节点 allocatable 扣除系统预留后的约 7.1 vCPU，而 EC2 可用满 8 vCPU；把读请求分到两个副本后，EKS 混合负载 QPS 与 EC2 相当。若读性能敏感，EKS 上可选大一号实例规格来弥补预留，而不是期待调优消除差距。
扩容不是自动均衡，缩容需另建集群
增加分片后，新分片初始没有业务表，需用 ON CLUSTER 补建；已有数据不会自动重分布到新分片，要均衡历史数据得通过 INSERT INTO ... SELECT 重写或导入新分区。减少分片或副本会被 UpdateGuard 拒绝，文章建议新建更小集群并用 BACKUP/RESTORE 迁移。这意味着水平扩容能提升新写入的分布能力，但历史数据布局需要额外规划，不能把扩容当成自动再平衡。
备份窗口与版本行为变化需提前确认
备份每天由每个分片的 1 号副本执行，周日全量、其余增量，增量依赖对应全量，因此可恢复时间窗口为 BackupRetentionDays 减 7 天，默认 28 天。文章还提醒 26.x 版本中 deduplicate_insert 默认开启会静默去重相同数据块，且查询中的 S3 函数默认不能使用实例角色，恢复语句需加 s3_allow_server_credentials_in_user_queries=1，而 25.8 加此设置反而报错。升级前应验证备份与恢复脚本的版本兼容性。
Q&A
在亚马逊云科技上自建 ClickHouse 集群，日常运维主要面临哪些挑战？
主要挑战包括：协调服务需维护 ZooKeeper（现推荐 ClickHouse Keeper）；版本升级需逐节点手工操作且回退无章法；扩容或变更配置需同步修改所有节点，误操作可能触发实例替换导致数据丢失；缺少开箱即用的监控告警；备份与恢复常被忽视；在 EKS 上运行有状态 ClickHouse 需处理存储、调度、权限等问题。
这个 ClickHouse 部署方案如何防止更新堆栈时误删数据或破坏集群？
方案通过 UpdateGuard 自定义资源在更新第一步检查变更，拒绝修改集群名、Keeper 数量、网络和实例类型，减少分片数、副本数或磁盘大小，以及降级 ClickHouse 版本等危险操作，一旦拒绝堆栈直接回滚。此外，数据盘独立于实例并设置删除/替换前自动快照，实例固定使用启动模版第 1 个版本，可变配置存于 SSM Parameter Store，避免更新导致实例替换。
EC2 方案和 EKS 方案在部署耗时和适用场景上有什么区别？
EC2 方案部署约 6 分钟，适合专用的 ClickHouse 集群，追求简单和性能可预期；EKS 方案部署约 30 分钟（含 EKS 集群创建），适合已有 Kubernetes 平台、希望统一管理的团队。日常运维上，EC2 用 SSM State Manager 逐节点执行，EKS 用 Altinity Operator 逐 host 滚动；修改实例类型在 EC2 需按手册逐节点手工操作，在 EKS 可通过参数触发节点组蓝绿替换。
压测发现 ClickHouse 持续写入的瓶颈在哪里？生产环境应如何调整？
压测显示持续写入的瓶颈是数据盘吞吐而非 CPU，写入阶段 ClickHouse 进程 CPU 使用率仅 10–20%，而两个副本的数据盘写入吞吐长时间顶在 gp3 默认的 125 MiB/s。生产环境建议把 DataVolumeThroughput 调到 300 MiB/s 左右（m7g.2xlarge 的 EBS 基线带宽为 312.5 MB/s），IOPS 保持 3000 即可。
方案中的备份和恢复是如何工作的？恢复时间窗口有多长？
开启备份后，每个分片的 1 号副本每天执行 ClickHouse 原生 BACKUP 到 S3，周日全量、其余增量，备份桶开启版本控制并按 BackupRetentionDays 自动过期。恢复时建议先恢复成新表校验，增量恢复会自动读取依赖的全量备份。由于全量备份先于后续增量过期，可保证恢复时间窗口为 BackupRetentionDays − 7 天（默认 28 天），建议每季度做一次恢复演练。
在 EC2 方案中如何升级 ClickHouse 版本？升级过程如何保证副本可用？
将堆栈参数 ClickHouseVersion 修改为目标 LTS 版本并更新堆栈，SSM State Manager 关联会以 MaxConcurrency=1、MaxErrors=0 逐节点执行升级。每个节点先记录表和复制表数量，安装新版本并重启，重启后需满足版本正确、表数量恢复、无等待加载任务、无只读副本、复制延迟小于 60 秒才处理下一个节点，保证同一分片任何时候最多只有一个副本不可用。方案不支持降级，降低版本会被 UpdateGuard 拒绝。
EKS 方案在读写性能上与 EC2 方案相比如何？
写入性能两者基本一致，差异在 ±6% 以内，瓶颈都是 gp3 磁盘吞吐。高并发读取 EKS 低 5–13%，主要原因是 pod 只能使用节点 allocatable 中扣除系统预留后的约 7.1 vCPU，而 EC2 上 ClickHouse 可使用全部 8 vCPU；把读请求分发到两个副本后，EKS 的混合负载 QPS 与 EC2 相当。对读性能敏感的业务可在 EKS 上选择大一号实例规格弥补。
