共计 2623 个字符，预计需要花费 7 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【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 官网理解详情