相信大家都對大名鼎鼎的ClickHouse有一定的了解了,它強大的數(shù)據(jù)分析性能讓人印象深刻。但在字節(jié)大量生產(chǎn)使用中,發(fā)現(xiàn)了ClickHouse依然存在了一定的限制。例如:
- 缺少完整的upsert和delete操作
- 多表關(guān)聯(lián)查詢能力弱
- 集群規(guī)模較大時可用性下降(對字節(jié)尤其如此)
- 沒有資源隔離能力
因此,我們決定將ClickHouse能力進行全方位加強,打造一款更強大的數(shù)據(jù)分析平臺。后面我們將從五個方面來和大家分享,本篇將詳細介紹我們是如何為ClickHouse增強資源隔離能力的。
廣告業(yè)務(wù)遇到的資源管控問題
ClickHouse的資源管控能力不夠完善,在 insert、select 并發(fā)高的場景下會導致執(zhí)行失敗,影響用戶體驗。這是因為社區(qū)版ClickHouse目前僅提供依據(jù)不同用戶的最大內(nèi)存控制,在超過閾值時會殺死執(zhí)行的 query。
在字節(jié)的廣告業(yè)務(wù)中,需要區(qū)分不同查詢的優(yōu)先級;對查詢性能抖動的容忍度較低;同時也需要支持adhoc能力;查詢類型廣泛、資源占用可能會較多。
ClickHouse提供的粗粒度并發(fā)控制不能滿足需求;
- 無法靈活控制并發(fā),導致查詢迅速占滿集群資源,部分后來的高優(yōu)查詢持續(xù)pending,導致報錯。
- 無法給特定業(yè)務(wù)預留cpu資源,出現(xiàn)大查詢占滿cpu,而后來的查詢執(zhí)行時間大幅增加。
ByteHouse的解決方案:Resource Group
在這種情況下,字節(jié)在ByteHouse(字節(jié)基于ClickHouse能力增強的版本)中開發(fā)了資源管理的組件:Resource Group。
基本思路是將并發(fā)、內(nèi)存、CPU等資源拆分給不同的資源組,同時通過資源組的父子關(guān)系實現(xiàn)不同資源組共享部分資源的能力。當用戶的查詢提交給引擎,依照定義的規(guī)則選定相應(yīng)的資源組,然后評估該資源組以及父資源組是否能夠執(zhí)行該查詢,如是則直接執(zhí)行,否則進入該資源組的等待隊列,等待資源釋放。
并發(fā)控制
max_concurrent_queries 配置項控制一個資源組能夠同時運行的查詢上限。當資源組并發(fā)達到上限,或者該資源組的父資源組并發(fā)達到上限,引擎會把查詢放入該資源組的等待隊列。當該資源組有一個查詢結(jié)束,引擎會執(zhí)行該資源組等待隊列中最早的查詢;如果此時該資源組等待隊列為空,則會觸發(fā)父資源組的資源釋放,進一步觸發(fā)該父資源組的其他子資源組的等待隊列查詢執(zhí)行,實現(xiàn)并發(fā)quota在一個父資源組之間的共享。
內(nèi)存控制
每一個資源組可以配置一個軟性的內(nèi)存上限,當資源組中的查詢使用內(nèi)存超過這個軟性限制之后,新查詢將會進入等待隊列。和并發(fā)控制類似,內(nèi)存也會判斷父資源組的限制,并使用類似的邏輯實現(xiàn)內(nèi)存在一個父資源組之間的共享。
由于目前還沒有一個準確的查詢占用內(nèi)存預估的模型,當前采取的策略是預估+實際內(nèi)存矯正的模式,當一個新查詢進入時,引擎會按照預估內(nèi)存評估是否可以執(zhí)行,在開始執(zhí)行之后則是利用查詢現(xiàn)有的memory_tracker在下一輪判斷之前矯正預估值。
此軟性的內(nèi)存限制不同于原生ClickHouse的硬性內(nèi)存限制,并不會殺死已經(jīng)在執(zhí)行的查詢,而是用于控制新查詢的可執(zhí)行判斷,因此可以配合使用。
CPU控制
ByteHouse使用cgroups提供的cpu controller實現(xiàn)資源組的CPU控制。Cpu controler通過使用 CFS 調(diào)度器將CPU資源按照相同的時間分片進行分配,以實現(xiàn)不同group按照預定義的cpu shares占用相應(yīng)的CPU資源。
在ByteHouse內(nèi)部,我們實現(xiàn)了一個新的線程池類,在該類中給查詢分配線程資源時,會依據(jù)當前Context中記錄的資源組信息分配關(guān)聯(lián)到相應(yīng)cgroup的線程。
由于采用的CFS調(diào)度器,我們可以很容易的得到以下結(jié)論:
-
當所有資源組都有查詢在執(zhí)行時,每個資源組可以使用的CPU比例為 cpu_shares / sum(cpu_shares)
-
當只有一個資源組有查詢在執(zhí)行時,該資源組可以使用的CPU比例為 100%
因此每個資源組可以使用的CPU資源比例范圍就是 [cpu_shares/sum(cpu_shares), 100%],通過這個功能我們也就實現(xiàn)了兩個預期效果:
-
保證了每個資源可以使用的CPU資源下限
-
保證了在任何workload情況下服務(wù)器CPU資源的總體利用率
Resource Group帶來的效果提升
Resource Group能夠顯著的提升查詢體驗,為優(yōu)先業(yè)務(wù)的查詢提供保障,并且減小查詢返回時間的方差。與此同時,也能夠為集群穩(wěn)定性帶來提升,不會因為OOM殺死執(zhí)行中的查詢,以及防止一個服務(wù)出現(xiàn)故障而拖垮整個集群。
ByteHouse的Resource Group主要有以下優(yōu)點:
-
能夠在CPU、內(nèi)存、并發(fā)控制等全方位的提供資源隔離的能力
-
可以限制低優(yōu)先級查詢帶來的影響
-
降低寫入語句可能帶來的不良影響
在上文提到的廣告業(yè)務(wù)中,使用ByteHouse替換ClickHouse后,查詢時間明顯縮短,體驗明顯改善。
應(yīng)用前:
應(yīng)用后:
可以看到上線前用戶每天的查詢平均耗時在2.3s到14.1s之間抖動,十分劇烈,用戶的使用體驗很差。上線后每天的查詢平均耗時則在0.4s到1.7s之之間抖動,較好的保證了該優(yōu)先業(yè)務(wù)的查詢資源,并且顯著縮短的平均查詢返回時間。
這是本次ClickHouse增強計劃系列文章的最后一篇啦,除了這五篇文章提到的能力,ByteHouse還有有一個與ClickHouse使用不同執(zhí)行引擎的版本,能夠?qū)崿F(xiàn)全面的存算分離,是真正的云原生數(shù)據(jù)倉庫!后續(xù)我們也將為大家?guī)?a href="http://www.1cnz.cn/article/zt/" target="_blank">專題介紹。
審核編輯 :李倩
-
內(nèi)存
+關(guān)注
關(guān)注
8文章
3020瀏覽量
74008 -
資源
+關(guān)注
關(guān)注
0文章
59瀏覽量
17781 -
數(shù)據(jù)分析
+關(guān)注
關(guān)注
2文章
1446瀏覽量
34050
原文標題:火山引擎:ClickHouse增強計劃之“資源隔離”
文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論