一、背景介紹
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在執行速度上有很大的優勢，特别适合用來做線上資料分析。
Presto另一個令人矚目的特性多資料源聯合查詢，一個公司的資料根據業務的特點可能散落在很多地方比如MySQL, OSS, HDFS, TableStore等等, Presto内置的Connector機制使得我們可以對這些不同資料源的資料關聯查詢，而不用事先把這些資料挪到同一個存儲媒體，特别适合資料湖場景這種資料源多種多樣的場景。
跟很多分析引擎隻實作了部分SQL語義不同(比如Clickhouse為了單表查詢的性能做優化，不支援多表JOIN這種常見的SQL場景)，而Presto則是實作完整的SQL語義，你不用擔心你有什麼SQL語義是Presto不支援的。
總結來說Presto是一款全記憶體流水線化執行的、支援通過Connector機制查詢各種異構資料源、完整實作了SQL語義的這麼一款資料分析引擎。
2.2 使用開源Presto自建的挑戰
由于上述Presto各種優異的特點各個公司都紛紛采用Presto來進行線上的資料的分析，但是使用開源Presto自建會缺失一些企業級的特性。
首先是營運維護成本高。開源自建意味着需要手動搭建Presto叢集，對Presto的各項配置參數進行調優，碰到各種性能使用問題需要從頭研究；Presto原生對于庫表列權限的支援很弱，需要配套搭建比如Ranger之類的另外一個系統來進行權限的管理；由于直接支援Presto協定的雲服務不多，周邊的排程、BI等配套軟體都得自建。這樣第一次上手時間很長，從數天到數周不等；另外後續這一整套軟體棧的維護也是成本很高的。
其次是使用門檻比較高。比如如果我們要新添加一個資料源來進行分析，我們必須要修改整個叢集的配置，然後對Presto叢集進行重新開機才能生效，這個至少會導緻5分鐘左右的不可用，而如果中間有任何配置錯誤，要進行調試時間就更長了；再比如由于Presto不是一個完全自包含的系統，對于權限控制之類的可能要依賴Ranger之類的系統，是以你對Presto使用可能還要跨越到另外一個系統去做一些配置，無法做到一站式；再一個使用門檻高的點在于它的SQL是要求嚴格類型比對的，比如下面這樣的SQL直接運作在Presto裡面會報錯的:
SELECT *
FROM TBL
WHERE 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提高2到10倍
DLA SQL在性能、價格方面對開源Presto也有着明顯的優勢。首先看性能, 下面是DLA Presto與開源Presto在TPCH 10x上的一個性能對比:
機器規格: 2台Worker 4C16G
機器價格: 528元/月/台
資料源: 阿裡雲OSS
測試資料: TPCH, scale factor: 10X, 資料格式Parquet
可以看出DLA SQL的性能幾乎所有的查詢性能都比開源Presto要好。再來看價格，基于雲服務搭建的大資料的分析平台典型的架構如下:
- 使用OSS來儲存所有的資料 -- OSS價格低，而且可以無限擴充
- 使用ECS來搭建Presto分析OSS上的資料。
那麼這裡的成本分為三塊：
- OSS存儲的成本: 隻跟使用者的資料量有關，跟上層分析引擎沒有關系。
- Presto占用的ECS的成本
- Presto調用OSS讀取資料産生的OSS接口調用費用
Presto占用ECS的成本這一塊，我們以上述2台4C16G來計算，自建Presto一個月的成本在 528 x 2 = 1056元。
如果使用者是比較低頻的使用，推薦使用DLA SQL的Serverless版本。比如每天運作一次TPCH 10X的22條查詢：那麼每個月的費用如下:
- Serverless版本是按照掃描量計費的，每TB28元。
- TPCH 10x Parquet格式22條SQL掃描量大約: 20GB, 每天掃一遍，那麼一個月一共掃描量為: 20G * 30 = 600G。
- 一個月的費用為: 600G * 28 / 2014 = 16元
由此可見在低頻場景下Serverless版本的費用是自建Presto的 1/66。當然使用者使用的頻率不是一個常數，如果使用者是高頻通路，那麼可能使用DLA CU版本對使用者會更劃算，因為CU版本是按照CU數計費，而不是按照掃描量計費的，這樣使用者不管運作多少查詢收費都是一樣的。這種模式跟使用者自建Presto很像，但是我們會支援基于時間段以及叢集的負載進行擴縮容，比如早上9點到晚上18點之間叢集使用滿負載運作，而18點之後分析師下班之後，使用人數下降我們可以自動對叢集進行縮容，是以如果根據時間段來進行擴縮容，DLA SQL CU版本還是會比使用者自建便宜一半左右。下圖是幾種方案的成本分布情況:
按照時間段與負載進行無痛擴縮容的功能我們正在開發中，近期上線。
要實作無痛擴縮容(擴縮容過程中不影響正在執行的查詢)不是那麼容易的哦。
另外一塊花費是Presto調用OSS讀取資料産生的OSS接口調用費用, 在這一塊我們做了大幅優化，平均來看可以幫助使用者節省OSS調用費用 60% - 90%(
https://yq.aliyun.com/articles/760352)。
是以平均來看，去除超低頻的使用者使用場景以及超高頻的使用者使用場景，DLA SQL的成本效益可以做到自建Presto的2到10倍。
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 mysql_db WITH DBPROPERTIES (
CATALOG = 'mysql',
LOCATION = 'jdbc:mysql://rm-******fake.mysql.rds.aliyuncs.com:3306/mysql_dbname',
USER = 'mysql_username',
PASSWORD = 'mysql_password',
INSTANCE_ID = 'mysql_instance_id',
VPC_ID = 'mysql_vpcid'
); 更少的運維操作意味着整個服務更高的可用性，更平滑的使用體驗。
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'; 四、總結與展望
DLA SQL(相容Presto)的目标是提供比開源自建更高的成本效益、開箱即用的體驗、友善的資料攝入、MySQL生态帶來的簡單易用、内置各種優化的資料湖分析計算服務。使用者可以先通過使用Serverless版本低成本試用，然後根據使用頻率的高低、對資源是否有強獨占的需求來決定生産環境使用Serverless版本還是CU版本。DLA SQL還在不斷發展中，目前規劃中的一些特性包含:
- 按照時間段或者工作負載進行自動擴縮容，幫助使用者節省成本。
- 支援檔案緩存機制，提升查詢性能
- 内置大資料最佳實踐，自動攔截Bad SQL
歡迎大家關注我們的釘釘群擷取最新的資訊: