一、背景介紹

根據(jù)MarketsandMarkets市場調(diào)研顯示，預(yù)計(jì)數(shù)據(jù)湖市場規(guī)模在2024年將從2019年的79億美金增長到201億美金。隨著數(shù)據(jù)湖的規(guī)模增長，基于交互式查詢引擎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ù)場景。下圖以阿里云數(shù)據(jù)湖分析（簡稱DLA）的Presto架構(gòu)為例說明。

FrontNode：整個(gè)架構(gòu)的接入層FrontNode，它通過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在多租戶隔離場景考慮的比較少，主要通過ResourceGroup機(jī)制限制每個(gè)資源組的資源（包括CPU和內(nèi)存）上限，它最大的問題是只能限制新的查詢，即一個(gè)Group的資源用超后，其新提交的查詢會(huì)被排隊(duì)，直到其使用的資源降到上限之下；對(duì)于正在執(zhí)行的查詢?nèi)绻^資源組的資源上限，ResourceGroup不會(huì)做限制。因此在一個(gè)共享的Presto集群中，一個(gè)大查詢還是可以把整個(gè)集群的資源消耗完，從而影響其他用戶的查詢。在DLA實(shí)際生產(chǎn)過程中，上千用戶共享的集群，此問題尤為突出。

與Spark、Hive等其他查詢引擎可以簡單設(shè)置執(zhí)行資源并發(fā)限制資源不同，Presto首先需要預(yù)先啟動(dòng)所有Stage，并且所有查詢?cè)赪orker執(zhí)行時(shí)共享線程和內(nèi)存，因此無法通過簡單地設(shè)置執(zhí)行的并發(fā)控制其資源的使用。

業(yè)界采用比較多的解決方案是：基于Presto On Yarn實(shí)現(xiàn)資源隔離。為每個(gè)資源組啟動(dòng)一個(gè)獨(dú)立的Presto On Yarn集群，并通過Yarn的資源管理機(jī)制實(shí)現(xiàn)Presto集群之間的隔離。其優(yōu)點(diǎn)是資源隔離比較好；但需要預(yù)先為每個(gè)租戶啟動(dòng)一個(gè)專屬的集群，即使沒有查詢?cè)趫?zhí)行也需要維護(hù)該集群，在數(shù)據(jù)湖分析Serverless服務(wù)場景，租戶較多，且他們的查詢很多都是間歇性的，其資源消耗也不穩(wěn)定，無法預(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)槔喴榻B社區(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í)間超過其配置的資源上限，則開始懲罰該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為例舉例說明：

第一秒 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算力隔離上線效果

接下來以TPCH做測試，驗(yàn)證租戶算力隔離效果。測試場景：

四臺(tái)Worker，每臺(tái)配置是4C8G；選用TPCH第20條SQL進(jìn)行實(shí)驗(yàn)，因?yàn)樗?個(gè)JOIN個(gè)，需要使用大量CPU；實(shí)驗(yàn)場景：四個(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ì)比：

可以看到在開源Presto版本里面，所有8條查詢耗時(shí)幾乎一樣；而在DLA的版本里面租戶A、B、C的查詢耗時(shí)較短，而租戶D由于使用過多資源被懲罰，因此它的5條查詢耗時(shí)較長。

在DLA的實(shí)際生產(chǎn)過程中，為每個(gè)用戶設(shè)置指定的資源上限，并進(jìn)行比較精準(zhǔn)的控制，杜絕了一條或多條查詢占用大量的資源，影響其他用戶的查詢。也不再出現(xiàn)少量查詢就把Presto集群搞垮的情況。保證了用戶查詢時(shí)間的穩(wěn)定性。另一方面，對(duì)于那些查詢量很大的用戶，DLA還提供了獨(dú)享集群模式，能讓查詢以更優(yōu)的性能完成。

五、總結(jié)

隨著越來越多的企業(yè)開始做數(shù)據(jù)湖分析，數(shù)據(jù)量的持續(xù)增加，數(shù)據(jù)分析需求也會(huì)越來越多，在一個(gè)共享的數(shù)據(jù)湖分析引擎，如何防止多租戶之間的查詢相互影響是一個(gè)很通用的問題，本文以阿里云DLA Presto為例，介紹了一種基于實(shí)時(shí)懲罰機(jī)制實(shí)現(xiàn)算力隔離的原理，能有效使共享Presto集群解決多租戶之間查詢相互影響的問題。