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