本文作者：車好多大數據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
Java與大數據架構
7年老碼農，10W+關注者。【Java與大數據架構】全面分享Java編程、Spark、Flink、Kafka、Elasticsearch、數據湖等乾貨。歡迎掃碼關注！
