ClickHouse集群在eBay事件监控平台的可用性和扩展性探索(2)

ClickHouse集群在eBay事件监控平台的可用性和扩展性探索

为了避免queries spike或者存在的某些load比较重的queries影响数据的写入，针对ClickHouse 的read/write隔离的方案需要尽快应用。初步的想法是为重要的案例增加一份单独的replica，ingress的流量只会使用写replica来进行数据的写入，通过zk将数据同步到读replica，而egress的queries只会发生在这些读replicas上，从而实现读写分离。

但是在将读写分离方案应用在生产上时，新的问题出现了：

事件监控平台使用的是
ClickHouseReplicatedMergeTree系列的table engine，来进行不同replica之间数据的同步。而ClickHouse server是通过centralized ZooKeeper集群来进行数据元数据的同步以及DDL queries指令的执行。目前的部署架构如下所示：

对于OLAP集群而言，每天有超过30亿条的数据插入, 平均每秒有100多个新写入的parts生成，而ClickHouse后台还会不断的生成merge task，生成更多的新的以及随时“过时”的parts。

并且一共有30个replica（10shards*3replicas）不断访问ZooKeeper拿到parts的元信息以完成数据同步。因此ZooKeeper处于巨大的压力之中，原本在一些数据mutation的时刻，zk已经显示出滞后，在这次enable了更多的replica来进行读写分离的时候，zk的outstanding requests高达1K+，并且在UTC 0点数据rotate的时候出现了数据丢失。

此时我们意识到随着用户流量的增大，集群shard数目不断增加，zk或许/已经成为了ClickHouse集群横向扩展的瓶颈。

解决方案

2.1 read/write separation

为了提高事件数据的响应速度，特别是为了保证基于事件数据的告警规则的有效性和稳定性，事件平台的ClickHouse采用了冷热分层的架构，而且热存储使用的是本地SSD磁盘，因此没有采用ClickHouse的存算分离方案。

为了实现ClickHouse的读写分离，基本思路是将集群中同一个shard的特定部分replica只提供写服务，另外一部分replica只执行读queries，具体设计如下：

在FCHC CRD中引入readWriteMod字段实现读写分离的支持，并且当readWriteMod>1时对该ClickHouse集群启用读写分离。

当{replica_num} % readWriteMod!= 0的节点则都默认为读节点，operator将这些读节点组织并创建一个读virtual集群，而位于query集群中的distributed tables则指向这个virtual集群节点中的具体表，实现这些节点的只读；

当{replica_num} % readWriteMod== 0 时该replica dedicated为写节点，ingress将会发现并倾向返回这批replica,并将数据直接写入，但是当这批写入节点不可用时，会回退到返回一个读节点进行数据写入，保证数据的安全性。这种模式下，同一个shard一般会分配1个写节点和1个或者多个读节点，因为通常都是读的压力比较大。

下图描述了一个shard中的replica是如何分配读写节点的：