在剛剛閉幕的PrestoCon 2020上，阿里雲的雲原生數據湖分析(DLA)作爲Linux Foundation的一員在大會上了分享了DLA在提供託管Presto服務過程中碰到的一些挑戰以及我們的解法，這裏跟大家分享探討一下。
01 Why Presto
首先給大家介紹一下爲什麼我們會選擇Presto作爲我們數據湖分析的引擎。
首先Presto採用的是全內存計算模型，性能非常好，特別適合進行adhoc查詢、數據探索、BI報表、輕量ETL等等各種業務場景；其次不像其它一些引擎只支持部分SQL語義，Presto支持完整的SQL語義，你不用擔心有什麼需求是Presto表達不出來的；再者Presto有個很方便的插件機制，你可以在不改動內核的情況下添加自己的插件，這樣理論上你可以用Presto去連接任何數據源，滿足你的各種業務場景；最後Presto有個非常棒的社區，現在Presto已經歸屬到Linux Foundation下面，Alibaba也是這個基金會的成員之一，國際國內大公司比如Facebook，Twitter，Amazon Athena，阿里巴巴，京東，頭條等等都在使用Presto進行大數據的分析。基於上述優勢，阿里雲數據湖分析採用了Presto作爲底層的分析引擎。
02 DLA SQL（兼容Presto）的技術架構
DLA SQL的技術架構分三塊：FrontNode，Presto Clusters以及Unified Meta Service。
FrontNode是整個架構的接入層，它實現了MySQL協議，這樣用戶可以用任何兼容MySQL協議的客戶端/BI工具/調度工具連接上來繼續數據分析、報表製作。FrontNode會把用戶提交的MySQL風格的SQL轉換成Presto風格的SQL，並且發送給底層正確的Presto集羣。
FrontNode之下，是我們的Presto集羣，在每個Region，我們會有兩類集羣，一個是掃描量集羣，對用戶收費是按照用戶SQL實際從底層數據源掃描的數據量進行收費的，這個集羣是公用的，用戶之間會通過我們的多租戶隔離技術進行元數據和算力的隔離，關於隔離技術的細節後文會詳細介紹。另外一類集羣是CU集羣，CU集羣是根據指定的CPU Core的個數單獨拉起的集羣，它適合於使用頻繁的客戶，因爲它不是按照掃描量計費，而是按照CPU Core個數計費的。這兩種集羣的收費差異可以看下圖：
在整個架構的左邊是我們的統一元數據中心，這個模塊是DLA跟社區差異很大的一個地方，在社區的實現裏面，所有的Connector連接底層實際的數據源去獲取元數據，當用戶需要添加新的數據源的時候需要添加新的Catalog文件，並且重啓集羣才能實現，通過把元數據收到統一服務裏面，用戶添加新的數據源對於DLA來說只是一個DDL操作，不需要重啓集羣，並且由於元數據統一在一個地方，使得我們可以很方便地實現權限管控，我們提供了MySQL風格的GRANT/REVOKE機制，這是開源Presto所沒有的便利。
03 託管Presto雲服務的三大挑戰
託管Presto作爲一個雲服務有很多挑戰，今天我們主要介紹以下三個：
· Coordinator單點問題
· 計算資源的多租戶隔離
· Connector優化
Coordinator單點問題
Coordinator單點會有很多問題，一旦Coordinator掛掉整個集羣就會不可用很長時間，要等待Coordinator重啓，並且註冊所有的Worker，這個時間在幾分鐘級別；另外如果只有一個Coordinator，我們是沒有辦法做無縫升級的，這些對於一個企業級服務都是不可接受的。我們採用如下架構解決了這個問題：
我們引入了Zookeeper在多個Coordinator之間選主，其中一個Coordinator會變成Leader，其它則是Follower。Leader Coordinator跟社區的Coordinator職責類似，它負責啓動DiscoveryService，負責一些全局信息的收集以及決策工作，同時也會之下分配給它的Query。Follower則比較簡單了，只負責執行分配給它的Query。
如果使用開源的Presto的話，有多個Coordinator之後會產生一個問題：用戶應該連接哪個Coordinator呢？在DLA的架構裏面這不是一個問題，因爲DLA的用戶不會直接連到Coordinator，只會連接FrontNode，FrontNode負責查詢的分發，因此用戶完全不感知我們有幾個Coordinator。
實現了多個Coordinator之後，要實現無縫升級就比較簡單了，如果大家有興趣我們後續文章可以專門介紹一下。
計算資源的多租戶隔離
Presto原生設計是在一個公司內部使用的，對於計算資源多租戶隔離考慮的不多，雖然有Resource Group的機制來限定一個Group的計算資源和內存，但是Group對於計算資源的使用是可以超過指定的上限的，Presto做的“限制”是如果有新的查詢，那麼新的查詢不會被調度，但是老的查詢還是會繼續佔用大量資源，這樣就會影響一個集羣上的其它租戶的使用。
DLA對計算資源隔離這塊進行了優化，把多租戶的概念引入了進去：
首先與社區Presto所有Split在一個全局隊列不同，在DLA的版本里面，每個租戶有自己的隊列，這樣做到第一層的隔離。然後我們在全局引入了一個Resource Manager的角色，它會從所有的Coordinator聚合所有租戶對於資源的使用情況，然後根據我們設定的閾值去計算每個租戶在下個調度週期是否應該被懲罰，然後把這個懲罰信息發送給所有的Worker。在Worker上，任務調度器在進行實際調度一個租戶的Split之前，會先檢查這個租戶是否被懲罰了，如果被懲罰了，那麼它的所有的Split都不會被調度，這樣就把計算資源保留給其它的租戶使用。
我們用下面的測試配置進行了測試：
1. 4臺Worker，每臺配置是4C8G；使用TPCH20G的數據；選用第TPCH第20條SQL進行實驗，因爲它JOIN了好幾個表，需要使用大量CPU。
2. 實驗場景：4個租戶，A、B、C各提交一條SQL，D提交5條SQL。
測試效果如下：
可以看到在社區版本里面，租戶D因爲提交了更多了SQL，所以它有更多的Split在運行，擠壓了其它租戶；在DLA版本里面，所有租戶運行中的Split個數是差不多的。
下面看看8條查詢的運行耗時：
可以看到在開源版本里面，所有8條查詢耗時幾乎一樣；而在DLA的版本里面租戶A、B、C的查詢耗時較短，因爲租戶D使用過多資源被懲罰了，所以它的5條查詢耗時較長。
連接器優化
OSS是阿里雲上的對象存儲服務，DLA採用OSS作爲數據湖的存儲層。我們支持對OSS數據進行INSERT INTO/OVERWRITE以及查詢，同時我們對OSS的請求進行了優化，可以把對於OSS API的調用次數降低到開源版本的1/10到1/3。
TableStore是阿里雲上廣泛使用的KV存儲服務，在DLA的幫助下讓用戶可以使用SQL語句來分析KV存儲中的數據，而且如果用戶有建立索引的話，DLA會自動採用合適的索引以達到更好的性能。
AnalyticDB是阿里雲提供的雲原生數據倉庫服務，DLA支持用戶讀寫AnalyticDB的數據，可以幫助用戶在把數據灌入AnalyticDB之前做一些預先清洗的工作。
對於MaxCompute我們支持讀寫，並且支持讀取MaxCompute的OSS外表的數據。
此外我們支持開源Presto支持的所有的Connector，同時我們也做了一些的優化，比如對於JDBC類數據源，我們支持自動探測底層表結構，然後根據索引列進行Split切分，這樣可以提高JDBC類數據源的查詢效率。