从ZooKeeper切换到ClickHouse-Keeper，藏着怎样的秘密

本文字数：7772；估计阅读时间：20 分钟

作者：博睿数据李骅宸（太道）& 小叮当

本文在公众号【ClickHouseInc】首发

本系列前两篇内容：

从ES到ClickHouse，Bonree ONE平台更轻更快！

100%降本增效！Bonree ONE平台通过ClickHouse实现了可观测信号数据的统一！

背景

Bonree ONE是博睿数据公司发布的一体化智能可观测平台。平台所有信号数据迁移到ClickHouse集群后，随着数据量的增长，对ZooKeeper的性能和稳定性要求也越来越高。ZooKeeper是一个开源的分布式协调组件，用于分布式系统之间的协调作用。但我们在使用中也遇到了一些痛点，如果不及时处理会影响到业务。最终我们选择用ClickHouse-Keeper替代ZooKeeper，解决写入性能和维护成本以及集群管理出现的问题。想做到丝滑切换，还需要考虑自动化升级、鉴权情况、数据迁移、数据验证等细节。

ZooKeeper vs ClickHouse-Keeper

ZooKeeper

在数据量和数据种类不断扩充的情况下，ClickHouse集群对于ZooKeeper的压力越来越大。例如在基于实时性要求高的告警数据入库查询时，数据查询的实时性要求秒级返回，ZooKeeper在我们实践中遇到过以下问题：

承载力有限。在我们自建云部署中，按Keeper 4C8G资源配置，单ZooKeeper集群（3个节点）的情况下，最多支持到5个shard（16C32G配置，双副本），每个shard的parts数量大概在2W左右，那5个shard总parts共计10W左右。在不断的数据量增加和表增加的情况下，集群规模会迅速膨胀。所以每扩容5个shard，就得再扩一套ZooKeeper集群，这也带来了极大的维护成本。
性能有瓶颈。初始ClickHouse存储1T数据，总共parts数量在1.2W以内时，数据可以在毫秒级插入成功，但是随着数据量不断增加，parts数量达到2W时，数据插入的响应时间会明显越来越慢，需要几十秒以上才可以插入成功。导致产品上会有查询不到数据，或者查询的数据不及时的现象，影响体验。
资源占用多。ZooKeeper占用内存和IO多，随着数据量的上涨，成本会越来越高。我们在同样的可观测性数据环境中对比发现，ZooKeeper内存消耗是ClickHouse-Keeper的4.5倍，IO占用是ClickHouse-Keeper的8倍。
稳定性不高。ZooKeeper使用Java语言开发，在内存设置不合理的情况下，会出现频繁Full GC从而导致服务中断，从而引起ClickHouse的性能抖动，有时还会出现zxid溢出的问题。另外，当ClickHouse后台执行副本间parts同步时，需要先在ZooKeeper上注册，这时如果ZooKeeper性能表现不佳，会引起后台线程剧增满载，从而导致副本间数据同步延迟。我们在自建云观察在使用ZooKeeper进行存储元数据时，副本间的parts数量延迟队列能达到1W多个，这将严重影响前台业务查询的数据的准确性。

ClickHouse-Keeper

基于以上痛点对比，加上写多读少的统计分析场景特点，我们选择了表现更佳的ClickHouse-Keeper作为Zookeeper的替代品，主要考虑以下几点：

判断兼容性。ClickHouse-Keeper兼容ZooKeeper客户端的协议，任何标准的ZooKeeper客户端都可以与ClickHouse-Keeper进行交互，支持使用ClickHouse的客户端命令。这样就对服务端来说，不改造就可以连接到ClickHouse-Keeper。

历史数据迁移。使用ClickHouse-keeper-converter工具对ZooKeeper历史数据进行转换，并将转换后的快照文件导入到ClickHouse-Keeper集群中。转换效率做到百万路径控制在五分钟以内，降低整体集群停止写入的时间，降低对线上产品的影响程度。

服务稳定。ClickHouse-Keeper使用C++语言编写，提升了整体服务的稳定性，从根本上解决了ZooKeeper的Full GC带来的服务中断，并可以通过调整服务端参数提升服务性能。

资源和性能。对元数据进行压缩存储降低服务的资源占用。同时在CPU和内存以及磁盘IO上使用效率更高。在更好资源情况下，ClickHouse-Keeper性能更佳。

方案演进

1.基于ZooKeeper的原有方案

在集群业务不断扩充的情况下，我们的业务也逐渐划分成重要业务和一般业务，重要业务的性能和查询需求需要优先保证，资源就得绝对隔离高保。我们知道在单个ClickHouse服务中，如果做大量的资源控制，对于大集群来说是一件灾难性的事件，因为我们每次都要重新划分新业务的比重同时调整资源比例。如果我们从物理上直接隔离不同业务的资源将是非常友好的一件事，这样对于运维只需要关心这个业务给多少资源支撑。早期我们因为业务多样复杂性和SLA的不同，通过Zookeeper实现了多个ClickHouse Cluster方案。但在ClickHouse不断扩容的情况下，整个ClickHouse对于ZooKeeper的压力也水涨船高，压力倍增。这时候使用一套ZooKeeper存储所有的元数据，对于ZooKeeper来说已经不能够支持ClickHouse提供正常的服务，插入延迟和任务堆积都将出现。为了解决这个困境，使用ClickHouse官方提供的多ZooKeeper方案。针对我们的业务数据特性和压力，每5个shard的ClickHouse存储parts存储到一个ZooKeeper集群（3个实例）。表的元信息存储到另一套单独的ZooKeeper集群中（3个实例）。

如上图举例，业务A和业务B需要做物理隔离，为A提供CK1集群（15个shard，双副本），为B提供CK2集群（5个shard，双副本），业务查询根据不同cluster名字映射到不同物理资源上的ClickHouse实例，从而做到资源隔离，业务不会影响。按5个shard为一组，ZK1、ZK2、ZK3三个集群平分CK1的15个shard的parts管理，ZK4管理CK2的5个shard的parts。CK1和CK2的所有表的元信息单独存储到公用ZK5集群中（出于稳定性要求考虑）。这样一共需要5套ZK集群（3x5 = 15个ZK实例），维护起来非常麻烦，并且存储时间久了性能和稳定性不太好。

2.基于ClickHouse-Keeper的新方案

测试中已验证使用ClickHouse-Keeper，提升了数据插入速度，提升了ClickHouse的稳定性，副本间同步文件的速度。因为ClickHouse-Keeper表现优异，我们完全不再需要用那么多套keeper管理，索性就维护一套ClickHouse-Keeper，完全可以支持到15个shard以上，相比原来方案精简了许多。

3.升级前的准备

我们知道ClickHouse会不断的更新在ZooKeeper上的数据，当我们停止入库后，其实还有一部分的后台任务在进行（例如后台merge任务），这些任务会改变在ZooKeeper上的数据内容，这样我们就没有办法判断升级之后和升级之前的内容是否是一致的，是否成功将ZooKeeper中的数据转换成功，同时我们又不能将ClickHouse停止，因为停止了ClickHouse的话，平台就无法使用。为此我们深入了解了ClickHouse在ZooKeeper上这些后台任务，并通过命令（例如：SYSTEM STOP MERGES）将这些任务停止掉。这样在升级前后ZooKeeper和ClickHouse-Keeper中的数据是完全一致的，也为我们后面进行数据对比验证提供了条件。因为全过程实现了自动化执行，保障了停止入库时间控制在30分钟内变更完成，不严重影响业务。

4.自动化升级（ZooKeeper -> ClickHouse-Keeper）

升级过程涉及跨机器执行多命令，以及对执行结果判断，大量的人为操作会导致出错概率成倍增加，并使升级时间大大增加。为了解决此问题，我们基于ansible开发自动化升级工具（ansible 是一款 IT 自动化工具，主要应用场景有配置系统、软件部署、持续发布及不停服平滑滚动更新的高级任务编排）。那么我们如何做的自动化升级呢？大致步骤如下：

（1）停止数据入库任务。

（2）停止ClickHouse的merge等后台任务。

（3）记录需要对比的指标数据。

（4）依次重启各个ZooKeeper集群获取最新产生的快照文件。

（5）按照ZooKeeper和ClickHouse-Keeper的对应规则进行快照文件Copy和转换成ClickHouse-Keeper的快照文件。

（6）将快照文件加载到ClickHouse-Keeper中，并进行抽样对比ZooKeeper和ClickHouse-Keeper节点内容。

（7）切换ClickHouse的元数据存储由ZooKeeper到ClickHouse-Keeper。

（8）查询对比指标，并与步骤（3）中指标对比。

（9）启动ClickHouse的merge等后台任务，启动数据入库。

在基于ansible做自动化升级之后，避免升级操作失误，真正做到了傻瓜式升级。同时提升了升级速度，由原先2-3小时的手动升级时间，缩短到现在的分钟级完成，降低了业务查询在ClickHouse的升级过程中影响范围。自动化核心过程：

//停止ClickHouse建库建表等操作
stopClickHouseManagers()

//停止ClickHouse 数据写入作
stopClickHouseConsumers()

//停止ClickHouse Merge等后台任务
ClickHouseStopMerges()

//获取Zookeeper集群最新的快照信息
getNewZookeeperSnap()

//转换Zookeeper快照生成ClickHouse keeper快照文件
createAndExecConvertShell(housekeeperClusterName)

//启动ClickHouse集群
startClickHouses()
    
//对比升级前后数据
checkClickHouseSelectData()

遇到的挑战

那么对于上面讲述的升级过程，就算完成了吗？其实那只是基础步骤。我们环境还更加复杂，除了历史部署了多cluster、多套ZK，还遇到了多套ZK转单套ClickHouse-Keeper（社区版只支持一转一）、ZK加密鉴权问题、数据验证效率等一些难题。

1.多套ZooKeeper转单套ClickHouse-Keeper

为什么会有这个需求呢？主要是因为我们在ZooKeeper和ClickHouse-Keeper性能测试中发现，ClickHouse-Keeper的性能在模拟ClickHouse 请求时性能远超ZooKeeper，对于已经是多套ZooKeeper存储parts的情况，为避免资源浪费，我们需要将集群进行缩减。在CK官方提供的工具中，只能进行一套ZooKeeper通过快照转换到一套ClickHouse-Keeper中。无法支持多套ZooKeeper 迁移到同一套ClickHouse-Keeper。如果不牵扯到服务缩减的话，还遇不到这个问题。那么我们是如何解决的呢，主要通过两方面：

在迁移之前我们会抽样一部分节点对这些节点信息进行保存，在迁移之后对比迁移之前抽样的节点信息是否一致，同时也会抽样表格数据进行查询，确保整个升级过程的前后，数据一致，以防异常情况带来的影响。
在原有的ClickHouse-keeper-converter源码中修改相关代码，支持多套ZooKeeper快照文件合并到同一套ClickHouse-Keeper。比如：

//循环反序列化所有的快照文件
for (const auto & item : existing_snapshots)
{
deserializeKeeperStorageFromSnapshot(storage, item.second, log);
}

//修改numChildren属性获取方式，不用自增id
storage.container.updateValue(parent_path, [path = itr.key] (KeeperStorage::Node & value) { value.addChild(getBaseName(path)); value.stat.numChildren = static_cast<int32_t>(value.getChildren().size());});

//创建转换快照文件时的文件输出流，为了后续diff工具快速读取用
int flags = (O_APPEND | O_CREAT | O_WRONLY);
std::unique_ptr<WriteBufferFromFile> out = std::make_unique<WriteBufferFromFile>("pathLog", DBMS_DEFAULT_BUFFER_SIZE, flags);

2.加密鉴权

我们有很多私有化TOB客户，历史上有些要求对ZK加密，有些不加密，情况不一，但都需要考虑能兼容各种，能丝滑升级。大家知道ZK可以进行ACL加密，对于已经加密的ZK集群转换如何处理，对于部分ZK集群加密转换如何处理，对于完全没有加密的ZK集群又如何处理，分不同策略：

全部加密，或全部不加密。全部加密并且加密信息一致的情况下，即每个ZooKeeper集群中的节点都是使用的相同的ACL策略，同时策略内容相同，并且ClickHouse-Keeper的ACL兼容ZK的ACL，则这种情况下我们是可以保留原有的加密信息，直接进行转换，同时ClickHouse中的配置文件也无需修改。如果全部没有加密，即ClickHouse在使用ZooKeeper的时候没有配置ACL信息，则这种情况也可以直接转换，同时ClickHouse中的配置文件也无需修改。
部分加密，或加密信息不一致。这种情况下就要将原有的加密信息去掉，同时修改ClickHouse 配置文件将加密方式修改为一致。去除ZooKeeper加密方式如下：

（1）添加超级管理员账户。在Zookeeper集群启动的时候在启动的JAVA命令中添加：

Dzookeeper.DigestAuthenticationProvider.superDigest=zookeeper:{XXXXXX}

（2）重启Zookeeper集群。

（3）使用Zookeeper客户端进入集群。

zkCli.sh -server ${zookeeper集群地址，格式为ip1:port,ip2:port}

（4）登录超级管理员账户。

addauth digest zookeeper:#{XXXXXX}

（5）执行取消节点的鉴权命令（目标路径下节点越多耗时越长）。

setAcl -R ${zookeeper的znode路径} world:anyone:cdrwa

（6）去除步骤（1）中的超级管理员账户，同时重启Zookeeper集群。

（7）待升级之后，看自己是否需要在ClickHouse-Keeper中再开启加密。

3.对比验证

我们知道在ZooKeeper中存储的路径是无法直接获取所有的路径，同时我们还遇到了多个ZooKeeper集群合并到同一个ClickHouse-Keeper集群中的情况。如果在自动化升级过程中不能快速准确的进行数据对比，升级时长会成倍增加，同时容易出现误判断，导致升级失败。对于如何快速获取路径和路径对比我们做了如下策略：

（1）我们在ZooKeeper快照转换成ClickHouse-Keeper快照的时候会将转换的所有的path都打印到一个pathlog目标文件中，在对比的时候对这个文件中的内容进行抽样，这样就将查询ZooKeeper的操作变成了读文件操作。原先读取900W个ZooKeeper路径大概需要9个小时，优化后只需要十几秒就可以完成（pathlog加载到内存中读取）。

（2）我们在获取到抽样的ClickHouse-Keeper之后，会根据转换关系，将znode路径和多个ZooKeeper集群的znode路径依次对比。同时在对比之前我们已经关闭了merge等任务，进一步保证临时目录不会出现，从而保证对比的有效性。分情况对比：

差异性路径。此类路径只存在于/clickhouse/tables的路径下，并且只会存在于唯一一套ZK集群中，则对比验证成功。反之，无论在多套ZK集群都不存在，或者存在于两套或两套以上，则对比验证失败。这样就保证了差异性路径数据的正确性。
公共路径。路径在所有ZK集群中的内容都是相同的，才算对比验证通过。这样就保证了公共路径数据的正确性。

4.ClickHouse-Keeper关键参数调优

max_requests_batch_size。这个表示发送到raft之前，请求攒批的最大size。集群越大，这个值适量调整大一些，利于攒批和性能提升，我们场景里把value设置为1W。
force_sync。表示请求是否同步写入日志，优化设置为false。
compress_logs。表示是否压缩日志，日志文件大小会影响启动速度和磁盘占用，优化设置为true。
compress_snapshots_with_zstd_format。表示是否压缩快照，日志文件大小会影响启动速度和磁盘占用，优化设置为true。

效果

我们将ZooKeeper替换为ClickHouse-Keeper之后，资源收益和写入耗时收益显著，解决了在ZooKeeper存储元数据的性能瓶颈问题，同时在易用性上降低了门槛。之前ZK的IO瓶颈会直接影响到整体ClickHouse存储的写入耗时。在我们自建云千亿数据实践验证中，从ZK已迁移到HouseKeeper后，CPU和内存占用节省了75%以上，故障率几乎没有。但更值得一提的是，即使再高配置的ClickHouse集群也不要忽视了IO的重要性。最终切换到ClickHouse-Keeper后，IO开销降低了8倍，同时性能也提高了近8倍，这个数据比较符合预期。原本没想到ClickHouse本身性能强悍，ClickHouse-Keeper的性能也毫不逊色！

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com