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.192、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