字节跳动基于 ClickHouse 优化实践之“高可用”

更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

相信大家都对大名鼎鼎的 ClickHouse 有一定的了解了，它强大的数据分析性能让人印象深刻。但在字节大量生产使用中，发现了 ClickHouse 依然存在了一定的限制。本篇将详细介绍我们是如何为 ClickHouse 增强高可用能力的。

字节遇到的 ClickHouse 可用性问题

随着字节业务的快速发展，产品快速扩张，承载业务的 ClickHouse 集群节点数也快速增加。另一方面，按照天进行的数据分区也快速增加，一个集群管理的库表特别多，开始出现元数据不一致的情况。两方面结合，导致集群的可用性极速下降，以至于到了业务难以接受的程度。直观的问题有三类：

1、故障变多

典型的例子如硬件故障，几乎每天都会出现。另外，当集群达到一定的规模，Zookeeper 会成为瓶颈，增加故障发生频率。

2、故障恢复时间长

因为数据分区变多，导致一旦发生故障，恢复时间经常会需要 1 个小时以上，这是业务方完全不能接受的。

3、运维复杂度提升

以往只需要一个人负责运维的集群，由于节点增加和分区变多，运维复杂度和难度成倍的增加，目前运维人数增加了几人也依然拙荆见肘，依然难保证集群的稳定运行。

可用性问题已经成为制约业务发展的重要问题，因此我们决定将影响高可用的问题一一拆解，并逐个解决。

提升高可用能力的方案

一、降低 Zookeeper 压力

问题所在：

原生 ClickHouse 使用 ReplicatedMergeTree 引擎来实现数据同步。原理上，ReplicatedMergeTree 基于 ZooKeeper 完成多副本的选主、数据同步、故障恢复等功能。由于 ReplicatedMergeTree 对 ZooKeeper 的使用比较重，除了每组副本一些表级别的元信息，还存储了逻辑日志、part 信息等潜在数量级较大的信息。Zookeeper 并不是一个能做到良好线性扩展的系统，当 ZooKeeper 在相对较高的负载情况下运行时，往往性能表现并不佳，甚至会出现副本无法写入，数据也无法同步的情况。在字节内部实际使用和运维 ClickHouse 的过程中，ZooKeeper 也是非常容易成为一个瓶颈的组件。

改造思路：

ReplicatedMergeTree 支持 insert_quorum，insert_quorum 是指如果副本数为 3，insert_quorum=2，要成功写入至少两个副本才会返回写入成功。

新分区在副本之间复制的流程如下：

可以看到，反复在 zookeeper 中进行分发日志、数据交换等步骤，这正是引起瓶颈的原因之一。

为了降低对 ZooKeeper 的负载，在 ByteHouse 中重新实现了一套 HaMergeTree 引擎。通过 HaMergeTree 降低对 ZooKeeper 的请求次数，减少在 ZooKeeper 上存储的数据量，新的 HaMergeTree 同步引擎：

1）保留 ZooKeeper 上表级别的元信息；

2）简化逻辑日志的分配；

3）将 part 信息从 ZooKeeper 日志移除。

HaMergeTree 减少了操作日志等信息在 zookeeper 里面的存放，来减少 zookeeper 的负载，zookeeper 里面只是存放 log LSN, 具体日志在副本之间通过 gossip 协议同步回放。

在保持和 ReplicatedMergeTree 完全兼容的前提下，新的 HaMergeTree 极大减轻了对 ZooKeeper 的负载，实现了 ZooKeeper 集群的压力与数据量不相关。上线后，因 Zookeeper 导致的异常大量减少。无论是单集群几百甚至上千节点，还是单节点上万张表，都能保障良好的稳定性。

二、提升故障恢复能力

问题所在：

虽然所有数据从业者都在做各种努力，想要保证线上生产环境不出故障，但是现实中还是难以避免会遇到各式各样的问题。主要是由下面这几种因素引起的：

软件缺陷：软件设计本身的 Bug 引起的系统非正常终止，或依赖的组件兼容引发的问题。

硬件故障：常见的有磁盘损坏、内容故障、CPU 故障等，当集群规模扩大后发生的频率也线性增加。

内存溢出导致进程被停止：在 OLAP 数据库中经常发生。

意外因素：如断电、误操作等引发的问题。

由于原生 ClickHouse 希望达到极致性能的初衷，所以在 ClickHouse 系统中元数据常驻于内存中，这导致了 ClickHouse server 重启时间非常长。因而当故障发生后，恢复的时间也很长，动辄一到两个小时，相当于业务也要中断一到两个小时。当故障频繁出现，造成的业务损失是无法估量的。

改造思路：

为了解决上述问题，在 ByteHouse 中采用了元数据持久化的方案，将元数据持久化到 RocksDB， Server 启动时直接从 RocksDB 加载元数据，内存中也仅仅存放必要的 Part 信息。因此可以减少元数据对内存的占用，以及加速集群的启动以及故障恢复时间。

如下图所示，元数据持久化整体上采用了 RocksDB+Meta in Memory 的方式，每个 Table 都会对应一个 RocksDB 数据库存放该表所有 Part 的元信息。Table 首次启动时，从文件系统中加载的 Part 元数据将被持久化到 RocksDB 中；之后重启时就可以直接从 RocksDB 中加载 Part。每个表从 RocksDB 或者文件系统加载的 Part 将只在内存中存放必要的 Part 信息。在实际使用 Part 时，将通过内存中存放的 Part 元信息去 RocksDB 中读取并加载对应 Part。

完成元数据持久化后，在性能基本无损失的情况下，单机支持的 part 不再受内存容量的限制，可以达到 100 万以上。最重要的是，故障恢复的时间显著缩短，只需要此前的几十分之一的时间就可以完成。例如在原生 ClickHouse 中需要一到两个小时的恢复时间，在 ByteHouse 中只需要 3 分钟，大大提高的系统的高可用能力，为业务提供了坚实保障。

三、其他方面

除了以上两点，在 ByteHouse 中在其他很多方面都为高可用能力做了增强，如通过 HaKafka 引擎提升了数据写入的高可用性，提升实时数据写入的容错率，可自动切换主备写入；增加了监控运维平台，实现对关键指标的监控、告警；增加多种问题诊断工具，能实现故障的快速定位。

对于数据分析平台来说，稳定性是重中之重。我们对 ByteHouse 的高可用能力的提升是不会停止的，在极致性能的背后，力图为用户提供最强有力的稳定性保障。

立即跳转火山引擎ByteHouse官网了解详情