相信大家都對大名鼎鼎的ClickHouse有一定的了解了，它強大的數據分析性能讓人印象深刻。但在字節大量生產使用中，發現了ClickHouse依然存在了一定的限制。例如：

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

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

廣告業務遇到的資源管控問題

ClickHouse的資源管控能力不夠完善，在 insert、select 并發高的場景下會導致執行失敗，影響用戶體驗。這是因為社區版ClickHouse目前僅提供依據不同用戶的最大內存控制，在超過閾值時會殺死執行的 query。

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

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

1. 無法靈活控制并發，導致查詢迅速占滿集群資源，部分后來的高優查詢持續pending，導致報錯。
2. 無法給特定業務預留cpu資源，出現大查詢占滿cpu，而后來的查詢執行時間大幅增加。

ByteHouse的解決方案：Resource Group

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

基本思路是將并發、內存、CPU等資源拆分給不同的資源組，同時通過資源組的父子關系實現不同資源組共享部分資源的能力。當用戶的查詢提交給引擎，依照定義的規則選定相應的資源組，然后評估該資源組以及父資源組是否能夠執行該查詢，如是則直接執行，否則進入該資源組的等待隊列，等待資源釋放。

并發控制

max_concurrent_queries 配置項控制一個資源組能夠同時運行的查詢上限。當資源組并發達到上限，或者該資源組的父資源組并發達到上限，引擎會把查詢放入該資源組的等待隊列。當該資源組有一個查詢結束，引擎會執行該資源組等待隊列中最早的查詢；如果此時該資源組等待隊列為空，則會觸發父資源組的資源釋放，進一步觸發該父資源組的其他子資源組的等待隊列查詢執行，實現并發quota在一個父資源組之間的共享。

內存控制

每一個資源組可以配置一個軟性的內存上限，當資源組中的查詢使用內存超過這個軟性限制之后，新查詢將會進入等待隊列。和并發控制類似，內存也會判斷父資源組的限制，并使用類似的邏輯實現內存在一個父資源組之間的共享。

由于目前還沒有一個準確的查詢占用內存預估的模型，當前采取的策略是預估+實際內存矯正的模式，當一個新查詢進入時，引擎會按照預估內存評估是否可以執行，在開始執行之后則是利用查詢現有的memory_tracker在下一輪判斷之前矯正預估值。

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

CPU控制

ByteHouse使用cgroups提供的cpu controller實現資源組的CPU控制。Cpu controler通過使用 CFS 調度器將CPU資源按照相同的時間分片進行分配，以實現不同group按照預定義的cpu shares占用相應的CPU資源。

在ByteHouse內部，我們實現了一個新的線程池類，在該類中給查詢分配線程資源時，會依據當前Context中記錄的資源組信息分配關聯到相應cgroup的線程。

由于采用的CFS調度器，我們可以很容易的得到以下結論：

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

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

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

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

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

Resource Group帶來的效果提升

Resource Group能夠顯著的提升查詢體驗，為優先業務的查詢提供保障，并且減小查詢返回時間的方差。與此同時，也能夠為集群穩定性帶來提升，不會因為OOM殺死執行中的查詢，以及防止一個服務出現故障而拖垮整個集群。

ByteHouse的Resource Group主要有以下優點：

• 能夠在CPU、內存、并發控制等全方位的提供資源隔離的能力

• 可以限制低優先級查詢帶來的影響

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

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

應用前：

應用后：

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

這是本次ClickHouse增強計劃系列文章的最后一篇啦，除了這五篇文章提到的能力，ByteHouse還有有一個與ClickHouse使用不同執行引擎的版本，能夠實現全面的存算分離，是真正的云原生數據倉庫！后續我們也將為大家帶來專題介紹。

審核編輯 ：李倩