一、背景介紹
1.1 什麼樣的客戶需要數據湖
在數據處理領域，數據湖相對來說是一個比較新的概念，它的提出可以很好地幫助企業應對當前數據場景越來越多、數據結構越來越複雜、數據處理的需求越來越多樣化的問題。傳統的單機數據庫技術傾向於大一統，一個數據庫可以解決數據存儲、在線交易、在線分析、離線報表等功能，好處是簡單，數據只有一份，缺點是各個功能都做了取捨，很難解決規模的問題。爲了突破數據規模的瓶頸，大數據技術更傾向於針對單獨領域做深度定製，比如海量文件存儲使用HDFS、海量對象存儲使用OSS/S3、寬表存儲使用BigTable/HBase、嵌套數據使用MongoDB、大規模TP數據使用PolarDB、大規模AP數據使用ADB/Clickhouse、日誌數據使用LogService等等。
在很多企業裏面，不同的部門業務不同，採用的數據方案也不同。在企業發展的前期，更多是靠業務模式驅動、流量驅動，數據複雜度的問題還不明顯，後期則需要精細化運營、向數據要紅利，數據管理的難度就成爲企業的痛點。數據湖的出現可以很好地解決這個痛點，這也是爲什麼各個雲廠商都推出了數據湖產品，數據湖產品和解決方案越來越得到客戶的認可。Gartner 2020年發佈的報告顯示目前已經有39%的用戶在使用數據湖，34%的用戶考慮在1年內使用數據湖。
1.2 阿里雲數據湖分析（DLA）整體方案
阿里雲數據湖分析（DLA）產品提供了數據湖的一站式解決方案。OSS對象存儲採用KV的技術架構，可以實現無限擴展，是公認的數據湖存儲底座。用戶可以通過離線ETL和在線增量ETL將在線數據和實時增量數據，同步到OSS中，然後對數據做深度的計算和分析。用戶也可以直接訪問這些在線庫，做在線的聯邦分析。爲了方便用戶管理數據湖中的數據，我們提供了統一的數據湖管理方案。數據湖管理可以統一存儲數據湖中數據的元信息給計算引擎使用，另外還提供元數據動態爬取功能，可以動態解析OSS數據目錄結構和數據格式，省去了用戶手動創建表和分區的工作。同時，DLA跟DMS和QuickBI進行了深度集成，方便用戶實現更豐富的開發和管理邏輯。
DLA同時提供了SQL和Spark兩個引擎，SQL基於Presto實現，可以實現高效的在線分析，主要面向用戶探索式分析、報表以及輕量ETL的場景；Spark可以實現用戶自定義代碼和複雜計算邏輯以及超大規模ETL的場景。本文主要介紹DLA SQL(兼容Presto)，關於DLA Spark的介紹可以閱讀: 阿里云云原生數據湖分析DLA Serverless Spark重磅發佈，助力企業低成本挖掘OSS數據價值
二、DLA SQL（兼容Presto）架構解析
2.1 Presto簡介
DLA SQL是基於開源的Presto引擎打造的交互式分析引擎，Presto是Facebook開源出來的、初衷就是爲了解決使用Hive來進行在線分析速度太慢的問題，它採用全內存流水線化的執行引擎, 相較於其它引擎會把中間數據落盤的執行方式，Presto在執行速度上有很大的優勢，特別適合用來做在線數據分析。
其次跟很多分析引擎只實現了部分SQL語義不同(比如Clickhouse爲了單表查詢的性能做優化，不支持多表JOIN這種常見的SQL場景)，而Presto則是實現完整的SQL語義，你不用擔心你有什麼SQL語義是Presto不支持的。
再者Presto另一個令人矚目的特性是多數據源聯合查詢，一個公司的數據根據業務的特點可能散落在很多地方比如MySQL, OSS, HDFS, TableStore等等, Presto內置的Connector機制使得我們可以對這些不同數據源的數據關聯查詢，而不用事先把這些數據挪到同一個存儲介質，特別適合數據湖場景這種數據源多種多樣的場景。
最後Presto有一個非常棒的社區，國內外的大公司比如Facebook、Twitter、Amazon Athena、阿里巴巴、京東、頭條等等都在用，你不用擔心用了Presto之後會碰到社區解決不了的問題。
總結來說Presto是一款全內存流水線化執行的、支持通過Connector機制查詢各種異構數據源、完整實現了SQL語義的這麼一款數據分析引擎。因爲它的這些優異的特性國內外的大公司包括我們DLA SQL都採用Presto來進行大數據的分析。
2.2 使用開源Presto自建的挑戰
由於上述Presto各種優異的特點各個公司都紛紛採用Presto來進行在線的數據的分析，但是使用開源Presto自建會缺失一些企業級的特性。
首先是運營維護成本高。開源自建意味着需要手動搭建Presto集羣，對Presto的各項配置參數進行調優，碰到各種性能使用問題需要從頭研究；Presto原生對於庫表列權限的支持很弱，需要配套搭建比如Ranger之類的另外一個系統來進行權限的管理；由於直接支持Presto協議的雲服務不多，周邊的調度、BI等配套軟件都得自建。這樣第一次上手時間很長，從數天到數週不等；另外後續這一整套軟件棧的維護也是成本很高的。
其次是使用門檻比較高。比如如果我們要新添加一個數據源來進行分析，我們必須要修改整個集羣的配置，然後對Presto集羣進行重啓才能生效，這個至少會導致5分鐘左右的不可用，而如果中間有任何配置錯誤，要進行調試時間就更長了；再比如由於Presto不是一個完全自包含的系統，對於權限控制之類的可能要依賴Ranger之類的系統，因此你對Presto使用可能還要跨越到另外一個系統去做一些配置，無法做到一站式；再一個使用門檻高的點在於它的SQL是要求嚴格類型匹配的，比如下面這樣的SQL直接運行在Presto裏面會報錯的：
SELECT *FROM TBLWHERE date_col < '2020-05-30'; -- date_col是date類型的
報錯的原因在於 date_col 的類型是date, 而 '2020-05-30' 的類型是string，類型不匹配，無法進行查詢，這會使得習慣於使用MySQL等數據庫的分析師非常不適應。
缺乏對雲上數據源的原生支持。我們越來越多的業務會基於雲上服務來搭建，會使用很多雲上的數據源比如阿里雲的AnalyticDB, TableStore等等，要分析這些數據源，Presto是沒有自帶Connector的，當然用戶可以自己基於Connector機制來實現，但是要實現一個穩定高效的Connector也是很有挑戰的一件事情，不是每個公司都願意投資人力資源來做。
最後Presto的Coordinator在架構上是個單點。當集羣運行的SQL很多，或者整個集羣很大，Coordinator解析調度查詢的壓力、Coordinator與Worke之間同步任務信息的壓力會很大，Coordinator會有宕機的風險，一旦宕機整個集羣會不可用，這對於一個要在生產環境使用的服務來說是不可接受的。
2.3 DLA SQL（兼容Presto）的架構
DLA SQL(兼容Presto)的目標是提供比開源自建更高的性價比、開箱即用的體驗、方便的數據攝入、MySQL生態的簡單易用、內置各種優化的Presto分析計算服務。下面我們來介紹一下爲了達到這個目標我們採用的架構。
我們整個架構的核心是中間的Presto集羣，跟開源的Presto不同的是，我們做了大量的優化，首先我們內置了多Coordinator的方案，去除了這個架構上的單點，並且這個多Coordinator的方案可以橫向擴展，以應對負載的上升。
其次我們對整個集羣元數據這塊進行了抽象整理，跟開源版本依賴各個Connector提供元數據信息不同的是，DLA SQL有統一的元數據中心。這使得我們對新的數據源的支持從部署期(依賴類似mysql.properties)移到了運行期, 使得我們可以動態增添各種數據源。統一的元數據也使得我們可以方便地內置支持庫表列方面的權限授權體系，幫助企業守好數據權限這一關。
在整個Presto集羣的最前面是我們的FrontNode節點，這個節點的作用是向用戶提供MySQL協議的接口，用戶通過MySQL協議提交查詢到FrontNode, FrontNode把查詢轉換成Presto風格的SQL提交給後端的Presto集羣，然後監控Presto集羣上任務的狀態並且把最終的結果返回給用戶；FrontNode的另外一個職責是對請求進行分發，因爲我們同時支持Serverless和CU版本，FrontNode會根據用戶購買的服務形態對用戶的請求進行分發，分發對對應的Presto集羣。
DLA SQL目前支持兩種售賣形態Serverless和獨享版，Serverless的版本針對小客戶、對資源隔離要求不是那麼高的用戶、低頻偶發查詢類的用戶；獨享版針對對於資源隔離要求比較高、或者是查詢非常高頻的場景。
三、DLA SQL（兼容Presto）VS開源自建Presto
基於上述DLA SQL的架構我們來對比一下DLA SQL相比開源自建Presto的優勢：
超高性價比：相比用戶自建Presto提高2到10倍
開箱即用
方便上手的SQL體驗
方便的數據攝入
高可用: 內置Coordinator HA
連接器的優化
MySQL生態支持
內置完善的權限控制體系
3.1 超高性價比：相比用戶自建Presto提高1到72倍
用戶自建Presto集羣一般會有兩種使用模式，一種是偶爾查查問題的時候才用，這種使用頻率很低，一天可能都查不了幾十條SQL，但是還是要維護一個集羣，非常不划算；另外一種是高頻使用場景，白天上班時間段全負載使用、晚上下班之後集羣還是空閒下來，從整體成本來看仍然不是最優的。
爲此DLA提供了兩種計費模式，一種是按照掃描量計費，執行一條SQL收一條SQL的錢，適用於低頻使用場景；另外一種是按照CU(Compute Unit)計費，適用於高頻使用場景。
我們做了一個實驗，以用戶自建兩臺4C16G機器組成的一個小集羣爲例，當用戶是低頻訪問的時候採用DLA的掃描量版本，DLA的性價比是用戶自建的72倍；當用戶是高頻訪問的時候採用DLA的CU版本 + 彈性，性價比仍然要高於用戶自建。整體來看DLA的性價比能夠做到用戶自建的1到72倍。
總之不管你什麼使用場景，什麼使用頻率，我們總有一個計費模式適合你。
3.2 開箱即用
對於用戶自建Presto，從搭建集羣開始，到最終完成一個最簡單的報表大概的步驟如下：
取決於你搭建Presto集羣的方式，是完全手動搭建，還是基於Docker之類的服務，整個過程可能在30分鐘到5小時之間；搭建完成之後爲了運行一條Presto SQL，你需要通過命令行登陸到你的ECS服務器上去，然後利用Presto提供的命令行工具來進行數據的查詢；或者再搭建一個hue之類的系統，並且做好對接，也可以進行數據的查詢；然後由於Presto對於BI報表的兼容性不是那麼的廣泛，你需要去下載/搭建自己的BI報表系統、任務定時調度系統，這個時間在幾個小時左右；因此爲了通過自建的Presto來完成一個最簡單的BI報表您需要的時間在幾小時到幾天之間。
而如果使用DLA SQL，整個過程是這樣的：
首先在“搭建Presto”的環節與自建不同，用戶只需要在DLA頁面點擊開通即可；然後進行數據查詢，直接在DLA控制檯就可以查詢，或者任何支持MySQL協議的客戶端都可以查詢；最後因爲DLA SQL支持了MySQL協議，雲上有現成的BI服務：QuickBI，有現成的調度服務阿里雲DMS, 阿里雲DataWorks等等，因此BI報表展示以及任務的定時調度均可以在5分鐘內完成；整個過程可以在30分鐘內完成，真正做到開箱即用，而且這種方便、省時間不只是節省你第一次搭建集羣時候的時間，因爲所有的相關配套都有現成服務提供，你不需要維護任何東西，在整個大數據分析的生命週期內都會節省時間，真正做到開箱即用、全託管。
3.3 方便上手的SQL體驗
相比開源自建Presto，DLA SQL在SQL體驗方面做了很多優化，方便數據分析師們使用。首先我們內置了類型的隱式轉換，比如分析師可以直接把一個date類型與一個string類型進行比較，忽略了這些類型轉換的細節，節省下來的時候可以專注於做更重要的數據探查。
其次我們所有的元數據是由我們統一元數據服務來管理，而不像開源Presto是由各個Connector單獨提供，這樣用戶要新添加一個數據源只要使用我們的 CREATE SCHEMA 語句來對元數據進行操作就好了，不涉及任何集羣的運維操作。比如要添加一個mysql數據源，我們執行如下的命令即可：
CREATE SCHEMA db001 WITH DBPROPERTIES (
CATALOG = 'mysql',
LOCATION = 'jdbc:mysql://xxx.rds.aliyuncs.com:3306/db',
USER = 'user',
PASSWORD = 'pass',
INSTANCE_ID = 'inst001',
VPC_ID = 'vpc001'
);
更少的運維操作意味着整個服務更高的可用性，更平滑的使用體驗。
3.4 方便的數據攝入
一個引擎要能分析數據，你首先得知道數據在哪裏，在雲上目前很大一部分數據是保存在對象存儲比如阿里雲OSS裏面的，OSS的特點是便宜，可以以比較低的成本存儲海量的數據。而OSS上數據的上傳與後續的分析往往的脫節的，通常不是同一個人完成，對於分析的人來說OSS上到底有哪些數據，它們的結構是怎麼樣的是個難題，DLA SQL在這一塊提供了兩個配套的服務: OSS元數據發現和一鍵建湖。
OSS元數據發現
OSS元數據發現的作用是自動掃描你OSS上的所有的數據文件，建立相應的庫、表結構，這樣在你需要分析的時候，所有的元數據都已經自動建立好了，省去你找數據、建庫建表的繁瑣。
一鍵建湖
一鍵建湖針對的場景是用戶的數據在RDS裏面的場景，它自動幫助你把RDS裏面的數據同步到OSS上，每天在你設置的時間點自動同步一次，保持數據最新。並且自動建立好相應的庫表結構，這樣在你需要對數據進行分析的時候，你直接分析就好了，而且分析的數據是OSS上的，對您RDS不會有任何壓力負載，做到真正的“敢分析”。關於數據攝入的詳細介紹可以閱讀: 阿里云云原生數據湖分析DLA重磅發佈-數據湖管理，助力企業一站式管理OSS數據湖存儲數據
3.5 高可用：內置Coordinator HA
在開源的Presto架構中Presto Coordinator是個單點，如果因爲CPU/內存或者底層物理機的原因導致Coordinator不可用，會導致整個集羣不可用，從而影響用戶的使用，DLA SQL內置了多Coordinator HA，當一個Coordinator宕機，另外一個Coordinator會自動接管，保證整個集羣的可用性：
3.6 連接器的優化
Presto本身支持了大量的Connector來連接各種數據源，但是雲上的有些數據源還是沒有覆蓋到的，比如阿里雲這邊自研的MaxCompute和Tablestore服務，在用戶中使用是很廣泛的，DLA SQL對他們也進行了支持。
DLA SQL也針對一些數據源進行了性能和成本方面的優化，比如針對阿里雲OSS進行數據分析的話會產生大量的OSS的調用，調用量也是有一些調用費用的，DLA SQL對這方面進行了優化，大幅降低了OSS的調用次數，降低用戶在OSS上的調用成本，如下圖：
再比如針對RDS類的數據源(MySQL/SQLServer/PostgreSQL/Oracle)，DLA SQL會自動探測底層的索引情況，然後選擇合適的字段對TableScan的Split進行拆分，從而加大併發度。這個特性對於RDS數據量很大的時候非常有用。
3.7 MySQL生態的支持
Presto本身實現了自己的client-server端的交互協議，但是由於大量的外圍客戶端軟件/BI軟件/調度軟件並不支持Presto的這種協議，使得用戶在使用上可選擇的軟件比較受限，很多時候還需要用戶自建一些服務。DLA SQL通過在Presto集羣前端部署一個SQL接入層節點，並且在SQL接入層中實現了MySQL協議，把用戶的MySQL協議過來的請求轉給Presto集羣，再把Presto集羣返回來的數據返回給客戶端，使得DLA SQL兼容了MySQL協議，可以使用MySQL生態龐大的周邊軟件設施，方便了用戶，降低用戶在這些周邊軟件上的投入。
3.8 內置完善的權限控制體系
開源Presto在權限控制方面支持的比較簡單的(SystemAccessControl)，用戶如果要實現完善的權限控制需要去配合另外的組件比如Ranger才能達到權限控制的目的，導致操作複雜無法做到一站式，很多企業因爲這種複雜性就直接放棄了權限相關的控制，機密數據有暴露的風險。DLA SQL內置了用戶熟悉了MySQL風格的權限控制機制, 你可以使用你熟悉的權限控制語句對權限進行控制，在DLA SQL內部一站式進行數據查詢、權限管控的工作：
GRANT SELECT on db001.tbl001 to 'user001';
REVOKE SELECT on db001.tbl001 to 'user001';