Clickhouse中ZK的作用

我们有个标签表，单表大概1P

https://www.163.com/dy/article/H4RAV2NC0511D3QS.html

ClickHouse 社区版原生的 Replication 方案有太多的信息存在 ZooKeeper 上，为了保证服务，一般会有一个或者几个副本，在字节内部主要是两个副本的方案。

早期内部曾有一个 400 个节点的集群，只存了半年的数据。突然有一天团队发现服务特别不稳定，ZK 的响应经常超时，table 可能变成只读模式，发现 znode 太多。而且 ZK 并不是可水平扩展的框架，按照当时的数据预估，整个服务很快就会不可用了。

团队分析后得出结论，实际上 ClickHouse 把 ZK 当成了三种服务的结合，而不仅把它当作一个 Coordinate service，可能这也是大家使用 ZK 的常用用法。ClickHouse 还会把它当作 Log Service，很多行为日志等数字的信息也会存在 ZK 上；还会作为表的 catalog service，像表的一些 schema 信息也会在 ZK 上做校验，这就会导致 ZK 上接入的数量与数据总量会成线性关系。按照这样的数据增长预估，ClickHouse 可能就根本无法支撑头条、抖音的全量需求。