clickhouse常规方式部署可能会遇到zookeeper压力大的场景，此时zookeeper的拆分会是一种有效的方法。
常规情况下Clickhouse集群架构如下：
可以看到多个clickhouse分片共同使用一个zookeeper集群。
但是这样往往会遇到：
- 添加更多的clickhouse分片，造成zk负载过大
- 更多的数据写入，造成zk负载过大
- 建更多的表，造成zk负载过大
总之，如果不能移除zk，那么一定要想办法解决zk的瓶颈问题。
可能有小伙伴会问了：
一开始搭建集群的时候就固化zk对应的分片数，用多组zk来承载，降低压力，会不会避免这个问题。
答案是：不一定。
一般情况下这样做确实可以在一定程度上规避这个问题，但是如果这个集群是已经有一定负载的老集群，怎么办？
结论是，拆，虽然不能绝对解决问题，但是针对大部分的场景，拆可以解决眼前的问题，并为业务迁移赢得时间。
现在问题变成了----怎么拆。
拆集群的前提：
1.数据避免直接写入分布式表
2.数据可以指定写哪些节点（屏蔽哪些节点）
Ok，现在开始：
1.zk扩容
假设原来zk有三个节点，那么现在添加3个节点（observer模式），等待zk数据同步。
稍后数据会同步到observer节点。
- 停止部分shard数据写入
这部分shard在zk上的数据会停止更新，最好等待24小时，待后台最后的merge完成。
- 修改部分shard的配置，使其指向新的zk，并重启生效
此时因为zk是同一套集群，数据是一致的，故不会影响查询和同步。
- 原来的observer 3个节点重启，重新组合成一个新的集群
Zk重启只影响数据的写入，此时查询是不受影响的（查询要避免init query指向待拆分的分片），而此时数据不会往这些分片写，故整个操作是安全的。
- 恢复部分分片的数据写入
此时集群已经完成了拆分。
注意：这个办法只适合于有资源且压力不是极大的集群，如果集群只有一个分片，此时只能做数据迁移了。
