隨著技術(shù)的發(fā)展和數(shù)據(jù)庫部署規(guī)模的持續(xù)擴(kuò)大，資源隔離的應(yīng)用場景在數(shù)據(jù)倉庫中變得越來越重要。如果數(shù)據(jù)量過大，ClickHouse無法靈活控制并發(fā)，將導(dǎo)致查詢迅速占滿集群資源，造成報(bào)錯(cuò)。同時(shí)，由于無法給特定業(yè)務(wù)預(yù)留CPU資源，后續(xù)查詢的執(zhí)行時(shí)間也會(huì)大幅增加。這些問題不僅影響了業(yè)務(wù)的穩(wěn)定性，也限制了查詢的效率。
ByteHouse是火山引擎推出的云原生數(shù)據(jù)倉庫，以開源的ClickHouse為基礎(chǔ)，經(jīng)過字節(jié)跳動(dòng)內(nèi)部多年的優(yōu)化和完善，提供了更豐富的功能和更強(qiáng)的性能，主要為用戶帶來極速的分析體驗(yàn)。
據(jù)了解，在字節(jié)跳動(dòng)內(nèi)部也存在數(shù)據(jù)量過大，ClickHouse無法滿足資源隔離需求的問題。為了解決這一問題，火山引擎ByteHouse推出了Resource Group資源管理組件。
Resource Group資源管理組件的基本思路是將并發(fā)、內(nèi)存、CPU等資源拆分給不同的資源組，通過資源組之間的關(guān)系調(diào)度共享資源能力。例如，當(dāng)用戶將查詢提交給引擎時(shí)，依據(jù)規(guī)則評估是否能執(zhí)行該查詢，如果可以，查詢將被直接執(zhí)行;否則，查詢將進(jìn)入該資源組的等待隊(duì)列，等待資源的釋放。
這種方式存在以下優(yōu)勢：通過將并發(fā)、內(nèi)存、CPU等資源拆分給不同的資源組，可以更加靈活地控制資源的分配，從而避免查詢迅速占滿集群資源的問題。其次，通過資源組的父子關(guān)系，可以實(shí)現(xiàn)不同資源組之間的資源共享，提高資源的利用率。
應(yīng)用前：
應(yīng)用后：
通過靈活的資源分配策略和高效的資源利用方式，ByteHouse的Resource Group能力可以提高查詢的穩(wěn)定性和效率，為用戶提供更好的使用體驗(yàn)。
據(jù)介紹，上線前，用戶每天的查詢平均耗時(shí)在2.3s到14.1s之間，抖動(dòng)劇烈，用戶體驗(yàn)較差。而上線后，每天的查詢平均耗時(shí)則在0.4s到1.7s之間，較好的保證了優(yōu)先業(yè)務(wù)的查詢資源，并且顯著縮短了平均查詢返回時(shí)間。
