阿里云云原生數據湖分析DLA是阿里雲在數據湖領域推出的拳頭產品，幫忙用戶進行數據湖的構建、對數據湖的進行分析、在統一的元數據基礎之上支持雙引擎: Presto和Spark，一站式滿足用戶各種數據分析的需求。DLA基於雲原生的理念進行構建、用戶不需要感知任何物理機、ECS、手動部署等等，直接使用服務，而且是完全Serverless形態，支持靈活的彈性策略，提供多種計費模型，滿足各種不同場景的用戶使用需求。
在剛剛閉幕的PrestoCon 2020上，阿里雲的雲原生數據湖分析(DLA)作為Linux Foundation的一員在大會上了分享了DLA在提供託管Presto服務過程中碰到的一些挑戰以及我們的解法，這裡跟大家分享探討一下。
Why Presto
首先給大家介紹一下為什麼我們會選擇Presto作為我們數據湖分析的引擎。
首先Presto採用的是全內存計算模型，性能非常的好，特別適合進行adhoc查詢、數據探索、BI報表、輕量ETL等等各種業務場景；其次不像其它一些引擎只支持部分SQL語義，Presto支持完整的SQL語義，你不用擔心有什麼需求是Presto表達不出來的；再者Presto有個很方便的插件機制，你可以在不改動內核的情況下添加自己的插件，這樣理論上你可以用Presto去連接任何數據源，滿足你的各種業務場景；最後Presto有個非常棒的社區，現在Presto已經歸屬到Linux Foundation下面，Alibaba也是這個基金會的成員之一，國際國內大公司比如Facebook，Twitter，Amazon Athena，阿里巴巴，京東，頭條等等都在使用Presto進行大數據的分析。基於上述優勢，阿里雲數據湖分析採用了Presto作為底層的分析引擎。
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個數計費的。這兩種集群的收費差異可以看下圖:
關於這兩種收費模式更詳細的差異對比可以查看我們的文檔: 掃描量版與CU版本的差異
在整個架構的左邊是我們的統一元數據中心，這個模塊是DLA跟社區差異很大的一個地方，在社區的實現裡面，所有的Connector連接底層實際的數據源去獲取元數據，當用戶需要添加新的數據源的時候需要添加新的Catalog文件，並且重啟集群才能實現，通過把元數據收到統一服務裡面，用戶添加新的數據源對於DLA來說只是一個DDL操作，不需要重啟集群，並且由於元數據統一在一個地方，使得我們可以很方便地實現權限管控，我們提供了MySQL風格的GRANT/REVOKE機制，這是開源Presto所沒有的便利。
託管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都不會被調度，這樣就把計算資源保留給其它的租戶使用。
我們用下面的測試配置進行了測試:
- 4臺Worker，每臺配置是4C8G;使用TPCH20G的數據；選用第TPCH第20條SQL進行實驗，因為它JOIN了好幾個表，需要使用大量CPU。
- 實驗場景: 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類數據源的查詢效率。
總結
Presto作為一款優秀的OLAP計算引擎非常適合用來做各種數據分析的工作，不管你是自建的還是採用雲上的服務。阿里雲數據湖分析在開源社區版本之上提供了多種計費模式以及彈性伸縮的能力，從而可以實現比用戶自建更高的性價比；我們支持阿里雲上主流的數據源，並且進行深度優化，讓用戶可以把更多的時間專注下數據分析上；我們提供了更多的穩定性(多Coordinator)與易用性(MySQL協議支持)讓各個不同人群可以輕鬆上手。總之DLA SQL(兼容Presto)的目標是比自建有更高的性價比、按需彈性的算力、開箱即用的體驗、方便的數據攝入、MySQL生態帶來的簡單易用、內置各種優化的Presto分析服務。
為了方便中國的Presto用戶交流，我們創建了專門的釘釘群，歡迎加入溝通:
