溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊×
其他方式登錄
點(diǎn)擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

Presto在軟件的探索與實(shí)踐是怎樣的

發(fā)布時間：2021-12-27 15:35:55 來源：億速云 閱讀：189 作者：柒染 欄目：大數(shù)據(jù)

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


1. 
Presto簡介
▍1.1 簡介

Presto是Facebook開源的MPP（Massive Parallel Processing）SQL引擎，其理念來源于一個叫Volcano的并行數(shù)據(jù)庫，該數(shù)據(jù)庫提出了一個并行執(zhí)行SQL的模型，它被設(shè)計為用來專門進(jìn)行高速、實(shí)時的數(shù)據(jù)分析。Presto是一個SQL計算引擎，分離計算層和存儲層，其不存儲數(shù)據(jù)，通過Connector SPI實(shí)現(xiàn)對各種數(shù)據(jù)源（Storage）的訪問。


▍  1.2 架構(gòu)

Presto在軟件的探索與實(shí)踐是怎樣的

Presto沿用了通用的Master-Slave架構(gòu)，一個Coordinator，多個Worker。Coordinator負(fù)責(zé)解析SQL語句，生成執(zhí)行計劃，分發(fā)執(zhí)行任務(wù)給Worker節(jié)點(diǎn)執(zhí)行；Worker節(jié)點(diǎn)負(fù)責(zé)實(shí)際執(zhí)行查詢?nèi)蝿?wù)。Presto提供了一套Connector接口，用于讀取元信息和原始數(shù)據(jù)，Presto 內(nèi)置有多種數(shù)據(jù)源，如 Hive、MySQL、Kudu、Kafka 等。同時，Presto 的擴(kuò)展機(jī)制允許自定義 Connector，從而實(shí)現(xiàn)對定制數(shù)據(jù)源的查詢。假如配置了Hive Connector，需要配置一個Hive MetaStore服務(wù)為Presto提供Hive元信息，Worker節(jié)點(diǎn)通過Hive Connector與HDFS交互，讀取原始數(shù)據(jù)。  

  

  
▍1.3 實(shí)現(xiàn)低延時原理  

Presto是一個交互式查詢引擎，我們最關(guān)心的是Presto實(shí)現(xiàn)低延時查詢的原理，以下幾點(diǎn)是其性能脫穎而出的主要原因：

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



2. 
Presto在滴滴的應(yīng)用
Presto在軟件的探索與實(shí)踐是怎樣的
▍2.1 業(yè)務(wù)場景

  • Hive SQL查詢加速
  • 數(shù)據(jù)平臺Ad-Hoc查詢
  • 報表（BI報表、自定義報表）
  • 活動營銷
  • 數(shù)據(jù)質(zhì)量檢測
  • 資產(chǎn)管理
  • 固定數(shù)據(jù)產(chǎn)品

Presto在軟件的探索與實(shí)踐是怎樣的


▍2.2 業(yè)務(wù)規(guī)模

Presto在軟件的探索與實(shí)踐是怎樣的


▍2.3 業(yè)務(wù)增長

Presto在軟件的探索與實(shí)踐是怎樣的

 

 
▍2.4 集群部署  
 

  
Presto在軟件的探索與實(shí)踐是怎樣的  

     
目前Presto分為混合集群和高性能集群，如上圖所示，混合集群共用HDFS集群，與離線Hadoop大集群混合部署，為了防止集群內(nèi)大查詢影響小查詢， 而單獨(dú)搭建集群會導(dǎo)致集群太多，維護(hù)成本太高，我們通過指定Label來做到物理集群隔離（詳細(xì)后文會講到）。而高性能集群，HDFS是單獨(dú)部署的，且可以訪問Druid， 使Presto 具備查詢實(shí)時數(shù)據(jù)和離線數(shù)據(jù)能力。


▍2.5 接入方式

二次開發(fā)了JDBC、Go、Python、Cli、R、NodeJs 、HTTP等多種接入方式，打通了公司內(nèi)部權(quán)限體系，讓業(yè)務(wù)方方便快捷的接入 Presto 的，滿足了業(yè)務(wù)方多種技術(shù)棧的接入需求。

Presto 接入了查詢路由 Gateway，Gateway會智能選擇合適的引擎，用戶查詢優(yōu)先請求Presto，如果查詢失敗，會使用Spark查詢，如果依然失敗，最后會請求Hive。在Gateway層，我們做了一些優(yōu)化來區(qū)分大查詢、中查詢及小查詢，對于查詢時間小于3分鐘的，我們即認(rèn)為適合Presto查詢，比如通過HBO（基于歷史的統(tǒng)計信息）及JOIN數(shù)量來區(qū)分查詢大小，架構(gòu)圖見：

Presto在軟件的探索與實(shí)踐是怎樣的



3. 
引擎迭代
Presto在軟件的探索與實(shí)踐是怎樣的
Presto在軟件的探索與實(shí)踐是怎樣的  

我們從2017年09月份開始調(diào)研Presto，經(jīng)歷過0.192、0.215，共發(fā)布56次版本。而在19年初（0.215版本是社區(qū)分家版本），Presto社區(qū)分家，分為兩個項目，叫PrestoDB和PrestoSQL，兩者都成立了自己的基金會。我們決定升級到PrestoSQL 最新版本（340版本）原因是：

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



4. 
引擎改進(jìn)
Presto在軟件的探索與實(shí)踐是怎樣的
在滴滴內(nèi)部，Presto主要用于Ad-Hoc查詢及Hive SQL查詢加速，為了方便用戶能盡快將SQL遷移到Presto引擎上，且提高Presto引擎查詢性能，我們對Presto做了大量二次開發(fā)。同時，因為使用Gateway，即使SQL查詢出錯，SQL也會轉(zhuǎn)發(fā)到Spark及Hive上，所以我們沒有使用Presto的Spill to Disk功能。這樣一個純內(nèi)存SQL引擎在使用過程中會遇到很多穩(wěn)定問題，我們在解決這些問題時，也積累了很多經(jīng)驗，下面將一一介紹：


▍4.1 Hive SQL兼容

18年上半年，Presto剛起步，滴滴內(nèi)部很多用戶不愿意遷移業(yè)務(wù)，主要是因為Presto是ANSI SQL，與HiveQL差距較大，且查詢結(jié)果也會出現(xiàn)結(jié)果不一致問題，遷移成本比較高，為了方便Hive用戶能順利遷移業(yè)務(wù)，我們對Presto做了Hive SQL兼容。而在技術(shù)選型時，我們沒有在Presto上層，即沒有在Gateway這層做SQL兼容，主要是因為開發(fā)量較大，且UDF相關(guān)的開發(fā)和轉(zhuǎn)換成本太高，另外就是需要多做一次SQL解析，查詢性能會受到影響，同時增加了Hive Metastore的請求次數(shù)，當(dāng)時Hive Metastore的壓力比較大，考慮到成本和穩(wěn)定性，我們最后選擇在Presto引擎層上兼容。

主要工作：

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

Hive SQL兼容，我們迭代了三個大版本，目前線上SQL通過率97~99%。而業(yè)務(wù)從Spark/Hive遷移到Presto后，查詢性能平均提升30%~50%，甚至一些場景提升10倍，Ad-Hoc場景共節(jié)省80%機(jī)器資源。下圖是線上Presto集群的SQL查詢通過率及失敗原因占比，'null' 表示查詢成功的SQL，其他表示錯誤原因：

Presto在軟件的探索與實(shí)踐是怎樣的


▍4.2 物理資源隔離

上文說到，對性能要求高的業(yè)務(wù)與大查詢業(yè)務(wù)方混合跑，查詢性能容易受到影響，只有單獨(dú)搭建集群。而單獨(dú)搭建集群導(dǎo)致Presto集群太多，維護(hù)成本太高。因為目前我們Presto Coordinator還沒有遇到瓶頸，大查詢主要影響Worker性能，比如一條大SQL導(dǎo)致Worker CPU打滿，導(dǎo)致其他業(yè)務(wù)方SQL查詢變慢。所以我們修改調(diào)度模塊，讓Presto支持可以動態(tài)打Label，動態(tài)調(diào)度指定的 Label 機(jī)器。如下圖所示：
Presto在軟件的探索與實(shí)踐是怎樣的

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

 

 
▍4.3 Druid Connector  

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

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

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

 
  • 結(jié)合 Druid 的預(yù)聚合、計算能力（過濾聚合）、Cache能力，提升Presto性能（RT與QPS）
  • 讓 Presto 具備查詢 Druid 實(shí)時數(shù)據(jù)能力
  • 為Druid提供全面的SQL能力支持，擴(kuò)展Druid數(shù)據(jù)的應(yīng)用場景
  • 通過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是通過JDBC實(shí)現(xiàn)的，缺點(diǎn)比較明顯：  

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

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

 
Presto在軟件的探索與實(shí)踐是怎樣的  

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

 

 
▍4.4 易用性建設(shè)  

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

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

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

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

 

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

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

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

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

 
Presto在軟件的探索與實(shí)踐是怎樣的  

 

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


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

 
 
 
Presto在軟件的探索與實(shí)踐是怎樣的  

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

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

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

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

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

 
Presto在軟件的探索與實(shí)踐是怎樣的
這里我們也總結(jié)了Worker常見的問題和解決方法：  

 
  • Sys load過高，導(dǎo)致業(yè)務(wù)查詢性能影響很大，研究jvm原理，通過參數(shù)（-XX:PerMethodRecompilationCutoff=10000 及 -XX:PerBytecodeRecompilationCutoff=10000）解決，也可升級最新JVM解決
  • Worker查詢hang住問題，原因HDFS客戶端存在bug，當(dāng)Presto與HDFS混部署，數(shù)據(jù)和客戶端在同一臺機(jī)器上時，短路讀時一直wait鎖，導(dǎo)致查詢Hang住超時，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報文大小，同時協(xié)助業(yè)務(wù)方合理數(shù)據(jù)治理
  • 修改Presto內(nèi)存管理邏輯，優(yōu)化Kill策略，保障當(dāng)內(nèi)存不夠時，Presto Worker不會OOM，只需要將大查詢Kill掉，后續(xù)熔斷機(jī)制會改為基于JVM，類似ES的熔斷器，比如95% JVM 內(nèi)存時，Kill掉最大SQL

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

  
作為一個Ad-Hoc引擎，Presto查詢性能越快，用戶體驗越好，為了提高Presto的查詢性能，在Presto on Hive場景，我們做了很多引擎優(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字段添加了布隆過濾器，查詢性能提升20-30%，針對一些業(yè)務(wù)做了調(diào)優(yōu)
  • 數(shù)據(jù)治理和小文件合并，某業(yè)務(wù)方查詢性能由20S降低為10S，性能提升一倍，且查詢性能穩(wěn)定
  • ORC格式性能優(yōu)化，查詢耗時減少5%
  • 分區(qū)裁剪優(yōu)化，解決指定分區(qū)但獲取所有分區(qū)元信息問題，減少了HMS的壓力
  • 下推優(yōu)化，實(shí)現(xiàn)了Limit、Filter、Project、Agg下推到存儲層

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

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

 

 

 
5.   
總結(jié)  
Presto在軟件的探索與實(shí)踐是怎樣的  

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


Presto在軟件的探索與實(shí)踐是怎樣的


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


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


Presto在軟件的探索與實(shí)踐是怎樣的




6. 
展望
Presto在軟件的探索與實(shí)踐是怎樣的
Presto主要應(yīng)用場景是Ad-Hoc查詢，所以其高峰期主要在白天，如下圖所示，是網(wǎng)約車業(yè)務(wù)下午12-16點(diǎn)的查詢，可以看到平均CPU使用率在40%以上。

Presto在軟件的探索與實(shí)踐是怎樣的

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


Presto在軟件的探索與實(shí)踐是怎樣的

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

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

向AI問一下細(xì)節(jié)

免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進(jìn)行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI
助
手