G行大數(shù)據(jù)應(yīng)用平臺批量調(diào)度優(yōu)化實踐
在金融行業(yè)數(shù)字化轉(zhuǎn)型浪潮中,海量數(shù)據(jù)的高效處理與批量任務(wù)的穩(wěn)定調(diào)度成為支撐銀行核心業(yè)務(wù)如客戶服務(wù)、風(fēng)險管控、監(jiān)管報送等的重要組成部分。為此,G行在開源DolphinScheduler(海豚調(diào)度)基礎(chǔ)上進行自主研發(fā),通過架構(gòu)重構(gòu)、功能優(yōu)化與本地化改造,打造了適配金融級生產(chǎn)要求的大數(shù)據(jù)批量調(diào)度系統(tǒng)。本文詳細介紹了G行大數(shù)據(jù)批量調(diào)度系統(tǒng)的落地實踐,為金融行業(yè)大數(shù)據(jù)調(diào)度系統(tǒng)的優(yōu)化升級提供可借鑒的實踐經(jīng)驗。
一、背景介紹
G行大數(shù)據(jù)應(yīng)用平臺自 2016 年 11 月投產(chǎn)上線后,為平臺上的應(yīng)用租戶提供海量數(shù)據(jù)存儲、計算和任務(wù)資源調(diào)度等技術(shù)組件服務(wù)。大數(shù)據(jù)批量任務(wù)具有數(shù)據(jù)規(guī)模大、執(zhí)行時間長、任務(wù)依賴復(fù)雜的特點,Oozie成為大數(shù)據(jù)平臺上線后的主要批量調(diào)度工具,實現(xiàn)了日均2萬多個批量任務(wù)的調(diào)度執(zhí)行。但Oozie在大規(guī)模任務(wù)并發(fā)場景下性能較差,可能出現(xiàn)死鎖或卡頓現(xiàn)象,而且無法支持動態(tài)擴縮容,任務(wù)開發(fā)和配置復(fù)雜,不支持補數(shù)、跨作業(yè)依賴、從指定任務(wù)節(jié)點重跑等復(fù)雜操作,頁面可視化管理能力較弱。
為了完善和豐富大數(shù)據(jù)批量調(diào)度功能,提升開發(fā)和運維管理效率,G行在開源DolphinScheduler(海豚調(diào)度)基礎(chǔ)上進行自主研發(fā),實現(xiàn)了國產(chǎn)化大數(shù)據(jù)應(yīng)用平臺的建設(shè)落地。
二、架構(gòu)設(shè)計
圖1. 大數(shù)據(jù)調(diào)度系統(tǒng)架構(gòu)設(shè)計
MasterServer
主要負責(zé)任務(wù)切分、任務(wù)提交、狀態(tài)監(jiān)控、任務(wù)容錯等,并同時監(jiān)聽其他MasterServer和WorkerServer的狀態(tài)。采用分布式無中心設(shè)計理念,每個節(jié)點都能同時工作。服務(wù)啟動時向Zookeeper注冊臨時節(jié)點,通過監(jiān)聽Zookeeper臨時節(jié)點變化來進行容錯處理。
WorkerServer
同樣采用分布式無中心設(shè)計理念,主要負責(zé)任務(wù)執(zhí)行、狀態(tài)反饋和日志服務(wù)。啟動時向Zookeeper注冊臨時節(jié)點,支持任務(wù)容錯。某個Worker節(jié)點異常時,其上的任務(wù)可容錯至其他正常Worker節(jié)點上執(zhí)行,對整個工作流任務(wù)無影響。
ApiServer
API接口層,主要負責(zé)前端UI層的請求,提供RESTful Api向外部提供請求服務(wù)。接口功能包括工作流的創(chuàng)建、定義、查詢、修改、發(fā)布、下線、手工啟動、停止、暫停、恢復(fù)、從當(dāng)前節(jié)點開始執(zhí)行等等。
AlertServer
提供告警服務(wù),支持通過告警插件形式實現(xiàn)豐富的任務(wù)監(jiān)控告警手段。
Zookeeper
MasterServer和WorkerServer節(jié)點均通過Zookeeper實現(xiàn)分布式服務(wù)管理和容錯,另外基于Zookeeper進行事件監(jiān)聽和分布式鎖實現(xiàn)。
EverSQL
元數(shù)據(jù)管理數(shù)據(jù)庫,記錄租戶賬號、工作節(jié)點、資源組、工作流配置、任務(wù)實例等信息。
基于去中心化的分布式架構(gòu),調(diào)度系統(tǒng)避免了單點故障風(fēng)險,支持動態(tài)水平擴展,保障了數(shù)萬至數(shù)十萬級任務(wù)并發(fā)調(diào)度,實現(xiàn)了系統(tǒng)的高可用性和可靠性。同時,靈活的多租戶管理和調(diào)度策略以及失敗自動重試等功能,保障了大數(shù)據(jù)平臺批量任務(wù)精細化管理和穩(wěn)定運行。
三、落地實踐
為了適配我行生產(chǎn)管理要求和批量運行特點,對海豚調(diào)度進行了一系列的部署改造和功能優(yōu)化。
1.多租戶部署改造
開源海豚調(diào)度多租戶的實現(xiàn)依賴于操作系統(tǒng)Linux用戶映射,每個租戶需綁定一個真實的Linux用戶。任務(wù)執(zhí)行時,WorkerServer通過sudo切換租戶用戶身份啟動子進程,確保進程級隔離。因此,為了實現(xiàn)租戶切換,WorkerServer啟動時需要以root或者是配置sudo權(quán)限的用戶啟動。在滿足要求的前提下,系統(tǒng)出現(xiàn)出現(xiàn)了維護難度大的問題;其次,sudoers在更新成默認配置后,會導(dǎo)致批量任務(wù)異常。
為了解決上述問題,制定了一種特殊的實現(xiàn)方案。改造了調(diào)度sudo切換用戶邏輯,每個租戶以其對應(yīng)的操作系統(tǒng)賬號啟動WorkerServer進程,結(jié)合Worker分組方式實現(xiàn)租戶選擇自身賬號啟動的Worker節(jié)點提交任務(wù)和執(zhí)行。同時改造了資源中心租戶文件路徑,通過Kerberos認證方式實現(xiàn)權(quán)限隔離。為了節(jié)省資源,每臺機器節(jié)點改造為可支持部署和啟動多個租戶的WorkerServer進程。同時,為了控制每個節(jié)點上的租戶資源消耗,租戶啟動WorkerServer時根據(jù)本地配置文件(dolpinscheduler.env)中計算資源、通信端口和任務(wù)并發(fā)等參數(shù)進行限制。每個租戶選取不同機柜的3臺機器節(jié)點部署啟動WorkerServer進程,滿足了單臺機器故障時的批量任務(wù)容錯。其他服務(wù)包括MasterServer、ApiServer、AlertServer、Zookeeper等仍以應(yīng)用Dolp賬號進行啟動和統(tǒng)一管理。
圖2. 多租戶WorkerServer部署模式
2.前端訪問控制
ApiServer服務(wù)提供了Web頁面供開發(fā)運維人員配置工作流/任務(wù)、檢查批量任務(wù)運行狀態(tài)、查看任務(wù)日志、對異常任務(wù)進行處置等。為了解決在非變更環(huán)境和時間內(nèi)通過Web頁面對生產(chǎn)環(huán)境進行操作的安全隱患,開發(fā)上線了一套只讀查詢頁面,在只讀查詢頁面只允許執(zhí)行查看類操作,任務(wù)編輯類、執(zhí)行類操作均被禁止。系統(tǒng)新建了一套只讀(readonly)租戶賬號體系,只讀頁面只允許只讀賬號登錄,且登錄后可查看當(dāng)前租戶正式賬號下創(chuàng)建的所有項目、資源組、工作流、批量任務(wù)等。只讀Web頁面與原Web頁面啟動不同的訪問端口,通過網(wǎng)絡(luò)策略限制,實現(xiàn)了對Web頁面的訪問控制。既滿足了管理員對批量任務(wù)進行巡檢查看的需求,同時控制了在非變更環(huán)境和時間內(nèi)對生產(chǎn)操作的風(fēng)險。
圖3. 海豚調(diào)度前端訪問控制
3.調(diào)度系統(tǒng)管理優(yōu)化
- 新增任務(wù)標簽功能
為了更清晰地對批量任務(wù)進行分類管理,增加了任務(wù)標簽屬性,制定了對客業(yè)務(wù)、數(shù)據(jù)入倉、監(jiān)管報送、內(nèi)部使用、普通任務(wù)5個標簽類型。實現(xiàn)了基于標簽的工作流篩選和統(tǒng)計功能,并且基于標簽制定了不同的告警策略,在批量告警消息中標識任務(wù)標簽,應(yīng)用一線和管理員接收到任務(wù)告警時可基于標簽屬性對任務(wù)影響范圍進行初步評估,后續(xù)也考慮基于標簽實現(xiàn)任務(wù)資源、優(yōu)先級配置與告警分級等功能。
- 新增批量化操作功能
為了便于批量化部署和管理工作流,開發(fā)實現(xiàn)了工作流批量化導(dǎo)入導(dǎo)出功能,提供了批量化部署、上線、下線能力和對應(yīng)的自動化工具,實現(xiàn)了大數(shù)據(jù)批量任務(wù)的自動化變更投產(chǎn),提升了租戶開發(fā)和部署效率。同時,為了應(yīng)對大量工作流或任務(wù)異常時的應(yīng)急處置場景,增加了批量化重跑、批量化停止、批量化上下線、批量化刪除等批量化操作功能,提升了平臺操作處置能力。
- 新增全局概覽下鉆功能
在生產(chǎn)環(huán)境進行調(diào)度版本升級、漏洞修復(fù)、功能完善等變更操作時,基于無中心化設(shè)計和容錯機制,理論上輪詢重啟進行應(yīng)用更新時,租戶批量任務(wù)都不受影響。但變更完成后,還需要整體檢查變更期間各租戶任務(wù)運行情況,如果輪詢檢查每個租戶所有項目下的批量任務(wù)不但耗時耗力,而且容易遺漏。因此,對全局概覽頁面進行了優(yōu)化,開發(fā)實現(xiàn)了在概覽頁面可直接查看并下鉆異常任務(wù)列表的功能。租戶管理員可下鉆跳轉(zhuǎn)到所屬租戶所有項目的異常任務(wù)列表,并可對異常任務(wù)進行處理。平臺管理員可查看所有租戶項目的異常任務(wù)明細,大大提升了調(diào)度系統(tǒng)變更后的巡檢效率。
圖4. 全局概覽下鉆功能
此外,我們還對其他部分功能進行了優(yōu)化,比如頁面刷新頻率、從異常任務(wù)節(jié)點執(zhí)行、審計日志輸出等,提升了平臺可用性和可靠性。同時,給租戶提供了基于接口的任務(wù)重調(diào)腳本,各租戶可在運維自動化操作平臺(EVEROP)配置應(yīng)急重調(diào)工具,實現(xiàn)在任務(wù)異常發(fā)生告警時基于告警關(guān)鍵字匹配應(yīng)急工具進行處置。
4.對接行內(nèi)告警平臺
監(jiān)控告警對于運維管理來說至關(guān)重要,為了及時發(fā)現(xiàn)批量執(zhí)行異常,所有批量任務(wù)都應(yīng)配置監(jiān)控告警。統(tǒng)一監(jiān)控管理平臺(UMP)是全行應(yīng)用系統(tǒng)的集中監(jiān)控和告警渠道。為了實現(xiàn)統(tǒng)一告警管理,開發(fā)改造了基于Syslog的告警插件接口,制定了統(tǒng)一告警策略和消息模板。租戶任務(wù)配置該告警插件接口后,在批量異常觸發(fā)告警時,AlertServer服務(wù)根據(jù)模板生成告警消息并推送至UMP后統(tǒng)一報出。UMP可根據(jù)消息中的業(yè)務(wù)系統(tǒng)關(guān)鍵字將告警分別通知到各租戶系統(tǒng)管理員。目前已經(jīng)實現(xiàn)的告警策略包括工作流與任務(wù)超時、失敗、阻塞、未正常調(diào)起等。
5.規(guī)范管理
為了便于租戶管理,調(diào)度系統(tǒng)在建設(shè)和推廣之初就重視規(guī)范和管理要求的制定,逐步完善了大數(shù)據(jù)批量調(diào)度開發(fā)和使用規(guī)范。其涵蓋了批量編排和命名、任務(wù)配置、任務(wù)依賴、批量告警、批量執(zhí)行、任務(wù)參數(shù)、報錯管理、數(shù)據(jù)清理等多個方面,對租戶的批量任務(wù)開發(fā)進行了統(tǒng)一規(guī)范和管理,進一步保障了平臺的可用性。
四、總結(jié)與展望
大數(shù)據(jù)平臺新調(diào)度系統(tǒng)上線后,基于租戶級別、業(yè)務(wù)屬性、批量任務(wù)影響范圍等制定了Oozie批量調(diào)度分批次遷移方案。截至目前,已經(jīng)實現(xiàn)了數(shù)十個租戶日均接近25000工作流,88000多個大數(shù)據(jù)批量任務(wù)的調(diào)度執(zhí)行。后續(xù)將持續(xù)推進和完善大數(shù)據(jù)批量運行分析、補充完善監(jiān)控能力、合理調(diào)度計算資源實現(xiàn)“削峰填谷”,進一步提升大數(shù)據(jù)批量調(diào)度管理水平。

作者:郭濤
多年大數(shù)據(jù)平臺運維經(jīng)驗,目前主要負責(zé)大數(shù)據(jù)平臺湖倉系統(tǒng)和調(diào)度平臺應(yīng)用運維相關(guān)工作。

編輯:趙孖同
愛好滑雪、養(yǎng)貓,負責(zé)金融市場類系統(tǒng)的運維工作,作為編輯,也將持續(xù)為大家輸出優(yōu)秀文章,敬請期待。






























