今天就跟大家聊聊有關(guān)Presto在軟件的探索與實(shí)踐是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)總部坐落于成都市區(qū)，致力網(wǎng)站建設(shè)服務(wù)有成都做網(wǎng)站、網(wǎng)站制作、網(wǎng)絡(luò)營(yíng)銷策劃、網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站維護(hù)、公眾號(hào)搭建、微信小程序定制開發(fā)、軟件開發(fā)等為企業(yè)提供一整套的信息化建設(shè)解決方案。創(chuàng)造真正意義上的網(wǎng)站建設(shè)，為互聯(lián)網(wǎng)品牌在互動(dòng)行銷領(lǐng)域創(chuàng)造價(jià)值而不懈努力！

• 完全基于內(nèi)存的并行計(jì)算
• 流水線
• 本地化計(jì)算
• 動(dòng)態(tài)編譯執(zhí)行計(jì)劃
• 小心使用內(nèi)存和數(shù)據(jù)結(jié)構(gòu)
• GC控制
• 無(wú)容錯(cuò)

• Hive SQL查詢加速
• 數(shù)據(jù)平臺(tái)Ad-Hoc查詢
• 報(bào)表（BI報(bào)表、自定義報(bào)表）
• 活動(dòng)營(yíng)銷
• 數(shù)據(jù)質(zhì)量檢測(cè)
• 資產(chǎn)管理
• 固定數(shù)據(jù)產(chǎn)品

 

 

▍2.4 集群部署  
 

 

 

     

 

• PrestoSQL社區(qū)活躍度更高，PR和用戶問(wèn)題能夠及時(shí)回復(fù)
• PrestoDB主要主力還是Facebook維護(hù)，以其內(nèi)部需求為主
• PrestoDB未來(lái)方向主要是ETL相關(guān)的，我們有Spark兜底，ETL功能依賴Spark、Hive

• 隱式類型轉(zhuǎn)換
• 語(yǔ)義兼容
• 語(yǔ)法兼容
• 支持Hive視圖
• Parquet HDFS文件讀取支持
• 大量UDF支持
• 其他

根據(jù)不同的業(yè)務(wù)劃分不同的label，通過(guò)配置文件配置業(yè)務(wù)方指定的label和其對(duì)應(yīng)的機(jī)器列表，Coordinator會(huì)加載配置，在內(nèi)存里維護(hù)集群label信息，同時(shí)如果配置文件里label信息變動(dòng)，Coordinator會(huì)定時(shí)更新label信息，這樣調(diào)度時(shí)根據(jù)SQL指定的label信息來(lái)獲取對(duì)應(yīng)的Worker機(jī)器，如指定label A時(shí)，那調(diào)度機(jī)器里只選擇Worker A 和 Worker B 即可。這樣就可以做到讓機(jī)器物理隔離了，對(duì)性能要求高的業(yè)務(wù)查詢既有保障了。  

 

 

▍4.3 Druid Connector  

 

使用 Presto + HDFS 有一些痛點(diǎn)：  

 

• latency高，QPS較低 
• 不能查實(shí)時(shí)數(shù)據(jù)，如果有實(shí)時(shí)數(shù)據(jù)需求，需要再構(gòu)建一條實(shí)時(shí)數(shù)據(jù)鏈路，增加了系統(tǒng)的復(fù)雜性
• 要想獲得極限性能，必須與HDFS DataNode 混部，且DataNode使用高級(jí)硬件，有自建HDFS的需求，增加了運(yùn)維的負(fù)擔(dān)

 

所以我們?cè)?.215版本實(shí)現(xiàn)了Presto on Druid Connector，此插件有如下優(yōu)點(diǎn)：  

 

• 結(jié)合 Druid 的預(yù)聚合、計(jì)算能力（過(guò)濾聚合）、Cache能力，提升Presto性能（RT與QPS）
• 讓 Presto 具備查詢 Druid 實(shí)時(shí)數(shù)據(jù)能力
• 為Druid提供全面的SQL能力支持，擴(kuò)展Druid數(shù)據(jù)的應(yīng)用場(chǎng)景
• 通過(guò)Druid Broker獲取Druid元數(shù)據(jù)信息
• 從Druid Historical直接獲取數(shù)據(jù)
• 實(shí)現(xiàn)了Limit下推、Filter下推、Project下推及Agg下推

 

在PrestoSQL 340版本，社區(qū)也實(shí)現(xiàn)了Presto on Druid Connector，但是此Connector是通過(guò)JDBC實(shí)現(xiàn)的，缺點(diǎn)比較明顯：  

 

• 無(wú)法劃分多個(gè)Split，查詢性能差
• 請(qǐng)求查詢Broker，之后再查詢Historical，多一次網(wǎng)絡(luò)通信
• 對(duì)于一些場(chǎng)景，如大量Scan場(chǎng)景，會(huì)導(dǎo)致Broker OOM
• Project及Agg下推支持不完善

 

詳細(xì)架構(gòu)圖見(jiàn)：  

 

 

 

使用了Presto on Druid后，一些場(chǎng)景，性能提升4~5倍。  

 

 

▍4.4 易用性建設(shè)  

 

為了支持公司的幾個(gè)核心數(shù)據(jù)平臺(tái)，包括：數(shù)夢(mèng)、提取工具、數(shù)易及特征加速及各種散戶，我們對(duì)Presto做了很多二次開發(fā)，包括權(quán)限管理、語(yǔ)法支持等，保證了業(yè)務(wù)的快速接入。主要工作：  

 

• 租戶與權(quán)限
• 與內(nèi)部Hadoop打通，使用HDFS SIMPLE協(xié)議做認(rèn)證
• 使用Ranger做鑒權(quán)，解析SQL使Presto擁有將列信息傳遞給下游的能力，提供用戶名+數(shù)據(jù)庫(kù)名/表名/列名，四元組的鑒權(quán)能力，同時(shí)提供多表同時(shí)鑒權(quán)的能力
• 用戶指定用戶名做鑒權(quán)和認(rèn)證，大賬號(hào)用于讀寫HDFS數(shù)據(jù)
• 支持視圖、表別名鑒權(quán)

 

• 語(yǔ)法拓展
• 支持add partition
• 支持?jǐn)?shù)字開頭的表
• 支持?jǐn)?shù)字開頭的字段

 

• 特性增強(qiáng)
• insert數(shù)據(jù)時(shí)，將插入數(shù)據(jù)的總行數(shù)寫入HMS，為業(yè)務(wù)方提供毫秒級(jí)的元數(shù)據(jù)感知能力
• 支持查詢進(jìn)度滾動(dòng)更新，提升了用戶體驗(yàn)
• 支持查詢可以指定優(yōu)先級(jí)，為用戶不同等級(jí)的業(yè)務(wù)提供了優(yōu)先級(jí)控制的能力
• 修改通信協(xié)議，支持業(yè)務(wù)方可以傳達(dá)自定義信息，滿足了用戶的日志審計(jì)需要等
• 支持DeprecatedLzoTextInputFormat格式
• 支持讀HDFS Parquet文件路徑

 

 

▍   4.5 穩(wěn)定性建設(shè)  

 

Presto在使用過(guò)程中會(huì)遇到很多穩(wěn)定性問(wèn)題，比如Coordinator OOM，Worker Full GC等，為了解決和方便定位這些問(wèn)題，首先我們做了監(jiān)控體系建設(shè)，主要包括：  

 

• 通過(guò)Presto Plugin實(shí)現(xiàn)日志審計(jì)功能
• 通過(guò)JMX獲取引擎指標(biāo)將監(jiān)控信息寫入Ganglia
• 將日志審計(jì)采集到HDFS和ES；     統(tǒng)一接入運(yùn)維監(jiān)控體系，將所有指標(biāo)發(fā)到 Kafka；
• Presto UI改進(jìn)：     可以查看Worker信息，可以查看Worker死活信息

 

通過(guò)以上功能，在每次出現(xiàn)穩(wěn)定性問(wèn)題時(shí)，方便我們及時(shí)定位問(wèn)題，包括指標(biāo)查看及SQL回放等，如下圖所示，可以查看某集群的成功及失敗SQL數(shù)，我們可以通過(guò)定義查詢失敗率來(lái)觸發(fā)報(bào)警：  

 

 

 

在Presto交流社區(qū)，Presto的穩(wěn)定性問(wèn)題困擾了很多Presto使用者，包括Coordinator和Worker掛掉，集群運(yùn)行一段時(shí)間后查詢性能變慢等。我們?cè)诮鉀Q這些問(wèn)題時(shí)積累了很多經(jīng)驗(yàn)，這里說(shuō)下解決思路和方法。

根據(jù)職責(zé)劃分，Presto分為Coordinator和Worker模塊，Coordinator主要負(fù)責(zé)SQL解析、生成查詢計(jì)劃、Split調(diào)度及查詢狀態(tài)管理等，所以當(dāng)Coordinator遇到OOM或者Coredump時(shí)，獲取元信息及生成Splits是重點(diǎn)懷疑的地方。而內(nèi)存問(wèn)題，推薦使用MAT分析具體原因。如下圖是通過(guò)MAT分析，得出開啟了FileSystem Cache，內(nèi)存泄漏導(dǎo)致OOM。

 

 
 

 

 

這里我們總結(jié)了Coordinator常見(jiàn)的問(wèn)題和解決方法：  

 

• 使用HDFS FileSystem Cache導(dǎo)致內(nèi)存泄漏，解決方法禁止FileSystem Cache，后續(xù)Presto自己維護(hù)了FileSystem Cache
• Jetty導(dǎo)致堆外內(nèi)存泄漏，原因是Gzip導(dǎo)致了堆外內(nèi)存泄漏，升級(jí)Jetty版本解決
• Splits太多，無(wú)可用端口，TIME_WAIT太高，修改TCP參數(shù)解決
• JVM Coredump，顯示"unable to create new native thread"，通過(guò)修改pid_max及max_map_count解決
• Presto內(nèi)核Bug，查詢失敗的SQL太多，導(dǎo)致Coordinator內(nèi)存泄漏，社區(qū)已修復(fù)

 

而Presto Worker主要用于計(jì)算，性能瓶頸點(diǎn)主要是內(nèi)存和CPU。內(nèi)存方面通過(guò)三種方法來(lái)保障和查找問(wèn)題：  

 

• 通過(guò)Resource Group控制業(yè)務(wù)并發(fā)，防止嚴(yán)重超賣
• 通過(guò)JVM調(diào)優(yōu)，解決一些常見(jiàn)內(nèi)存問(wèn)題，如Young GC Exhausted
• 善用MAT工具，發(fā)現(xiàn)內(nèi)存瓶頸

 

而Presto Worker常會(huì)遇到查詢變慢問(wèn)題，兩方面原因，一是確定是否開啟了Swap內(nèi)存，當(dāng)Free內(nèi)存不足時(shí)，使用Swap會(huì)嚴(yán)重影響查詢性能。第二是CPU問(wèn)題，解決此類問(wèn)題，要善用Perf工具，多做Perf來(lái)分析CPU為什么不在干活，看CPU主要在做什么，是GC問(wèn)題還是JVM Bug。如下圖所示，為線上Presto集群觸發(fā)了JVM Bug，導(dǎo)致運(yùn)行一段時(shí)間后查詢變慢，重啟后恢復(fù)，Perf后找到原因，分析JVM代碼，可通過(guò)JVM調(diào)優(yōu)或升級(jí)JVM版本解決：  

 

這里我們也總結(jié)了Worker常見(jiàn)的問(wèn)題和解決方法：  

 

• Sys load過(guò)高，導(dǎo)致業(yè)務(wù)查詢性能影響很大，研究jvm原理，通過(guò)參數(shù)（-XX:PerMethodRecompilationCutoff=10000 及 -XX:PerBytecodeRecompilationCutoff=10000）解決，也可升級(jí)最新JVM解決
• Worker查詢hang住問(wèn)題，原因HDFS客戶端存在bug，當(dāng)Presto與HDFS混部署，數(shù)據(jù)和客戶端在同一臺(tái)機(jī)器上時(shí)，短路讀時(shí)一直wait鎖，導(dǎo)致查詢Hang住超時(shí)，Hadoop社區(qū)已解決
• 超賣導(dǎo)致Worker Young GC Exhausted，優(yōu)化GC參數(shù)，如設(shè)置-XX:G1ReservePercent=25 及 -XX:InitiatingHeapOccupancyPercent=15
• ORC太大，導(dǎo)致Presto讀取ORC Stripe Statistics出現(xiàn)OOM，解決方法是限制ProtoBuf報(bào)文大小，同時(shí)協(xié)助業(yè)務(wù)方合理數(shù)據(jù)治理
• 修改Presto內(nèi)存管理邏輯，優(yōu)化Kill策略，保障當(dāng)內(nèi)存不夠時(shí)，Presto Worker不會(huì)OOM，只需要將大查詢Kill掉，后續(xù)熔斷機(jī)制會(huì)改為基于JVM，類似ES的熔斷器，比如95% JVM 內(nèi)存時(shí)，Kill掉最大SQL

▍4.6 引擎優(yōu)化及調(diào)研  

 

作為一個(gè)Ad-Hoc引擎，Presto查詢性能越快，用戶體驗(yàn)越好，為了提高Presto的查詢性能，在Presto on Hive場(chǎng)景，我們做了很多引擎優(yōu)化工作，主要工作：  

 

• 某業(yè)務(wù)集群進(jìn)行了JVM調(diào)優(yōu)，將Ref Proc由單線程改為并行執(zhí)行，普通查詢由30S~1分鐘降低為3-4S，性能提升10倍+
• ORC數(shù)據(jù)優(yōu)化，將指定string字段添加了布隆過(guò)濾器，查詢性能提升20-30%，針對(duì)一些業(yè)務(wù)做了調(diào)優(yōu)
• 數(shù)據(jù)治理和小文件合并，某業(yè)務(wù)方查詢性能由20S降低為10S，性能提升一倍，且查詢性能穩(wěn)定
• ORC格式性能優(yōu)化，查詢耗時(shí)減少5%
• 分區(qū)裁剪優(yōu)化，解決指定分區(qū)但獲取所有分區(qū)元信息問(wèn)題，減少了HMS的壓力
• 下推優(yōu)化，實(shí)現(xiàn)了Limit、Filter、Project、Agg下推到存儲(chǔ)層

 

18年我們?yōu)榱颂岣逷resto查詢性能，也調(diào)研了一些技術(shù)方案，包括Presto on Alluxio和Presto on Carbondata，但是這2種方案最后都被舍棄了，原因是：  

 

• Presto on Alluxio查詢性能提升35%，但是內(nèi)存占用和性能提升不成正比，所以我們放棄了Presto on Alluxio，后續(xù)可能會(huì)對(duì)一些性能要求敏感的業(yè)務(wù)使用
• Presto on Carbondata是在18年8月份測(cè)試的，當(dāng)時(shí)的版本，Carbondata穩(wěn)定性較差，性能沒(méi)有明顯優(yōu)勢(shì)，一些場(chǎng)景ORC更快，所以我們沒(méi)有再繼續(xù)跟蹤調(diào)研Presto on Carbondata。     因?yàn)榈蔚斡袑ｉT維護(hù)Druid的團(tuán)隊(duì)，所以我們對(duì)接了Presto on Druid，一些場(chǎng)景性能提升4~5倍，后續(xù)我們會(huì)更多關(guān)注Presto on Clickhouse及Presto on Elasticsearch

 

 

 

5.   

總結(jié)  

 

通過(guò)以上工作，滴滴Presto逐漸接入公司各大數(shù)據(jù)平臺(tái)，并成為了公司首選Ad-Hoc查詢引擎及Hive SQL加速引擎，下圖可以看到某產(chǎn)品接入后的性能提升：

上圖可以看到大約2018年10月該平臺(tái)開始接入Presto，查詢耗時(shí)TP50性能提升了10+倍，由400S降低到31S。且在任務(wù)數(shù)逐漸增長(zhǎng)的情況下，查詢耗時(shí)保證穩(wěn)定不變。

而高性能集群，我們做了很多穩(wěn)定性和性能優(yōu)化工作，保證了平均查詢時(shí)間小于2S。如下圖所示：

6. 

展望

Presto主要應(yīng)用場(chǎng)景是Ad-Hoc查詢，所以其高峰期主要在白天，如下圖所示，是網(wǎng)約車業(yè)務(wù)下午12-16點(diǎn)的查詢，可以看到平均CPU使用率在40%以上。

但是如果看最近一個(gè)月的CPU使用率會(huì)發(fā)現(xiàn)，平均CPU使用率比較低，且波峰在白天10~18點(diǎn)，晚上基本上沒(méi)有查詢，CPU使用率不到5%。如下圖所示：

所以，解決晚上資源浪費(fèi)問(wèn)題是我們今后需要解決的難題。

看完上述內(nèi)容，你們對(duì)Presto在軟件的探索與實(shí)踐是怎樣的有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。