运营 ClickHouse 五年：PB 级集群的实战教训
I've operated petabyte-scale ClickHouse clusters for 5 years
我在 Tinybird 运营 ClickHouse 集群已近六年，从版本 18.4 一路走到今天，处理过 PB 级数据，也踩过无数坑。搭建集群容易，但维持其稳定运行才是真挑战。本文分享我在架构设计、存储策略、升级流程中的真实经验：从本地 SSD 到 S3 云存储的权衡，从零复制机制的利弊到如何避免数据丢失，再到如何在不中断服务的情况下完成升级。如果你正在管理 ClickHouse 集群，这些教训或许能帮你避开一些弯路。
搭建集群很容易，难的是让它持续稳定运行。
HN 评论区
49- zbentley
> 对于每秒超过 2 万行数据且有人频繁推送变更的负载，你可能需要一名全职人员来维护集群，并审查用户即将编写的各种疯狂查询。
我认为这是过去 DBA 文化的一个优势。这并不是说 DBA 对于编写优质查询是绝对必要的（他们通常需要与应用团队协作，引导对方采用更合理的模式/行为），也不是说他们对于维护数据库是必须的（托管数据库服务已经淘汰了大量此类工作），而是因为他们充当了查询和模式存在的守门人和限流器。
在这种模式下，DBA 的作用有点像一种人类/流程版的轻量级微服务，封装了数据库访问功能。其一大好处是，查询/模式变更/访问模式的变化速率得到了控制，并且在上线前有更高的概率经过人类的审查和思考。这也导致终端数据库用户形成了一种文化：在直接采用定制访问模式之前，先尝试让现有的模式/查询模式发挥作用。这种文化对于初创公司或热衷于快速大规模重构的团队来说并非理想之选，但对于数据库可靠性要求高或查询速率/数据集规模巨大的场景来说，这正是你所需要的。
我并不认为守门人团队总是物有所值，这取决于具体情况。但我认为该团队的代码版本（即前述仅封装数据库访问/模式变更的轻量级微服务）是……
- anguss
几周前，我在 GitHub 上扫描那些提交频繁的仓库，以识别所谓的“软件工厂”，结果惊讶地看到了 ClickHouse。考虑到他们合并代码到主分支的速度之快，我连用十英尺长的杆子都不愿意碰它。我指的是每天 50 多次提交，以及成千上万个由 AI 生成的问题和分类。你自己去看看吧 https://github.com/clickhouse/clickhouse
- walthamstow
顺便提一句，上周我打开富勒姆对阵水晶宫的比赛时愣住了，发现富勒姆今年球衣上印的是 ClickHouse，而水晶宫印的是 Temporal AI。真是我的两个世界碰撞了。
- lucrbvi
这么多 ® 符号，很好奇 ClickHouse® Inc. 会如何处理他人对其名称的使用……希望别像 Oracle 对待 JavaScript 那样。
- threecheese
我正在运行一个 TB 级别的 ClickHouse 集群——但这只是因为我让 Langfuse 在 MacBook 上跑了好几个月 :)
不过说真的，ClickHouse 确实很吃磁盘空间。