Presto在滴滴的探索與實踐

桔妹導讀：Presto在滴滴內部發展三年，已經成爲滴滴內部Ad-Hoc和Hive SQL加速的首選引擎。目前服務6K+用戶，天天讀取2PB ~ 3PB HDFS數據，處理30萬億~35萬億條記錄，爲了承接業務及豐富使用場景，滴滴Presto須要解決穩定性、易用性、性能、成本等諸多問題。咱們在3年多的時間裏，作了大量優化和二次開發，積攢了很是豐富的經驗。本文分享了滴滴對Presto引擎的改進和優化，同時也提供了大量穩定性建設經驗。

1. 

Presto簡介

▍1.1 簡介

Presto是Facebook開源的MPP（Massive Parallel Processing）SQL引擎，其理念來源於一個叫Volcano的並行數據庫，該數據庫提出了一個並行執行SQL的模型，它被設計爲用來專門進行高速、實時的數據分析。Presto是一個SQL計算引擎，分離計算層和存儲層，其不存儲數據，經過Connector SPI實現對各類數據源（Storage）的訪問。

▍ 1.2 架構

Presto沿用了通用的Master-Slave架構，一個Coordinator，多個Worker。Coordinator負責解析SQL語句，生成執行計劃，分發執行任務給Worker節點執行；Worker節點負責實際執行查詢任務。Presto提供了一套Connector接口，用於讀取元信息和原始數據，Presto 內置有多種數據源，如 Hive、MySQL、Kudu、Kafka 等。同時，Presto 的擴展機制容許自定義 Connector，從而實現對定製數據源的查詢。假如配置了Hive Connector，須要配置一個Hive MetaStore服務爲Presto提供Hive元信息，Worker節點經過Hive Connector與HDFS交互，讀取原始數據。

▍1.3 實現低延時原理

Presto是一個交互式查詢引擎，咱們最關心的是Presto實現低延時查詢的原理，如下幾點是其性能脫穎而出的主要緣由：

• 徹底基於內存的並行計算
• 流水線
• 本地化計算
• 動態編譯執行計劃
• 當心使用內存和數據結構
• GC控制
• 無容錯

2. 

Presto在滴滴的應用

▍2.1 業務場景

• Hive SQL查詢加速
• 數據平臺Ad-Hoc查詢
• 報表（BI報表、自定義報表）
• 活動營銷
• 數據質量檢測
• 資產管理
• 固定數據產品

▍2.2 業務規模

▍2.3 業務增加

▍2.4 集羣部署

目前Presto分爲混合集羣和高性能集羣，如上圖所示，混合集羣共用HDFS集羣，與離線Hadoop大集羣混合部署，爲了防止集羣內大查詢影響小查詢， 而單獨搭建集羣會致使集羣太多，維護成本過高，咱們經過指定Label來作到物理集羣隔離（詳細後文會講到）。而高性能集羣，HDFS是單獨部署的，且能夠訪問Druid， 使Presto 具有查詢實時數據和離線數據能力。

▍2.5 接入方式

二次開發了JDBC、Go、Python、Cli、R、NodeJs 、HTTP等多種接入方式，打通了公司內部權限體系，讓業務方方便快捷的接入 Presto 的，知足了業務方多種技術棧的接入需求。

Presto 接入了查詢路由 Gateway，Gateway會智能選擇合適的引擎，用戶查詢優先請求Presto，若是查詢失敗，會使用Spark查詢，若是依然失敗，最後會請求Hive。在Gateway層，咱們作了一些優化來區分大查詢、中查詢及小查詢，對於查詢時間小於3分鐘的，咱們即認爲適合Presto查詢，好比經過HBO（基於歷史的統計信息）及JOIN數量來區分查詢大小，架構圖見：

3. 

引擎迭代

咱們從2017年09月份開始調研Presto，經歷過0.19二、0.215，共發佈56次版本。而在19年初（0.215版本是社區分家版本），Presto社區分家，分爲兩個項目，叫PrestoDB和PrestoSQL，二者都成立了本身的基金會。咱們決定升級到PrestoSQL 最新版本（340版本）緣由是：

• PrestoSQL社區活躍度更高，PR和用戶問題可以及時回覆
• PrestoDB主要主力仍是Facebook維護，以其內部需求爲主
• PrestoDB將來方向主要是ETL相關的，咱們有Spark兜底，ETL功能依賴Spark、Hive

4. 

引擎改進

在滴滴內部，Presto主要用於Ad-Hoc查詢及Hive SQL查詢加速，爲了方便用戶能儘快將SQL遷移到Presto引擎上，且提升Presto引擎查詢性能，咱們對Presto作了大量二次開發。同時，由於使用Gateway，即便SQL查詢出錯，SQL也會轉發到Spark及Hive上，因此咱們沒有使用Presto的Spill to Disk功能。這樣一個純內存SQL引擎在使用過程當中會遇到不少穩定問題，咱們在解決這些問題時，也積累了不少經驗，下面將一一介紹：

▍4.1 Hive SQL兼容

18年上半年，Presto剛起步，滴滴內部不少用戶不肯意遷移業務，主要是由於Presto是ANSI SQL，與HiveQL差距較大，且查詢結果也會出現結果不一致問題，遷移成本比較高，爲了方便Hive用戶能順利遷移業務，咱們對Presto作了Hive SQL兼容。而在技術選型時，咱們沒有在Presto上層，即沒有在Gateway這層作SQL兼容，主要是由於開發量較大，且UDF相關的開發和轉換成本過高，另外就是須要多作一次SQL解析，查詢性能會受到影響，同時增長了Hive Metastore的請求次數，當時Hive Metastore的壓力比較大，考慮到成本和穩定性，咱們最後選擇在Presto引擎層上兼容。

主要工做：

• 隱式類型轉換
• 語義兼容
• 語法兼容
• 支持Hive視圖
• Parquet HDFS文件讀取支持
• 大量UDF支持
• 其餘

Hive SQL兼容，咱們迭代了三個大版本，目前線上SQL經過率97~99%。而業務從Spark/Hive遷移到Presto後，查詢性能平均提高30%~50%，甚至一些場景提高10倍，Ad-Hoc場景共節省80%機器資源。下圖是線上Presto集羣的SQL查詢經過率及失敗緣由佔比，'null' 表示查詢成功的SQL，其餘表示錯誤緣由：

▍4.2 物理資源隔離

上文說到，對性能要求高的業務與大查詢業務方混合跑，查詢性能容易受到影響，只有單獨搭建集羣。而單獨搭建集羣致使Presto集羣太多，維護成本過高。由於目前咱們Presto Coordinator尚未遇到瓶頸，大查詢主要影響Worker性能，好比一條大SQL致使Worker CPU打滿，致使其餘業務方SQL查詢變慢。因此咱們修改調度模塊，讓Presto支持能夠動態打Label，動態調度指定的 Label 機器。以下圖所示：

根據不一樣的業務劃分不一樣的label，經過配置文件配置業務方指定的label和其對應的機器列表，Coordinator會加載配置，在內存裏維護集羣label信息，同時若是配置文件裏label信息變更，Coordinator會定時更新label信息，這樣調度時根據SQL指定的label信息來獲取對應的Worker機器，如指定label A時，那調度機器裏只選擇Worker A 和 Worker B 便可。這樣就能夠作到讓機器物理隔離了，對性能要求高的業務查詢既有保障了。

▍4.3 Druid Connector

使用 Presto + HDFS 有一些痛點：

• latency高，QPS較低 
• 不能查實時數據，若是有實時數據需求，須要再構建一條實時數據鏈路，增長了系統的複雜性
• 要想得到極限性能，必須與HDFS DataNode 混部，且DataNode使用高級硬件，有自建HDFS的需求，增長了運維的負擔

因此咱們在0.215版本實現了Presto on Druid Connector，此插件有以下優勢：

• 結合 Druid 的預聚合、計算能力（過濾聚合）、Cache能力，提高Presto性能（RT與QPS）
• 讓 Presto 具有查詢 Druid 實時數據能力
• 爲Druid提供全面的SQL能力支持，擴展Druid數據的應用場景
• 經過Druid Broker獲取Druid元數據信息
• 從Druid Historical直接獲取數據
• 實現了Limit下推、Filter下推、Project下推及Agg下推

在PrestoSQL 340版本，社區也實現了Presto on Druid Connector，可是此Connector是經過JDBC實現的，缺點比較明顯：

• 沒法劃分多個Split，查詢性能差
• 請求查詢Broker，以後再查詢Historical，多一次網絡通訊
• 對於一些場景，如大量Scan場景，會致使Broker OOM
• Project及Agg下推支持不完善

詳細架構圖見：

使用了Presto on Druid後，一些場景，性能提高4~5倍。

▍4.4 易用性建設

爲了支持公司的幾個核心數據平臺，包括：數夢、提取工具、數易及特徵加速及各類散戶，咱們對Presto作了不少二次開發，包括權限管理、語法支持等，保證了業務的快速接入。主要工做：

• 租戶與權限
• 與內部Hadoop打通，使用HDFS SIMPLE協議作認證
• 使用Ranger作鑑權，解析SQL使Presto擁有將列信息傳遞給下游的能力，提供用戶名+數據庫名/表名/列名，四元組的鑑權能力，同時提供多表同時鑑權的能力
• 用戶指定用戶名作鑑權和認證，大帳號用於讀寫HDFS數據
• 支持視圖、表別名鑑權

• 語法拓展
• 支持add partition
• 支持數字開頭的表
• 支持數字開頭的字段

• 特性加強
• insert數據時，將插入數據的總行數寫入HMS，爲業務方提供毫秒級的元數據感知能力
• 支持查詢進度滾動更新，提高了用戶體驗
• 支持查詢能夠指定優先級，爲用戶不一樣等級的業務提供了優先級控制的能力
• 修改通訊協議，支持業務方能夠傳達自定義信息，知足了用戶的日誌審計須要等
• 支持DeprecatedLzoTextInputFormat格式
• 支持讀HDFS Parquet文件路徑

▍ 4.5 穩定性建設

Presto在使用過程當中會遇到不少穩定性問題，好比Coordinator OOM，Worker Full GC等，爲了解決和方便定位這些問題，首先咱們作了監控體系建設，主要包括：

• 經過Presto Plugin實現日誌審計功能
• 經過JMX獲取引擎指標將監控信息寫入Ganglia
• 將日誌審計採集到HDFS和ES； 統一接入運維監控體系，將全部指標發到 Kafka；
• Presto UI改進： 能夠查看Worker信息，能夠查看Worker死活信息

經過以上功能，在每次出現穩定性問題時，方便咱們及時定位問題，包括指標查看及SQL回放等，以下圖所示，能夠查看某集羣的成功及失敗SQL數，咱們能夠經過定義查詢失敗率來觸發報警：

在Presto交流社區，Presto的穩定性問題困擾了不少Presto使用者，包括Coordinator和Worker掛掉，集羣運行一段時間後查詢性能變慢等。咱們在解決這些問題時積累了不少經驗，這裏說下解決思路和方法。

根據職責劃分，Presto分爲Coordinator和Worker模塊，Coordinator主要負責SQL解析、生成查詢計劃、Split調度及查詢狀態管理等，因此當Coordinator遇到OOM或者Coredump時，獲取元信息及生成Splits是重點懷疑的地方。而內存問題，推薦使用MAT分析具體緣由。以下圖是經過MAT分析，得出開啓了FileSystem Cache，內存泄漏致使OOM。

這裏咱們總結了Coordinator常見的問題和解決方法：

• 使用HDFS FileSystem Cache致使內存泄漏，解決方法禁止FileSystem Cache，後續Presto本身維護了FileSystem Cache
• Jetty致使堆外內存泄漏，緣由是Gzip致使了堆外內存泄漏，升級Jetty版本解決
• Splits太多，無可用端口，TIME_WAIT過高，修改TCP參數解決
• JVM Coredump，顯示"unable to create new native thread"，經過修改pid_max及max_map_count解決
• Presto內核Bug，查詢失敗的SQL太多，致使Coordinator內存泄漏，社區已修復

而Presto Worker主要用於計算，性能瓶頸點主要是內存和CPU。內存方面經過三種方法來保障和查找問題：

• 經過Resource Group控制業務併發，防止嚴重超賣
• 經過JVM調優，解決一些常見內存問題，如Young GC Exhausted
• 善用MAT工具，發現內存瓶頸

而Presto Worker常會遇到查詢變慢問題，兩方面緣由，一是肯定是否開啓了Swap內存，當Free內存不足時，使用Swap會嚴重影響查詢性能。第二是CPU問題，解決此類問題，要善用Perf工具，多作Perf來分析CPU爲何不在幹活，看CPU主要在作什麼，是GC問題仍是JVM Bug。以下圖所示，爲線上Presto集羣觸發了JVM Bug，致使運行一段時間後查詢變慢，重啓後恢復，Perf後找到緣由，分析JVM代碼，可經過JVM調優或升級JVM版本解決：

這裏咱們也總結了Worker常見的問題和解決方法：

• Sys load太高，致使業務查詢性能影響很大，研究jvm原理，經過參數（-XX:PerMethodRecompilationCutoff=10000 及 -XX:PerBytecodeRecompilationCutoff=10000）解決，也可升級最新JVM解決
• Worker查詢hang住問題，緣由HDFS客戶端存在bug，當Presto與HDFS混部署，數據和客戶端在同一臺機器上時，短路讀時一直wait鎖，致使查詢Hang住超時，Hadoop社區已解決
• 超賣致使Worker Young GC Exhausted，優化GC參數，如設置-XX:G1ReservePercent=25 及 -XX:InitiatingHeapOccupancyPercent=15
• ORC太大，致使Presto讀取ORC Stripe Statistics出現OOM，解決方法是限制ProtoBuf報文大小，同時協助業務方合理數據治理
• 修改Presto內存管理邏輯，優化Kill策略，保障當內存不夠時，Presto Worker不會OOM，只須要將大查詢Kill掉，後續熔斷機制會改成基於JVM，相似ES的熔斷器，好比95% JVM 內存時，Kill掉最大SQL

▍4.6 引擎優化及調研

做爲一個Ad-Hoc引擎，Presto查詢性能越快，用戶體驗越好，爲了提升Presto的查詢性能，在Presto on Hive場景，咱們作了不少引擎優化工做，主要工做：

• 某業務集羣進行了JVM調優，將Ref Proc由單線程改成並行執行，普通查詢由30S~1分鐘下降爲3-4S，性能提高10倍+
• ORC數據優化，將指定string字段添加了布隆過濾器，查詢性能提高20-30%，針對一些業務作了調優
• 數據治理和小文件合併，某業務方查詢性能由20S下降爲10S，性能提高一倍，且查詢性能穩定
• ORC格式性能優化，查詢耗時減小5%
• 分區裁剪優化，解決指定分區但獲取全部分區元信息問題，減小了HMS的壓力
• 下推優化，實現了Limit、Filter、Project、Agg下推到存儲層

18年咱們爲了提升Presto查詢性能，也調研了一些技術方案，包括Presto on Alluxio和Presto on Carbondata，可是這2種方案最後都被捨棄了，緣由是：

• Presto on Alluxio查詢性能提高35%，可是內存佔用和性能提高不成正比，因此咱們放棄了Presto on Alluxio，後續可能會對一些性能要求敏感的業務使用
• Presto on Carbondata是在18年8月份測試的，當時的版本，Carbondata穩定性較差，性能沒有明顯優點，一些場景ORC更快，因此咱們沒有再繼續跟蹤調研Presto on Carbondata。 由於滴滴有專門維護Druid的團隊，因此咱們對接了Presto on Druid，一些場景性能提高4~5倍，後續咱們會更多關注Presto on Clickhouse及Presto on Elasticsearch

5. 

總結

經過以上工做，滴滴Presto逐漸接入公司各大數據平臺，併成爲了公司首選Ad-Hoc查詢引擎及Hive SQL加速引擎，下圖能夠看到某產品接入後的性能提高：

上圖能夠看到大約2018年10月該平臺開始接入Presto，查詢耗時TP50性能提高了10+倍，由400S下降到31S。且在任務數逐漸增加的狀況下，查詢耗時保證穩定不變。

而高性能集羣，咱們作了不少穩定性和性能優化工做，保證了平均查詢時間小於2S。以下圖所示：

6. 

展望

Presto主要應用場景是Ad-Hoc查詢，因此其高峯期主要在白天，以下圖所示，是網約車業務下午12-16點的查詢，能夠看到平均CPU使用率在40%以上。

可是若是看最近一個月的CPU使用率會發現，平均CPU使用率比較低，且波峯在白天10~18點，晚上基本上沒有查詢，CPU使用率不到5%。以下圖所示：

因此，解決晚上資源浪費問題是咱們從此須要解決的難題。

同時，爲了避免與開源社區脫節，咱們打算升級PrestoDB 0.215到PrestoSQL 340版本，屆時會把咱們的Presto on Druid代碼開源出來，回饋社區。

本文做者

▬

滴滴Presto引擎負責人，負責帶領引擎團隊深刻Presto內核，解決在海量數據規模下Presto遇到的穩定性、性能、成本方面的問題。搜索引擎及OLAP引擎愛好者，公衆號：FFCompute

關於團隊

▬

滴滴大數據架構部 OLAP & 檢索平臺組負責以 Elasticsearch、Clickhouse、Presto 及 Druid 爲表明的 OLAP 引擎的內核級極致優化，爲滴滴各個產品線提供穩定可靠的 PB 級海量數據的實時數據分析、日誌檢索、監控及即席查詢服務。

博聞強識，招賢納士，滴滴用廣闊的舞臺，在這裏，等待你！

掃描了解更多崗位

延伸閱讀

▬

內容編輯 | Charlotte

聯繫咱們 | DiDiTech@didiglobal.com

本文分享自微信公衆號 - 滴滴技術（didi_tech）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。