presto的動態化應用(一):presto節點的橫向擴展與伸縮

一、presto動態化概述

　　近年來,基於hadoop的sql框架層出不窮,presto也是其中的一員.從2012年發展至今,依然保持年輕的活力(版本迭代依然很快),presto的相關介紹,我們就不贅述了,相信看官多對presto有或多或少的了解,詳細的一些說明可以看官網(https://prestodb.io)的說明.

　　presto自身功能和思想富有先進性,雖然由於是內存計算,穩定性方面還有很大提升空間,但整體依然在adhoc方面有很好的競爭力,我們本次介紹針對我們團隊對於presto部分應用個性化定制功能的闡述,如果設計不合理或有待改進的方面,請大家多多反饋,我們共同進步.

　　由於我們團隊是圍繞着hadoop相關項目進行,對於大數據的即席查詢的需求是無可避免,最終選用presto和impala兩款即席查詢工具.一款新的開源工具從測試到生產環境,除了必要的覆蓋測試,還要自動部署, 監控, 預警 , 日志分析 , 異常處理等等功能,還有一些來源業務部門的需求進行調整及改進(主要針對sql和易用性,性能改進,可后續其他系列文章進行說明).

我們針對presto動態開發,主要體現於三個方面:

• presto節點的橫向擴展與伸縮(動態資源)

• presto的配置動態化(消除presto本地配置)

• presto動態加載更新插件(不停服務情況下,自動增加或升級插件)

二、資源動態化:充分利用集群資源,混搭才是王道

presto從上線到切入業務,一直在獨立hadoop集群中,遵從不搶占線上集群資源,不影響線上核心任務的原則,但是遷入presto的業務方日漸增多,T-1的跨機群將數據拷貝至獨立presto集群方式已然無法滿足,我們做出大膽的決定,便是將presto遷入線上集群直接使用,於是我們必須能夠對presto的資源管理有完善的把控和管理.

PrestoSchedule1.0功能點:

    1.presto on yarn

    2.presto Server(白天100%節點,晚上5%節點)

    3.presto 監控預警系統

    4.presto 權限管理

    5.presto 動態插件管理

    6.presto 分流管理

    7.presto 自動升級(用戶無感知,保證task無失敗)

三、PrestoSchedule1.0模塊

1.Presto Server

　　prestoServer 是PrestoSchedule獨立部署模塊.是包括管理界面,監控,權限管理等功能,提供了自主運維管理后台，讓管理員能通過頁面來配置、啟停和管理presto集群, 同時管理presto master與work的節點數，監控每個節點運行信息,從節點啟動-運行-消亡-刪除啟動包痕跡都有詳細記錄，管理員可以定制work的啟動時間和停止時間, 同時能夠看到每次啟動耗時和結束耗時以及能看到執行成功或者失敗，還會為保留過去的work的記錄，可以查看定時歷史啟動記錄.

　　除此之外,prestoServer 還兼有管理多集群映射的職責(為presto性能考慮,盡量讓presto使用hadoop block減少網絡傳輸,我們在每個hadoop集群都部署一套對應的presto服務),讓sql用戶對於訪問集群無任何感知,屏蔽具體master的地址,對master的遷移和 on yarn提供基礎支撐.

• 權限,屏蔽連接master的直接訪問,同時對於presto訪問者細粒度到人,對於非內部人員或非授權人員禁止訪問,管控presto程序訪問入口如客戶端,jdbc,restful等方式

• presto代理,甄別多個presto集群的所有入口方式及權限,用戶無感知的使用presto, 使presto master完全進入黑盒子,便於動態遷移master, 新建presto集群,客戶端無需感知或受到影響

• 分流,監控presto master壓力,可將一部分查詢流量實時切換到另一presto master,同時支持presto新開發功能的灰色發布及線上自測

• 運維管理,支持新建,啟停presto集群,管理presto work的節點數,可以通過頁面修改當前的presto work數量,及交互資源(將切換masterA的work轉換為masterB的work).

• 監控,包括presto sql分析,presto監控情況, JMX監控, presto隊列情況, presto自恢復機制.

2.presto on yarn

　　混搭性集群充分利用集群資源,一直是我們深入研究的主題,對於離線任務與實時任務,導數任務與計算任務應該各司其職,充分榨干集群每一寸土地,當然,這是理想的情況,presto on yarn是我們對於在離線集群進行長時間運行(long server)的服務的一次嘗試.

　　因我們有on yarn需求時,社區的presto-yarn項目(https://github.com/prestodb/presto-yarn)才是初版,Slider也不是很成熟,測試過程中也很多不滿足我們需求的地方,於是我們便開發presto on yarn的項目.

　　為了更好的融入混搭集群的方向, 我們需要解決如下幾個問題:

資源:

    1.利用空閑的資源

    2.不能搶占核心任務的資源

    3.不能影響其他任務的運行

穩定性:

    1.保證presto在yarn上的穩定性

    2.保證presto master和work的數量

    3.保證用戶查詢不因平台框架原因查詢失敗

可伸縮性:

    1.保證隨時可擴展,可縮減的可操作性

易部署:

    1.web頁面一鍵部署,一鍵啟停

    2.兼容運行環境(JDK版本)問題.

權限控制:

    1.表權限級別控制,與公司hadoop/hive權限驗證打通(公司內部erp權限管理,請看hadoop erp權限管理)

定時性:

    1.保證白天100%資源運行,夜間5%資源運行

　　針對以上的問題,我們進行分解,針對問題進行對應涉及工作,其中思路與alluxio on yarn類似, 資源可以使用linux container 與 docker container 進行資源隔離.

　　穩定性則可以增加AM 作為管理節點及ETCD注冊, 通過thrift接收外部請求,增加或減少資源,同時AM與APP又受到prestoServer管理,即便APP或AM失敗或者被意外kill,也可以重啟任務或監聽重試.

　　可伸縮性,通過請求AM執行容器的創建及銷毀工作,同時,對異常關閉(NodeManger異常關閉)的容器進程依然存在, AM定期向presto Master發送反向關閉無效work服務指令,Presto Master對於不在容器內的存活presto work發送關閉命令, presto work執行exit, 反向關閉presto work進程(需要增加presto API).

　　易部署,使用on yarn的方式,比較方便的便是部署,能夠達到一鍵部署的特征,但是隨即而來的便是容器環境問題, hadoop JDK版本多為1.6,1.7, 並沒有使用JDK1.8, 但是presto對於JDK1.8是強依賴, 我們解決方式有兩種,其一是使用docker container(公司內部hadoop已支持多種容器模式共存,通過參數選擇container 類型) ,方案二,我們presto是支持動態插件功能,其中動態插件管理可選擇是否包含JDK啟動,原理是將JDK及備用jar放置HDFS中,通過外部配置(系列二的配置管理系統)決定, 是使用localjdk,還是使用遠程jdk(如使用遠程,依然會對比本地JDK版本以及是否曾經已下載進行復用),然后啟動presto服務.

　　權限控制,除了與公司的權限管理系統貫通並兼容,presto server也作為所有用戶訪問presto的入口, 對於用戶並不知道訪問的具體hadoop集群或presto集群,將用戶sql訪問與presto技術實現松和耦合,我們隨時可以將用戶sql切換到其他平台中運行,如spark sql, hive, impala等.

　　定時性,自動化伸縮節點是初期最重要的功能之一, presto性質決定他的用戶多為白天, hive的跑批腳本多為在凌晨開始,早晨結束,故此兩者時間上可以進行互補,技術實現相對簡單, 僅僅定時器觸發AM的thrift接口發送伸縮命令即可.

3.presto 服務發現

　　服務發現現今使用的是etcd進行,原本有計划將presto的發現服務,轉移到ETCD中,但開發計划一直未能展開,故此使得兩個發現服務互補使用.(臨時方案)

服務發現:

• presto集群信息

• yarn APP/AM 信息

• hadoop配置信息

• catalog版本信息

• catalog配置

• presto config信息

• presto 插件版本信息

• on yarn配置信息

4.presto IDE

　　presto的快速查詢使用方式則是多種多樣, 我們支持presto client, SQL IDE(公司內部web開發工具) JDBC, ODBC, restful接口方式等方式進行sql的查詢工作,從而保證業務方在任何條件下都可以訪問.

四、文章說明

　　本文出自本人的一個同事涵總之手，今天在本人的博客上曬一下！