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