Presto在車好多的實踐

本文作者：車好多大資料OLAP團隊-王培

Presto 簡介

1.簡介

Presto 最初是由 Facebook 開發的一個分布式 SQL 執行引擎， 它被設計為用來專門進行高速、實時的資料分析，以彌補 Hive 在速度和對接多種資料源上的短板，發展歷史如下：

?2012年秋季，Facebook啟動Presto專案?2013年冬季，Presto開源?2017年11月，11888 commits，203 releases，198 contributors?2019年1月，Presto分家，目前有PrestoDB和PrestoSQL兩個社區

2.架構

Presto 是典型的 MPP 架構，由一個 Coordinator 和多個 Worker 組成，其中 Coordinator 負責 SQL 的決議和調度，Worker 負責任務的具體執行，可配置多個不同型別的 Catalog，實作對多個資料源的訪問，

Presto 在車好多的落地

Presto 大概在 2017 年底 2018 年初左右開始在車好多落地使用，主要是為滿足集團的 Adhoc 查詢和報表而服務，落地三年左右，經過了數次的版本升級和一次大的架構升級，迭代如下：

目前有專門提供 Ahoc 查詢的大集群，以及一些業務專有小集群相互配合提供服務，滿足集團不同 SLA 的查詢需求，總體使用情況：

1.初期落地

初期選擇的版本是 0.153，當時根據情況有以下幾個需求：

?隱藏 Coordinator 真實地址

?接入有規范或者管控

?簡化管理員運維

開源社區版本直接暴露 Coordinator 地址給客戶端提供服務，重啟 Coordinator 會 Fail Query，為了滿足以上需求，我們實作了以下關鍵功能點：

?客戶端和服務端之間加一層代理

代理層的作用不僅隱藏了 Coordinator 真實地址，而且可以根據需求設定一些客戶端接入規范，以便能區分接入方式/型別等，我們還在代理層附加了下面兩個主要功能：在每一個 Query 結束時，會記錄其所有資訊并發送到 Kafka，最終落入到 Hive，即日志審計，方便管理員后續分析/治理；監控一些 Query 指標，在超出閾值時主動 kill Query，提高集群穩定性，

?發現服務單獨部署

發現服務沒有采用內嵌在 Coordinator 中的方式，而是采用單獨部署方式，不僅有助于代理層靈活的獲取集群地址，不會受限于某個 Coordinator，而且在管理員運維時發揮很大的作用：在集群中啟動第二個 Coordinator 角色，代理層會自動把流量切換到新啟動的 Coordinator，待舊 Coordinator 原有的 Query 運行結束再切換回來，達到用戶無感知重啟 Coordinator 的目的，再加上本身 Worker 節點 支持優雅下線，那么整個集群的無感知運維就可以輕松實作，為管理員運維帶來極大的便利，

整體架構大致如下：

根據實際的場景需求，除了 Hive 之外，Mysql 是接入最多的資料源，后續又接入了 Kudu（版本升級后才接入）、Mongo、PostgreSQL 等資料源，方便用戶利用 Presto 進行跨資料源的關聯查詢，這也是我們當時選擇 Presto 組件的主要原因，

一開始采用了和 Hadoop 集群混合部署的模式，但是考慮到資源競爭，很快切換到物理機單獨部署：

? Coordinator 節點不作為計算節點，只作為協調節點；

? 每臺物理機只部署一個 Presto 節點，無其他任何競爭服務；

? JVM 配置為 G1 回收器、最大堆記憶體為物理記憶體的 75%；

以為 Presto 集群的穩定性會大大提高，但是服務上線后，我們就遇到了一個不小的挑戰：服務經常 OOM，很不穩定，經過調研，我們采取以下措施來優化 OOM 問題：

? 設定堆外記憶體最大使用量 MaxDirectMemorySize

? 設定 glibc 的引數 export MALLOC_ARENA_MAX=1

通過以上主要優化，我們 Presto 集群的記憶體使用值常年比較平穩，OOM 問題大大緩解，

2.中期迭代

經過初期的穩定階段以后，為了跟進社區，開始著手做版本升級的事情，基于單獨部署的發現服務和代理層切換流量的功能以及客戶端的向后兼容，我們成功實作了用戶無感知升級，

? Gracefully 停掉一半 Worker

? 升級一半 Worker 到新版本

? 啟動一個新版本的 Coordinator

? 等待老版本 Coordinator 查詢執行完成

? 關閉老版本 Coordinator 以及剩余老版本 worker

? 升級剩余 Worker 到新版本

在上述的方案中，重啟 Coordinator 或者升級版本的程序，會出現一個集群中同時存在多個 Coordinator 的情況，日志會出現 com.facebook.presto.execution.SqlTaskManager Switching coordinator affinity from xxx to yyy 類似的警告,這種狀況長時間內是有資源調度死鎖風險的，然而在我們的狀況中，不論是重啟還是升級都是在短時間內（分鐘級別），所以穩定性還是可以保證的，隨著用戶和任務的增多，Presto 在車好多作為 Adhoc 查詢引擎慢慢流行開來，但隨之幾個核心問題暴露出來：

2.1 無權限管控

背景

Presto 接入的底層資料源種類多，而且資料量大，覆寫車好多集團相當一部分業務線的業務資料，沒有權限管控的機制，任何一個用戶都可以通過 Presto 訪問底層資料源的全部資料，這對資料安全來說是一個很大的隱患，

解決方案&效果

由于底層對接的資料源種類不統一，比如 Hive、Mysql、Mongo 等，在資料源層做權限當時有以下幾方面限制：

? 資料源層面，有些資料源開啟權限驗證，而有些沒有開啟；

? 不同型別資料源支持權限的策略不一樣，無法統一；

? 在 Presto 里不是所有的 Connector 都支持 Impersonate[1]；

? 基于以上限制，最快速、最適合的方案就是在代理層做權限管控的邏輯，

? 改造 Presto 不同型別（cli、jdbc、python、go 等）的客戶端，支持公司內部賬號體系，完成認證程序；

? 基于公司權限/流程系統，改造一套適合 Presto 的權限管理系統；

? 在代理層實作鑒權邏輯；

這個權限管理方案實作簡單，落地后比較符合公司的使用需求和場景，結合代理層的日志審計功能，這樣管理員對 Presto 集群的所有用戶以及 Query 執行情況都有了全面詳細的了解，這個為后續的任務治理提供了非常寶貴的資料支持，

2.2 新增 Catalog 頻繁，運維壓力大

背景

車好多集團關于車有多個業務線，比如收車、賣車、車后、金融等方面，每個業務線都有自己的業務資料，有些時候需要跨業務線的OLTP資料庫（Mysql，Mongo、PostgreSQL等的只讀從庫）進行關聯查詢，需要新增對應的 Catalog，Presto 對于新增 Catalog 是需要重啟集群的，所以這對于管理員來說有很大的運維壓力，

當然從長遠來看，還是要將多資料源統一入Hive，有HiveMetaStore服務統一管理所有元資料，運維和管理都會方便很多，

解決方案&效果

我們修改了部分原始碼，Presto-Server 對外提供 Restful 介面可在線添加新的 Catalog，對于更新和洗掉 Catalog 的情況，比較低頻，為了穩定，還是采用重啟集群的方式，這個功能的實作大大減輕了管理員的運維壓力，也減少了上線帶來的穩定性風險，

2.3 棘手的排隊問題出現

背景

經過了一年多的迭代，Presto 在車好多集團內部成為了提供 Adhoc 查詢的核心組件，數十個業務線的數百名用戶都重度依賴 Presto 來實作他們的分析需求或者報表結果，基本上集群每天有 600+用戶（資料分析師、運營、市場、產品等），高峰期每秒提交數目最大能達到百級別，在這樣的一個情況下，高峰期任務排隊的情況就會出現并且越來越嚴重，嚴重影響了用戶的使用體驗，

解決方案&效果

首先的想到的是任務治理

? 大查詢限制：導致集群排隊的主要原因是大查詢（耗費計算資源多的 Query）長時間占用集群資源不釋放，集群最大運行 Query 數目被打滿，后續提交的 Query 只能排隊，為了限制大查詢，我們下調單個 Query 的最大運行時間、最大掃描磁區數目、記憶體使用最大值、stage 數目等，讓集群資源快速流轉起來；

? 單個用戶 Query 數目限制：我們下調單個用戶的最大運行數目以及最大排隊數目，防止單個用戶提交過多查詢占滿集群資源，其他用戶沒有機會提交；

? 優化 SQL：我們根據一些規則，給出 SQL 優化的建議，比如：避免笛卡爾積、distinct 濫用、非等值 join 等情況，并推動用戶優化 SQL；

? 推動上層 BI 工具快取結果：為了方便用戶使用，有一些 BI 工具來對接 Presto，有多個用戶會查看同一張報表，基于這樣的情況，沒有必要每次查看都要發起一次查詢，工具層快取這個結果，對底層 Presto 的壓力會大大緩解；

? 推動中間表的建設，優化查源表的情況，減少計算資源的浪費；

? 每周統計出各個部門的資源使用賬單&資源消耗排名 Top N 的用戶，并通知，這是推動用戶優化任務重要的資料來源；

其次，增加資源，這也是必然要嘗試的一個方法，然而由于一些客觀原因，比如：成本、機房初始容量規劃等，無法給集群進行提供充足的資源，只能小規模有限擴容，

通過以上兩個方面的優化，尤其是任務治理，排隊情況得到緩解，然而總會有一些新用戶會提交一些不合理的任務，因此任務治理是一項長期持續的作業，資源方面，沒有條件新增，那么就只能在存量資源上想辦法，

3.Presto 在車好多的架構升級

3.1 彈性Presto 方案（Presto on YARN）

我們調研彈性Presto方案主要基于以下2點：

? 中期任務治理后，排隊問題依然嚴重，希望有更多的資源能提供給Presto，但由于Adhoc查詢場景的特殊性，白天資源利用率高，晚上這部分資源又會閑置；

? 一鍵快速的拉起、洗掉集群，以及一鍵快速的擴容、縮容能力，對管理員來說是剛需，能極大提高管理員的作業效率；

在當前大資料架構的概覽下，我們發現 Hadoop 中 YARN 集群的夜間批處理任務和 Presto 集群白天的查詢任務是完全錯峰的，有典型的潮汐現象，

所以我們開始考慮 Presto on YARN 的彈性技術方案，總體來說，收益很多，總結如下：

? 可以為用戶快速搭建專有集群，達到資源隔離，提升服務質量的效果；

? Presto 集群可以利用 YARN 集群白天空閑的資源，大大緩解資源緊張的問題；

? YARN集群也能利用晚上Presto閑置的資源來擴充批處理任務的資源

? 大資料整體機器全天的資源利用率會大大提高，節省成本；

由于 Hadoop 集群整體版本是 2.7.x，經過調研，需要使用 Slider 這個已經組件來實作 Presto on YARN，總體來說調研程序比較順利，由于 Slider 專案已經不維護，資料相對較少，程序中請教了吳彪前輩一些問題，這里衷心感謝！

Presto on YARN 方案有以下注意點：

? 如果 YARN 集群不支持 label 功能，可以采用動態埠的方式解決單個 NodeManager 上調度多個 PrestoServer 節點的埠沖突問題；

? YARN集群要開啟CGroup，否則CPU、MEM不受控制；

? appConfig 中可設定"site.global.data_dir": "${AGENT_LOG_ROOT}"來 解決一臺 NodeManager 上兩個 PrestoServer 目錄沖突的問題；

? 單個 PrestoServer 的資源受限于 YARN 集群中 Container 最大資源的限制；

在使用程序我們也發現了一些 Slider 的問題：

? 某些情況下節點短時間無法自動拉起，在佇列資源比較緊張的情況下，節點會因資源被搶占而被 kill，Slider 會把當前 NodeManager 加進黑名單，如果重試次數足夠多直到把所有 NodeManager 都遍歷一遍，那么所有 NodeManager 都會被 Slider 加進黑名單，雖然黑名單有超時機制，但是在黑名單失效前節點是無法被拉起的，

? Slider 把 YARN 的優先級和節點親和性揉在一起，造成重啟后實際節點優先級倒置；

? Slider 上報給 YARN 的應用診斷資訊過長，可能導致無法寫入 zk，將 RM 阻塞在 zk 寫操作，最終搞掛 RM；

將以上問題都解決以后，Presto on YARN 的方案達到了可用、穩定的狀態，

3.2 代理層 Presto-gateway

有了 Presto on YARN 方案以后，結合 Presto 集群晚間有一些定時任務、架構演進穩定性以及后續規劃的考量，考慮采用 物理和 on YARN 的多集群模式來改善資源狀況，如果采用多集群的架構，有一個重要的點需要考慮：Presto中，一個Query執行周期內需要客戶端和服務端進行多次的HTTP請求，在多集群模式下，如何保證同一個Query的請求都分發到同一個集群呢？

針對上述問題，經過調研，發現普通現有的Nginx演算法比如IP Hash[2]等無法滿足需求，還是需要在代理層進行改造，這個代理層需要滿足以下功能：

? 保存每個Query和后端集群地址映射狀態；

? 任務分發；

? 靈活控制每個集群的激活狀態；

調研程序中發現有個開源的Presto-gateway[3]專門做了上述的事情，從前面的架構已經知道，我們有一個現成的代理層，但是現有代理層沒有覆寫上述功能，經過作業量、架構擴展性等方面的評估，決定用Presto-gateway替換自研代理層，并做一些落地改造：

? 原有代理層權限、監控相關功能的添加；

? 每個查詢和后端集群地址的映射關系由原來的 Guava Cache 修改到 Redis 中，Presto-gateway 徹底無狀態，可多實體部署保證 HA；

? 增加后端探活功能，檢測某個集群功能例外，從分發串列中移除；

? 增加分發策略，在原來的隨機策略基礎上增加了平滑加權輪詢、指標動態策略；

后續也會考慮把一些公共的功能，比如多實體HA、探活、分發策略等回饋給Presto-gateway社區

3.3 多集群部署

多集群方案全部準備好以后，我們首先為一些需要專屬集群保障 Query 不受其他查詢影響的用戶試用這個方案，經過試用以后，這些用戶反饋良好，開始著手改造公司的大Adhoc集群，采用了原有物理集群和 Presto on YARN 新集群同時提供服務的模式，其中 Presto on YARN 集群只在白天提供服務，晚上下線為批處理任務讓出資源，結構如下：

上述架構目前已經穩定上線運行，白天集群排隊情況大大緩解，用戶體驗也大大提高，后續會逐漸 All in Presto on YARN，把物理機集群的資源添加到 YARN 中，

總結與展望

Presto 在車好多落地將近 3 年的時間，期間對于原始碼的改造一直保持克制謹慎的態度，主要基于升級方面的考量，經過 Presto on YARN 架構升級，Presto 組件資源有了很大的靈活性，也具備了快速部署獨立集群提供高 SLA 服務的能力，讓 Presto 在車好多更好的發揮作用，

未來將從以下方面繼續推進 Presto 的建設：

? 版本升級到 PrestoSQL，近期底層 HDFS 已經升級到 3.X 版本[4]，會根據情況開啟 EC 功能，作為上層計算組件，Presto 需支持讀 EC；

? 根據資源指標實時對 Presto on YARN 集群動態擴縮容，資源管理將更加精細，用戶體驗也會大大提高；

? Presto on Hudi 等新技術的探索，為引入資料湖技術做儲備；

? 有機會的話，針對特定需求范疇場景的BI，用Presto on Alluxio加速；

References:

[1] https://docs.starburstdata.com/latest/connector/starburst-connectors.html

[2] https://www.nginx.com/products/nginx/load-balancing

[3] https://github.com/lyft/presto-gateway

[4] HDFS 2.x 升級 3.x 在車好多的實踐

Java與大資料架構

7年老碼農，10W+關注者，【Java與大資料架構】全面分享Java編程、Spark、Flink、Kafka、Elasticsearch、資料湖等干貨，歡迎掃碼關注！