Presto在軟件的探索與實踐是怎樣的

發布時間：2021-12-27 15:35:55 來源：億速云閱讀：192 作者：柒染欄目：大數據

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

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控制
無容錯

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數量來區分查詢大小，架構圖見：

引擎迭代

我們從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

引擎改進

在滴滴內部，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

總結

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

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

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

Presto在軟件的探索與實踐是怎樣的

展望

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

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

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

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

向AI問一下細節

中文字幕av专区_日韩电影在线播放_精品国产精品久久一区免费式_av在线免费观看网站

Presto在軟件的探索與實踐是怎樣的

猜你喜歡

中文字幕av专区_日韩电影在线播放_精品国产精品久久一区免费式_av在线免费观看网站

Presto在軟件的探索與實踐是怎樣的

猜你喜歡

最新資訊

相關推薦

相關標簽