如何為ClickHouse增強(qiáng)高可用能力

相信大家都對(duì)大名鼎鼎的ClickHouse有一定的了解了，它強(qiáng)大的數(shù)據(jù)分析性能讓人印象深刻。但在字節(jié)大量生產(chǎn)使用中，發(fā)現(xiàn)了ClickHouse依然存在了一定的限制。例如：

缺少完整的upsert和delete操作

多表關(guān)聯(lián)查詢(xún)能力弱

集群規(guī)模較大時(shí)可用性下降（對(duì)字節(jié)尤其如此）

沒(méi)有資源隔離能力

因此，我們決定將ClickHouse能力進(jìn)行全方位加強(qiáng)，打造一款更強(qiáng)大的數(shù)據(jù)分析平臺(tái)。后面我們將從五個(gè)方面來(lái)和大家分享，本篇將詳細(xì)介紹我們是如何為ClickHouse增強(qiáng)高可用能力的。

字節(jié)遇到的ClickHouse可用性問(wèn)題

隨著字節(jié)業(yè)務(wù)的快速發(fā)展，產(chǎn)品快速擴(kuò)張，承載業(yè)務(wù)的ClickHouse集群節(jié)點(diǎn)數(shù)也快速增加。另一方面，按照天進(jìn)行的數(shù)據(jù)分區(qū)也快速增加，一個(gè)集群管理的庫(kù)表特別多，開(kāi)始出現(xiàn)元數(shù)據(jù)不一致的情況。兩方面結(jié)合，導(dǎo)致集群的可用性極速下降，以至于到了業(yè)務(wù)難以接受的程度。直觀的問(wèn)題有三類(lèi)：

1、故障變多

典型的例子如硬件故障，幾乎每天都會(huì)出現(xiàn)。另外，當(dāng)集群達(dá)到一定的規(guī)模，Zookeeper會(huì)成為瓶頸，增加故障發(fā)生頻率。

2、故障恢復(fù)時(shí)間長(zhǎng)

因?yàn)閿?shù)據(jù)分區(qū)變多，導(dǎo)致一旦發(fā)生故障，恢復(fù)時(shí)間經(jīng)常會(huì)需要1個(gè)小時(shí)以上，這是業(yè)務(wù)方完全不能接受的。

3、運(yùn)維復(fù)雜度提升

以往只需要一個(gè)人負(fù)責(zé)運(yùn)維的集群，由于節(jié)點(diǎn)增加和分區(qū)變多，運(yùn)維復(fù)雜度和難度成倍的增加，目前運(yùn)維人數(shù)增加了幾人也依然拙荊見(jiàn)肘，依然難保證集群的穩(wěn)定運(yùn)行。

可用性問(wèn)題已經(jīng)成為制約業(yè)務(wù)發(fā)展的重要問(wèn)題，因此我們決定將影響高可用的問(wèn)題一一拆解，并逐個(gè)解決。

提升高可用能力的方案

一、降低Zookeeper壓力

問(wèn)題所在：

原生ClickHouse 使用 ReplicatedMergeTree 引擎來(lái)實(shí)現(xiàn)數(shù)據(jù)同步。原理上，ReplicatedMergeTree 基于 ZooKeeper 完成多副本的選主、數(shù)據(jù)同步、故障恢復(fù)等功能。由于 ReplicatedMergeTree 對(duì) ZooKeeper 的使用比較重，除了每組副本一些表級(jí)別的元信息，還存儲(chǔ)了邏輯日志、part 信息等潛在數(shù)量級(jí)較大的信息。Zookeeper并不是一個(gè)能做到良好線性擴(kuò)展的系統(tǒng)，當(dāng)ZooKeeper 在相對(duì)較高的負(fù)載情況下運(yùn)行時(shí)，往往性能表現(xiàn)并不佳，甚至?xí)霈F(xiàn)副本無(wú)法寫(xiě)入，數(shù)據(jù)也無(wú)法同步的情況。在字節(jié)內(nèi)部實(shí)際使用和運(yùn)維 ClickHouse 的過(guò)程中，ZooKeeper 也是非常容易成為一個(gè)瓶頸的組件。

改造思路：

ReplicatedMergeTree 支持 insert_quorum，insert_quorum 是指如果副本數(shù)為3，insert_quorum=2，要成功寫(xiě)入至少兩個(gè)副本才會(huì)返回寫(xiě)入成功。

新分區(qū)在副本之間復(fù)制的流程如下：

可以看到，反復(fù)在 zookeeper 中進(jìn)行分發(fā)日志、數(shù)據(jù)交換等步驟，這正是引起瓶頸的原因之一。

為了降低對(duì) ZooKeeper 的負(fù)載，在ByteHouse中重新實(shí)現(xiàn)了一套 HaMergeTree 引擎。通過(guò)HaMergeTree降低對(duì) ZooKeeper 的請(qǐng)求次數(shù)，減少在 ZooKeeper 上存儲(chǔ)的數(shù)據(jù)量，新的 HaMergeTree 同步引擎：

1）保留ZooKeeper上表級(jí)別的元信息；

2）簡(jiǎn)化邏輯日志的分配；

3）將 part 信息從 ZooKeeper 日志移除。

HaMergeTree 減少了操作日志等信息在zookeeper里面的存放，來(lái)減少zookeeper的負(fù)載，zookeeper里面只是存放log LSN, 具體日志在副本之間通過(guò)gossip協(xié)議同步回放。

在保持和ReplicatedMergeTree完全兼容的前提下，新的 HaMergeTree 極大減輕了對(duì) ZooKeeper 的負(fù)載，實(shí)現(xiàn)了 ZooKeeper 集群的壓力與數(shù)據(jù)量不相關(guān)。上線后，因Zookeeper導(dǎo)致的異常大量減少。無(wú)論是單集群幾百甚至上千節(jié)點(diǎn)，還是單節(jié)點(diǎn)上萬(wàn)張表，都能保障良好的穩(wěn)定性。

二、提升故障恢復(fù)能力

問(wèn)題所在：

雖然所有數(shù)據(jù)從業(yè)者都在做各種努力，想要保證線上生產(chǎn)環(huán)境不出故障，但是現(xiàn)實(shí)中還是難以避免會(huì)遇到各式各樣的問(wèn)題。主要是由下面這幾種因素引起的：

軟件缺陷：軟件設(shè)計(jì)本身的Bug引起的系統(tǒng)非正常終止，或依賴(lài)的組件兼容引發(fā)的問(wèn)題。

硬件故障：常見(jiàn)的有磁盤(pán)損壞、內(nèi)容故障、CPU故障等，當(dāng)集群規(guī)模擴(kuò)大后發(fā)生的頻率也線性增加。

內(nèi)存溢出導(dǎo)致進(jìn)程被停止：在OLAP數(shù)據(jù)庫(kù)中經(jīng)常發(fā)生。

意外因素：如斷電、誤操作等引發(fā)的問(wèn)題。

由于原生ClickHouse希望達(dá)到極致性能的初衷，所以在ClickHouse系統(tǒng)中元數(shù)據(jù)常駐于內(nèi)存中，這導(dǎo)致了ClickHouse server重啟時(shí)間非常長(zhǎng)。因而當(dāng)故障發(fā)生后，恢復(fù)的時(shí)間也很長(zhǎng)，動(dòng)輒一到兩個(gè)小時(shí)，相當(dāng)于業(yè)務(wù)也要中斷一到兩個(gè)小時(shí)。當(dāng)故障頻繁出現(xiàn)，造成的業(yè)務(wù)損失是無(wú)法估量的。

改造思路：

為了解決上述問(wèn)題，在ByteHouse中采用了元數(shù)據(jù)持久化的方案，將元數(shù)據(jù)持久化到RocksDB， Server啟動(dòng)時(shí)直接從RocksDB加載元數(shù)據(jù)，內(nèi)存中也僅僅存放必要的Part信息。因此可以減少元數(shù)據(jù)對(duì)內(nèi)存的占用，以及加速集群的啟動(dòng)以及故障恢復(fù)時(shí)間。

如下圖所示，元數(shù)據(jù)持久化整體上采用了RocksDB+Meta in Memory的方式，每個(gè)Table都會(huì)對(duì)應(yīng)一個(gè)RocksDB數(shù)據(jù)庫(kù)存放該表所有Part的元信息。Table首次啟動(dòng)時(shí)，從文件系統(tǒng)中加載的Part元數(shù)據(jù)將被持久化到RocksDB中；之后重啟時(shí)就可以直接從RocksDB中加載Part。每個(gè)表從RocksDB或者文件系統(tǒng)加載的Part將只在內(nèi)存中存放必要的Part信息。在實(shí)際使用Part時(shí)，將通過(guò)內(nèi)存中存放的Part元信息去RocksDB中讀取并加載對(duì)應(yīng)Part。

完成元數(shù)據(jù)持久化后，在性能基本無(wú)損失的情況下，單機(jī)支持的part不再受內(nèi)存容量的限制，可以達(dá)到100萬(wàn)以上。最重要的是，故障恢復(fù)的時(shí)間顯著縮短，只需要此前的幾十分之一的時(shí)間就可以完成。例如在原生ClickHouse中需要一到兩個(gè)小時(shí)的恢復(fù)時(shí)間，在ByteHouse中只需要3分鐘，大大提高的系統(tǒng)的高可用能力，為業(yè)務(wù)提供了堅(jiān)實(shí)保障。

三、其他方面

除了以上兩點(diǎn)，在ByteHouse中在其他很多方面都為高可用能力做了增強(qiáng)，如通過(guò)HaKafka引擎提升了數(shù)據(jù)寫(xiě)入的高可用性，提升實(shí)時(shí)數(shù)據(jù)寫(xiě)入的容錯(cuò)率，可自動(dòng)切換主備寫(xiě)入；增加了監(jiān)控運(yùn)維平臺(tái)，實(shí)現(xiàn)對(duì)關(guān)鍵指標(biāo)的監(jiān)控、告警；增加多種問(wèn)題診斷工具，能實(shí)現(xiàn)故障的快速定位。

對(duì)于數(shù)據(jù)分析平臺(tái)來(lái)說(shuō)，穩(wěn)定性是重中之重。我們對(duì)ByteHouse的高可用能力的提升是不會(huì)停止的，在極致性能的背后，力圖為用戶(hù)提供最強(qiáng)有力的穩(wěn)定性保障。