數(shù)據(jù)湖 | 數(shù)據(jù)湖分析算力隔離技術(shù)剖析
一、背景介紹
根據(jù)MarketsandMarkets市場(chǎng)調(diào)研顯示，預(yù)計(jì)數(shù)據(jù)湖市場(chǎng)規(guī)模在2024年將從2019年的79億美金增長(zhǎng)到201億美金。隨著數(shù)據(jù)湖的規(guī)模增長(zhǎng)，基于交互式查詢引擎Presto的數(shù)據(jù)湖分析負(fù)載也隨著增加。在共享的Presto集群里，大查詢之間非常容易相互影響，在此背景下對(duì)查詢進(jìn)行算力隔離也就迫在眉睫。本文主要介紹數(shù)據(jù)湖分析引擎Presto如何解決多租戶算力隔離的技術(shù)。
二、數(shù)據(jù)湖分析Presto算力隔離遇到的挑戰(zhàn)
1、數(shù)據(jù)湖分析Presto方案架構(gòu)
Presto是一個(gè)定位大數(shù)據(jù)分析領(lǐng)域的分布式SQL查詢引擎，適合GB到PB級(jí)別的數(shù)據(jù)的交互式分析查詢。與Hive、Spark等其他查詢引擎不同，它是一個(gè)全內(nèi)存計(jì)算的MPP引擎，能快速獲取查詢結(jié)果，因此它特別適合進(jìn)行adhoc查詢、數(shù)據(jù)探索、BI報(bào)表、輕量ETL等多種業(yè)務(wù)場(chǎng)景。下圖以阿里云數(shù)據(jù)湖分析（簡(jiǎn)稱DLA）的Presto架構(gòu)為例說(shuō)明。
FrontNode：整個(gè)架構(gòu)的接入層FrontNode，它通過(guò)MySQL協(xié)議提供服務(wù)，只要兼容MySQL協(xié)議的客戶端、BI工具可以直接連接并提交查詢，它接收到SQL后，會(huì)對(duì)SQL做解析，轉(zhuǎn)換為Presto風(fēng)格的SQL，并調(diào)度到相應(yīng)的Presto集群。
Presto引擎：中間的Presto計(jì)算引擎，適合交互查詢，用戶可以根據(jù)業(yè)務(wù)特點(diǎn)，如果是頻繁類型的查詢，適合選擇獨(dú)享集群；若是偶發(fā)類型的查詢，適合Serverless類型的共享集群。
元數(shù)據(jù)：左側(cè)是統(tǒng)一元數(shù)據(jù)，相對(duì)Presto原生的元數(shù)據(jù)，它能統(tǒng)一管理所有Connector的元數(shù)據(jù)，并支持多租戶的權(quán)限控制；并提供了MySQL風(fēng)格的GRANT/REVOKE機(jī)制，便于租戶內(nèi)的子賬戶權(quán)限管理。
存儲(chǔ)層：底層是存儲(chǔ)層，Presto并不自帶存儲(chǔ)，但它支持許多的數(shù)據(jù)源，并支持不同數(shù)據(jù)源之間的關(guān)聯(lián)查詢。
2、數(shù)據(jù)湖分析Presto算力隔離遇到的挑戰(zhàn)
社區(qū)原生的Presto在多租戶隔離場(chǎng)景考慮的比較少，主要通過(guò)ResourceGroup機(jī)制限制每個(gè)資源組的資源（包括CPU和內(nèi)存）上限，它最大的問(wèn)題是只能限制新的查詢，即一個(gè)Group的資源用超后，其新提交的查詢會(huì)被排隊(duì)，直到其使用的資源降到上限之下；對(duì)于正在執(zhí)行的查詢?nèi)绻^(guò)資源組的資源上限，ResourceGroup不會(huì)做限制。因此在一個(gè)共享的Presto集群中，一個(gè)大查詢還是可以把整個(gè)集群的資源消耗完，從而影響其他用戶的查詢。在DLA實(shí)際生產(chǎn)過(guò)程中，上千用戶共享的集群，此問(wèn)題尤為突出。
與Spark、Hive等其他查詢引擎可以簡(jiǎn)單設(shè)置執(zhí)行資源并發(fā)限制資源不同，Presto首先需要預(yù)先啟動(dòng)所有Stage，并且所有查詢?cè)赪orker執(zhí)行時(shí)共享線程和內(nèi)存，因此無(wú)法通過(guò)簡(jiǎn)單地設(shè)置執(zhí)行的并發(fā)控制其資源的使用。
業(yè)界采用比較多的解決方案是：基于Presto On Yarn實(shí)現(xiàn)資源隔離。為每個(gè)資源組啟動(dòng)一個(gè)獨(dú)立的Presto On Yarn集群，并通過(guò)Yarn的資源管理機(jī)制實(shí)現(xiàn)Presto集群之間的隔離。其優(yōu)點(diǎn)是資源隔離比較好；但需要預(yù)先為每個(gè)租戶啟動(dòng)一個(gè)專屬的集群，即使沒(méi)有查詢?cè)趫?zhí)行也需要維護(hù)該集群，在數(shù)據(jù)湖分析Serverless服務(wù)場(chǎng)景，租戶較多，且他們的查詢很多都是間歇性的，其資源消耗也不穩(wěn)定，無(wú)法預(yù)估。因此如果為每個(gè)用戶都啟動(dòng)一個(gè)專屬集群，會(huì)導(dǎo)致嚴(yán)重的資源浪費(fèi)。
三、基于實(shí)時(shí)懲罰機(jī)制實(shí)現(xiàn)DLA Presto的算力隔離技術(shù)解析
1、社區(qū)Presto的Query執(zhí)行與調(diào)度原理
下面以一個(gè)聚合類型的查詢?yōu)槔?jiǎn)要介紹社區(qū)Presto的Query（查詢）執(zhí)行原理。
Select id, sum(money) from employ where id>10000 group by id;注：*左右滑動(dòng)閱覽
一個(gè)查詢會(huì)被解析為包含多個(gè)Stage的物理執(zhí)行計(jì)劃，每個(gè)Stage包含若干Task，Task會(huì)被Coordinator調(diào)度到Worker上執(zhí)行。在Worker上，每個(gè)Task會(huì)包含多個(gè)Driver，每個(gè)Driver對(duì)應(yīng)一個(gè)Split（數(shù)據(jù)切片）；每個(gè)Driver會(huì)包含若干操作算子Operator。
它在Presto上的調(diào)度邏輯如下圖所示，在主節(jié)點(diǎn)Coordinator和從節(jié)點(diǎn)Worker都有相應(yīng)的調(diào)度邏輯。
在Coordinator上，主要負(fù)責(zé)多租戶Group之間和Group內(nèi)的Query調(diào)度。若Group使用的資源未達(dá)到上限，則Query會(huì)被解析并調(diào)度。Query解析后，以Task為單位，一次性把所有Stage的Task分配給Worker。
Worker會(huì)根據(jù)數(shù)據(jù)切片Split生成Driver，并放到調(diào)度隊(duì)列。Worker執(zhí)行Split以時(shí)間片為單位，一次最多只執(zhí)行1秒，未完成則繼續(xù)放入排隊(duì)隊(duì)列。
2、基于實(shí)時(shí)懲罰機(jī)制的核心思想
數(shù)據(jù)切片Split的執(zhí)行基于CPU時(shí)間片可以做進(jìn)一步的限制：實(shí)時(shí)統(tǒng)計(jì)每個(gè)Group消耗的CPU時(shí)間，當(dāng)Group累計(jì)每秒消耗的CPU時(shí)間超過(guò)其配置的資源上限，則開(kāi)始懲罰該Group，即不再執(zhí)行其Split，直到其累計(jì)CPU消耗小于資源上限。
舉例的描述：GroupA的配置可使用的CPU核數(shù)上限為N，Coordinator每秒為GroupA生成N秒的CPU時(shí)間片，當(dāng)GroupA的查詢執(zhí)行時(shí)，實(shí)時(shí)統(tǒng)計(jì)GroupA的CPU消耗，其每秒的CPU消耗為cpus，累計(jì)消耗為Csum，每秒都需要讓Csum加上cpus，然后做如下的判斷邏輯：
如果 Csum <= N：下一秒不需要懲罰；并重置Csum = 0。
如果 Csum >= 2N，需要懲罰1秒，下一秒GroupA的所有Split都不會(huì)被調(diào)度執(zhí)行；并設(shè)置Csum = Csum - N。
如果 N < Csum < 2N，下一秒不會(huì)被懲罰，但Csum-N的值會(huì)進(jìn)入下一秒的判斷邏輯，下一秒被懲罰的概率會(huì)加大；并設(shè)置Csum = Csum - N。
上圖以N=3為例舉例說(shuō)明：
第一秒 cpus=2，Csum=2；下一秒不懲罰。
第二秒 cpus=5，Csum=5；下一秒不懲罰。
第三秒 cpus=4，Csum=6；下一秒懲罰。
第四秒 cpus=0，Csum=3；下一秒不懲罰
第五秒 cpus=7，Csum=7；下一秒懲罰。
第六秒 cpus=0，Csum=4；下一秒不懲罰。
第七秒 cpus=5，Csum=6；下一秒懲罰。
第八秒 cpus=0，Csum=3；下一秒不懲罰。
第九秒 cpus=3，Csum=3；下一秒不懲罰。
3、基于實(shí)時(shí)懲罰機(jī)制實(shí)現(xiàn)DLA Presto的算力隔離的實(shí)現(xiàn)原理
鑒于DLA的Presto已經(jīng)實(shí)現(xiàn)了Coordinator的高可用，一個(gè)集群中包含至少兩個(gè)Coordinator，因此ResourceManager模塊首先需要實(shí)時(shí)收集所有Coordinator上所有Group的資源消耗信息，并在ResourceManager中匯總，然后計(jì)算并判斷每個(gè)Group是否需要被懲罰，最終把每個(gè)Group是否需要被懲罰的信息同步給所有Worker。如下圖所示：
與社區(qū)Presto的Worker把所有Split放到一個(gè)waitingSplit隊(duì)列不同，DLA Presto首先在Worker上引入Group概念，每個(gè)Group都會(huì)維護(hù)一個(gè)自己的隊(duì)列。Worker在調(diào)度選擇Split時(shí)，首先會(huì)考慮Group是否被懲罰，如果被懲罰，則不會(huì)調(diào)度該Group的Split；只有未被懲罰的Group的Split會(huì)被選中執(zhí)行。之后Worker會(huì)統(tǒng)計(jì)所有查詢的資源消耗并匯總到Coordinator，并進(jìn)入到下一個(gè)判斷周期。最終達(dá)到控制Group算力的能力。
四、DLA Presto算力隔離上線效果
接下來(lái)以TPCH做測(cè)試，驗(yàn)證租戶算力隔離效果。測(cè)試場(chǎng)景：
四臺(tái)Worker，每臺(tái)配置是4C8G；
選用TPCH第20條SQL進(jìn)行實(shí)驗(yàn)，因?yàn)樗?個(gè)JOIN個(gè)，需要使用大量CPU；
實(shí)驗(yàn)場(chǎng)景：四個(gè)租戶資源上限相同都為8，其中A、B、C各提交一條SQL，D同時(shí)提交5條SQL。
可以看到社區(qū)Presto版本由于租戶D提交查詢多，相應(yīng)的Split會(huì)更多，因此他能分配更多的資源，這對(duì)其他用戶是不公平的。而在DLA版本中，由于預(yù)先為租戶D和其他用戶配置了相同的資源上限，因此租戶D使用的資源和其他用戶也是差不多的。
下圖是8條查詢的耗時(shí)對(duì)比：
可以看到在開(kāi)源Presto版本里面，所有8條查詢耗時(shí)幾乎一樣；而在DLA的版本里面租戶A、B、C的查詢耗時(shí)較短，而租戶D由于使用過(guò)多資源被懲罰，因此它的5條查詢耗時(shí)較長(zhǎng)。
在DLA的實(shí)際生產(chǎn)過(guò)程中，為每個(gè)用戶設(shè)置指定的資源上限，并進(jìn)行比較精準(zhǔn)的控制，杜絕了一條或多條查詢占用大量的資源，影響其他用戶的查詢。也不再出現(xiàn)少量查詢就把Presto集群搞垮的情況。保證了用戶查詢時(shí)間的穩(wěn)定性。另一方面，對(duì)于那些查詢量很大的用戶，DLA還提供了獨(dú)享集群模式，能讓查詢以更優(yōu)的性能完成。
五、總結(jié)
隨著越來(lái)越多的企業(yè)開(kāi)始做數(shù)據(jù)湖分析，數(shù)據(jù)量的持續(xù)增加，數(shù)據(jù)分析需求也會(huì)越來(lái)越多，在一個(gè)共享的數(shù)據(jù)湖分析引擎，如何防止多租戶之間的查詢相互影響是一個(gè)很通用的問(wèn)題，本文以阿里云DLA Presto為例，介紹了一種基于實(shí)時(shí)懲罰機(jī)制實(shí)現(xiàn)算力隔離的原理，能有效使共享Presto集群解決多租戶之間查詢相互影響的問(wèn)題。
關(guān)于我們
DLA致力于幫助客戶構(gòu)建低成本、簡(jiǎn)單易用、彈性的數(shù)據(jù)平臺(tái)，比傳統(tǒng)Hadoop至少節(jié)約50%的成本。其中DLA Meta支持云上15+種數(shù)據(jù)數(shù)據(jù)源（OSS、HDFS、DB、DW）的統(tǒng)一視圖，引入多租戶、元數(shù)據(jù)發(fā)現(xiàn)，追求邊際成本為0，免費(fèi)提供使用。DLA Lakehouse基于Apache Hudi實(shí)現(xiàn)，主要目標(biāo)是提供高效的湖倉(cāng)，支持CDC及消息的增量寫入，目前這塊在加緊產(chǎn)品化中。DLA Serverless Presto是基于Apache PrestoDB研發(fā)的，主要是做聯(lián)邦交互式查詢與輕量級(jí)ETL。DLA支持Spark主要是為在湖上做大規(guī)模的ETL，并支持流計(jì)算、機(jī)器學(xué)習(xí)；比傳統(tǒng)自建Spark有著300%的性價(jià)比提升，從ECS自建Spark或者Hive批處理遷移到DLA Spark可以節(jié)約50%的成本?；贒LA的一體化數(shù)據(jù)處理方案，可以支持BI報(bào)表、數(shù)據(jù)大屏、數(shù)據(jù)挖掘、機(jī)器學(xué)習(xí)、IOT分析、數(shù)據(jù)科學(xué)等多種業(yè)務(wù)場(chǎng)景。
歡迎加入數(shù)據(jù)湖分析DLA技術(shù)交流釘釘群進(jìn)行交流~
點(diǎn)擊“閱讀原文”了解關(guān)于DLA的更多信息