背景
Presto作為OLAP界領先的分析引擎在國內外有著廣泛的應用，各個公司要麼在自己的機房自建Presto，要麼在雲上使用ECS自建Presto來使用，但是開源的Presto在用戶學習成本、數據攝入、生態兼容性、高可用、對雲上數據的支持度方面還是有一些薄弱。因此阿里雲數據湖分析團隊打造了一個DLA SQL(兼容Presto)獨享版本，今天給大家介紹一下它的一些特性。
開箱即用
對於用戶自建Presto，從搭建集群開始，到最終完成一個最簡單的報表大概的步驟如下:
取決於你搭建Presto集群的方式，是完全手動搭建，還是基於Docker之類的服務，整個過程可能在30分鐘到5小時之間；搭建完成之後為了運行一條Presto SQL，你需要通過命令行登陸到你的ECS服務器上去，然後利用Presto提供的命令行工具來進行數據的查詢；然後由於Presto對於BI報表的兼容性不是那麼的廣泛，你需要去下載/搭建自己的BI報表系統、任務定時調度系統，這個時間在幾個小時左右；因此為了完成一個最簡單的BI報表您需要的時間在幾小時到幾天之間。
而如果使用DLA SQL，整個過程是這樣的:
首先在“搭建Presto”的環節與自建不同，用戶只需要在DLA頁面點擊開通即可，用時5分鐘；然後進行數據查詢，直接在DLA控制檯就可以查詢，或者任何支持MySQL協議的客戶端都可以查詢，用時1分鐘；最後由於DLA Presto支持的MySQL協議，雲上有現成的BI服務: QuickBI，有現成的調度服務Aliyun DMS, Aliyun DataWorks等等，因此BI報表展示以及任務的定時調度均可以在5分鐘內完成；整個過程可以在30分鐘內完成，真正做到開箱即用，而且這種方便、省時間不只是節省你第一次搭建集群時候的實踐，因為所有的相關配套都有現成服務提供，你不需要維護任何東西，在整個大數據分析的生命週期內都會節省時間，真正做到開箱即用、全託管。
方便的數據攝入
一個引擎要能分析數據，你首先得知道數據在哪裡，在雲上目前很大一部分數據是保存在對象存儲比如阿里雲OSS裡面的，OSS的特點是便宜，可以以比較低的成本存儲海量的數據。而OSS上數據的上傳與後續的分析往往的脫節的，可能都不是同一個人完成，對於分析的人來說OSS上到底有哪些數據，它們的結構是怎麼樣的是個難題，DLA Presto在這一塊提供了兩個配套的服務: OSS元數據發現和一鍵建湖。
OSS元數據發現
OSS元數據發現的作用是自動掃描你OSS上的所有的數據文件，建立相應的庫、表結構，這樣在你需要分析的時候，所有的元數據都已經自動建立好了，省去你建庫建表的繁瑣。
一鍵建湖
一鍵建湖針對的場景是用戶的數據在RDS裡面的場景，他自動幫助你把RDS裡面的數據同步到OSS上，每天在你設置的時間點自動同步一次，保持數據最新。並且自動建立好相應的庫表結構，這樣在你需要對數據進行分析的時候，你直接分析就好了，而且分析的數據是OSS上的，對您RDS不會有任何壓力負載，做到真正的“敢分析”。
高可用 - 內置Coordinator HA
在開源的Presto架構中Presto Coordinator是個單點，如果因為CPU/內存或者底層物理機的原因導致Coordinator不可用，會導致整個集群不可用，從而影響用戶的使用，DLA Presto內置了多Coordinator HA，當一個Coordinator宕機，另外一個Coordinator會自動接管，保證整個集群的可用性:
更多的連接器、更多的優化
Presto本身支持了大量的Connector來連接各種數據源，但是雲上的有些數據源還是沒有覆蓋到的，比如阿里雲這邊自研的MaxCompute和Tablestore服務，在用戶中使用是很廣泛的，DLA SQL對他們也進行了支持。
DLA Presto也針對一些數據源進行了性能和成本方面的優化，比如針對阿里雲OSS進行數據分析的話會產生大量的OSS的調用，調用量也是有一些調用費用的，DLA SQL對這方面進行了優化，大幅降低了OSS的調用次數，降低用戶在OSS上的調用成本，如下圖:
再比如針對RDS類的數據源(MySQL/SQLServer/PostgreSQL/Oracle)，DLA Presto會自動探測底層的索引情況，然後選擇合適的字段對TableScan的Split進行拆分，從而加大併發度。這個特性對於RDS數據量很大的時候非常有用。
MySQL生態支持
Presto本身實現了自己的client-server端的交互協議，但是由於大量的外圍客戶端軟件/BI軟件/調度軟件並不支持Presto的這種協議，使得用戶在使用上可選擇的軟件比較受限，很多時候還需要用戶自建一些服務。DLA Presto通過在Presto集群前端部署一個FrontNode節點，並且在FrontNode中實現了MySQL協議，把用戶的MySQL協議過來的請求轉給Presto集群，再把Presto集群返回來的數據返回給客戶端，使得DLA Presto兼容了MySQL協議，可以使用MySQL生態龐大的周邊軟件設施，方便了用戶，降低用戶在這些周邊軟件上的投入。
性價比
除了上述特性DLA Presto在性能、價格方面對開源Presto也有著明顯的優勢，下面是DLA Presto與開源Presto在TPCH 10x上的一個性能對比:
機器規格: 2臺Worker 4C16G
數據源: 阿里雲OSS
測試數據: TPCH, scale factor: 10X, 數據格式Parquet
幾乎所有的查詢的時間DLA Presto都要比開源Presto要短。這是性能，在價格方面首先針對OSS調用次數我們做了大幅優化，平均來看可以幫助用戶節省OSS調用費用 60% - 90%(https://yq.aliyun.com/articles/760352)。
內置完善權限控制體系
我們知道開源Presto在權限控制方面支持的比較簡單的(SystemAccessControl)，用戶如果要實現完善的權限控制需要去配合另外的組件比如Ranger才能達到權限控制的目的。DLA Presto內置了用戶熟悉了MySQL風格的權限控制機制, 你可以使用你熟悉的權限控制語句對權限進行控制:
GRANT SELECT on db001.tbl001 to 'user001';
REVOKE SELECT on db001.tbl001 to 'user001';其它正在建設中的特性
除了上面目前我們已經提供的特性，我們還有很多正在研發中很快發佈的特性這裡也給大家預告一下:
彈性擴縮容
在用戶自建的Presto集群中，集群的規模往往的固定的，但是查詢的負載在一天中是有波峰波谷的, 比如下午6點之後分析師們都下班了，負載會大幅下降:
如果始終保有相同的資源，無法做到資源的最大利用率，浪費機器資源。DLA Presto將會提供兩種方式的彈性擴縮容:
- 基於時間段的擴縮容: 高峰時間段多配置機器，空閒時間短自動縮減機器數。
- 基於負載的擴縮容: 自動監控集群的負載情況，如果負載低於某個閾值一段實踐，自動觸發縮容，如果負載高於某個閾值，自動觸發擴容。
而且我們會保證擴縮容的過程中不影響用戶正在查詢的SQL，對用戶毫無影響。
內置最佳實踐
即使我們擁有再好的引擎，如果我們不遵守一些大數據分析的最佳實踐，寫出一些低效的SQL也只能獲得很差的性能，甚至影響整個集群的性能。對於有經驗的用戶可能沒有問題，但是我們很難阻止數據分析新手寫出低效的SQL。針對這個問題DLA Presto支持"放心模式", 內置了一些最佳實踐, 比如:
- 查詢分區表的時候不帶分區條件直接報錯
- 兩個表JOIN不指定JOIN條件直接報錯
- 等等
這些最佳實踐用戶都可以配置是否開啟，開啟之後就可以幫助用戶自動攔截低效SQL。
文件緩存
如果你的數據是保存在對象存儲比如阿里雲OSS上，由於數據在遠端，頻繁的讀取對於性能是有一定損耗的，我們正在內置的一個功能是文件緩存機制，根據用戶的配置，我們自動緩存相應的文件塊，如果有重複率比較大的查詢，比如一群用戶查看同一個報表，那麼緩存的命中率會很大，可以大幅提高請求的響應速度。
總結
總結來說我們想把DLA Presto打造成一個比用戶自建有著更高的性價比、一樣的算力、開箱即用的體驗、配套方便的數據攝入服務、MySQL生態帶來的簡單易用、內置各種優化的Presto分析服務。現在這款服務正式對外售賣，歡迎加下面的釘釘群諮詢瞭解:
