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

• 缺少完整的upsert和delete操作
• 多表關(guān)聯(lián)查詢能力弱
• 集群規(guī)模較大時可用性下降（對字節(jié)尤其如此）
• 沒有資源隔離能力

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

廣告業(yè)務(wù)遇到的資源管控問題

ClickHouse的資源管控能力不夠完善，在 insert、select 并發(fā)高的場景下會導(dǎo)致執(zhí)行失敗，影響用戶體驗(yàn)。這是因?yàn)樯鐓^(qū)版ClickHouse目前僅提供依據(jù)不同用戶的最大內(nèi)存控制，在超過閾值時會殺死執(zhí)行的 query。

在字節(jié)的廣告業(yè)務(wù)中，需要區(qū)分不同查詢的優(yōu)先級；對查詢性能抖動的容忍度較低；同時也需要支持adhoc能力；查詢類型廣泛、資源占用可能會較多。

ClickHouse提供的粗粒度并發(fā)控制不能滿足需求；

1. 無法靈活控制并發(fā)，導(dǎo)致查詢迅速占滿集群資源，部分后來的高優(yōu)查詢持續(xù)pending，導(dǎo)致報錯。
2. 無法給特定業(yè)務(wù)預(yù)留cpu資源，出現(xiàn)大查詢占滿cpu，而后來的查詢執(zhí)行時間大幅增加。

ByteHouse的解決方案：Resource Group

在這種情況下，字節(jié)在ByteHouse（字節(jié)基于ClickHouse能力增強(qiáng)的版本）中開發(fā)了資源管理的組件：Resource Group。

基本思路是將并發(fā)、內(nèi)存、CPU等資源拆分給不同的資源組，同時通過資源組的父子關(guān)系實(shí)現(xiàn)不同資源組共享部分資源的能力。當(dāng)用戶的查詢提交給引擎，依照定義的規(guī)則選定相應(yīng)的資源組，然后評估該資源組以及父資源組是否能夠執(zhí)行該查詢，如是則直接執(zhí)行，否則進(jìn)入該資源組的等待隊(duì)列，等待資源釋放。

并發(fā)控制

max_concurrent_queries 配置項(xiàng)控制一個資源組能夠同時運(yùn)行的查詢上限。當(dāng)資源組并發(fā)達(dá)到上限，或者該資源組的父資源組并發(fā)達(dá)到上限，引擎會把查詢放入該資源組的等待隊(duì)列。當(dāng)該資源組有一個查詢結(jié)束，引擎會執(zhí)行該資源組等待隊(duì)列中最早的查詢；如果此時該資源組等待隊(duì)列為空，則會觸發(fā)父資源組的資源釋放，進(jìn)一步觸發(fā)該父資源組的其他子資源組的等待隊(duì)列查詢執(zhí)行，實(shí)現(xiàn)并發(fā)quota在一個父資源組之間的共享。

內(nèi)存控制

每一個資源組可以配置一個軟性的內(nèi)存上限，當(dāng)資源組中的查詢使用內(nèi)存超過這個軟性限制之后，新查詢將會進(jìn)入等待隊(duì)列。和并發(fā)控制類似，內(nèi)存也會判斷父資源組的限制，并使用類似的邏輯實(shí)現(xiàn)內(nèi)存在一個父資源組之間的共享。

由于目前還沒有一個準(zhǔn)確的查詢占用內(nèi)存預(yù)估的模型，當(dāng)前采取的策略是預(yù)估+實(shí)際內(nèi)存矯正的模式，當(dāng)一個新查詢進(jìn)入時，引擎會按照預(yù)估內(nèi)存評估是否可以執(zhí)行，在開始執(zhí)行之后則是利用查詢現(xiàn)有的memory_tracker在下一輪判斷之前矯正預(yù)估值。

此軟性的內(nèi)存限制不同于原生ClickHouse的硬性內(nèi)存限制，并不會殺死已經(jīng)在執(zhí)行的查詢，而是用于控制新查詢的可執(zhí)行判斷，因此可以配合使用。

CPU控制

ByteHouse使用cgroups提供的cpu controller實(shí)現(xiàn)資源組的CPU控制。Cpu controler通過使用 CFS 調(diào)度器將CPU資源按照相同的時間分片進(jìn)行分配，以實(shí)現(xiàn)不同group按照預(yù)定義的cpu shares占用相應(yīng)的CPU資源。

在ByteHouse內(nèi)部，我們實(shí)現(xiàn)了一個新的線程池類，在該類中給查詢分配線程資源時，會依據(jù)當(dāng)前Context中記錄的資源組信息分配關(guān)聯(lián)到相應(yīng)cgroup的線程。

由于采用的CFS調(diào)度器，我們可以很容易的得到以下結(jié)論：

1. 當(dāng)所有資源組都有查詢在執(zhí)行時，每個資源組可以使用的CPU比例為 cpu_shares / sum(cpu_shares)

2. 當(dāng)只有一個資源組有查詢在執(zhí)行時，該資源組可以使用的CPU比例為 100%

因此每個資源組可以使用的CPU資源比例范圍就是 [cpu_shares/sum(cpu_shares), 100%],通過這個功能我們也就實(shí)現(xiàn)了兩個預(yù)期效果：

1. 保證了每個資源可以使用的CPU資源下限

2. 保證了在任何workload情況下服務(wù)器CPU資源的總體利用率

Resource Group帶來的效果提升

Resource Group能夠顯著的提升查詢體驗(yàn)，為優(yōu)先業(yè)務(wù)的查詢提供保障，并且減小查詢返回時間的方差。與此同時，也能夠?yàn)榧悍€(wěn)定性帶來提升，不會因?yàn)镺OM殺死執(zhí)行中的查詢，以及防止一個服務(wù)出現(xiàn)故障而拖垮整個集群。

ByteHouse的Resource Group主要有以下優(yōu)點(diǎn)：

• 能夠在CPU、內(nèi)存、并發(fā)控制等全方位的提供資源隔離的能力

• 可以限制低優(yōu)先級查詢帶來的影響

• 降低寫入語句可能帶來的不良影響

在上文提到的廣告業(yè)務(wù)中，使用ByteHouse替換ClickHouse后，查詢時間明顯縮短，體驗(yàn)明顯改善。

應(yīng)用前：

應(yīng)用后：

可以看到上線前用戶每天的查詢平均耗時在2.3s到14.1s之間抖動，十分劇烈，用戶的使用體驗(yàn)很差。上線后每天的查詢平均耗時則在0.4s到1.7s之之間抖動，較好的保證了該優(yōu)先業(yè)務(wù)的查詢資源，并且顯著縮短的平均查詢返回時間。

這是本次ClickHouse增強(qiáng)計(jì)劃系列文章的最后一篇啦，除了這五篇文章提到的能力，ByteHouse還有有一個與ClickHouse使用不同執(zhí)行引擎的版本，能夠?qū)崿F(xiàn)全面的存算分離，是真正的云原生數(shù)據(jù)倉庫！后續(xù)我們也將為大家?guī)韺ｎ}介紹。

審核編輯 ：李倩