一、調度系統(tǒng)簡介

Buffalo調度是一款京東自主研發(fā)的分布式DAG作業(yè)調度系統(tǒng)。為京東的數(shù)據(jù)開發(fā)工程師、算法工程師、數(shù)據(jù)分析師等用戶提供了離線作業(yè)的編排&調試、監(jiān)控運維、DAG調度等系統(tǒng)能力，致力于打造行業(yè)領先的穩(wěn)定高效、產品簡潔高體驗、任務監(jiān)控全面、資源容器化、系統(tǒng)能力開放化的ETL調度系統(tǒng)。

在京東調度系統(tǒng)核心面臨的挑戰(zhàn)有以下幾個：

1.業(yè)務復雜帶來的依賴關系復雜：復雜的數(shù)據(jù)鏈路，使得部分任務有數(shù)百、甚至上千個上下游，層級多達數(shù)十層?？缣煲蕾?、數(shù)據(jù)回刷、月度匯總等業(yè)務場景，需任務間依賴存在大小周期依賴、跨天依賴等復雜場景，任務依賴關系數(shù)據(jù)構成一個龐大且復雜的有向無環(huán)圖。

2.業(yè)務體量大且穩(wěn)定性&性能要求高：目前平臺有數(shù)十萬任務，百萬+依賴關系，日均百萬+調度頻次，不僅關系復雜、執(zhí)行量大，且系統(tǒng)的任何細微異常，都可能導致數(shù)據(jù)鏈路異常，核心數(shù)據(jù)受損，這對調度系統(tǒng)的穩(wěn)定性和性能帶來了不小挑戰(zhàn)。

3.數(shù)據(jù)加工場景復雜需支撐豐富調度能力：支持集團多個BG業(yè)務，業(yè)務場景多樣，涉及數(shù)據(jù)采集、數(shù)據(jù)計算、數(shù)據(jù)推送、數(shù)據(jù)轉換等多種任務類型、多種執(zhí)行方式、多種觸發(fā)規(guī)則，以及控制節(jié)點、任務間的數(shù)據(jù)傳遞、數(shù)據(jù)補錄場景等，對系統(tǒng)功能的豐富度和靈活度提出新要求。

二、核心技術方案

為支撐靈活的業(yè)務加工和工作流編排場景，快速的業(yè)務發(fā)展帶來的任務量增長，以及保障整個系統(tǒng)的穩(wěn)定性，我們從易用性、穩(wěn)定性、以及高性能等方面做了很多的思考和優(yōu)化，下面我將著重從這三個方面詳細介紹。

1. 實體和編排調度模型

a) 雙層實體模型

采用主流的雙層實體模型，雙層實體模型中，包含兩個核心概念：

?Action（環(huán)節(jié)）：環(huán)節(jié)是最小粒度的執(zhí)行單位，攜帶執(zhí)行相關的信息，如腳本、參數(shù)、環(huán)境等。

?Task（任務）：任務是由一個或多個環(huán)節(jié)+觸發(fā)規(guī)則構成的DAG，Task和Task之間也可以相互依賴，在外層構成一個DAG，實現(xiàn)雙層調度。

相比單層實體模型，編排能力更強，有更好的靈活性，同時對于單個業(yè)務的整合打包和管理也更友好。

b) 基于實例的調度

任務定義是任務配置的載體，無狀態(tài)，不可執(zhí)行，任務當?shù)竭_運行周期時，會產生相應周期的任務實例（產生實例的過程叫“實例化”），實例化時會根據(jù)任務的配置信息，包括：環(huán)節(jié)、上游依賴、數(shù)據(jù)依賴、運行周期等，生成當前周期實例，可理解為任務的一個快照，任務實例是真正可執(zhí)行、并具有狀態(tài)的對象。

基于實例的調度模式，其優(yōu)點在于：

?周期穩(wěn)定：任務的每個周期都會有實例，不會出現(xiàn)周期缺失的情況，且每個周期的實例可獨立操作

?依賴明確：任務某個周期的實例，其對上游任務實例的依賴，或者數(shù)據(jù)依賴是明確的、可預期的，同時對某個周期的數(shù)據(jù)可從整個鏈路上快速追溯，并在產生問題是可從鏈路層面快速修復。

c) 分類分級調度能力

平臺中的任務不通業(yè)務，重要性存在一定差異，為提升核心任務的保障能力，平臺提供任務分類分級管理，和基于分級的調度能力，在客戶端資源較為緊張時，會優(yōu)先保障重要業(yè)務。同時任務等級信息會透傳到底層集群，在底層計算集群層面也增加相應基于分類和等級的保障策略，保障核心業(yè)務的穩(wěn)定性。

2. 高可用架構

buffalo整體有分三層，每一層都具備高可用架構，使得整體具備高可用和容災能力

?a) Manager管理層：

?主要提供產品化管理能力，包括任務的創(chuàng)建、任務管理、任務運維等，管理端無狀態(tài)，可橫向擴展，負載對外提供服務

?b) 高可用Scheduler：

?也叫NameNode是Buffalo核心調度引擎，負責任務實例的周期生成，以及基于DAG的雙層任務實例的調度、客戶端資源的調度（物理資源、彈性資源）、任務狀態(tài)的處理等。

?整體采用多活+主備高可用架構，多個scheduler會通過數(shù)據(jù)分片負載處理任務，同時對于任務狀態(tài)消息進行冪等處理，其中資源調度模塊采用主備模式，以便支撐靈活和高效的資源調度能力。當一個節(jié)點故障時，其他節(jié)點會監(jiān)測到節(jié)點下線，并自動觸發(fā)接管邏輯，將異常節(jié)點任務接管處理，保障故障節(jié)點上的任務執(zhí)行不受影響。

?c) 容錯執(zhí)行層：

?執(zhí)行層的核心職責是負責任務啟動執(zhí)行，并監(jiān)聽任務執(zhí)行結果、采集任務日志、上報任務狀態(tài)，執(zhí)行層支持物理機和基于k8s的容器化資源兩種模式。

?物理機：部署worker（也稱TaskNode）長進程，任務以獨立進程方式運行，多個worker構成節(jié)點組對（虛擬節(jié)點）外服務，避免單點故障問題。同時worker本身支持消息重傳、cgroup資源隔離等高可用特性。

?k8s彈性資源：與原生k8s對接，任務以短周期pod方式執(zhí)行，任務結束時pod銷毀，天然具備高可用特性，同時具備更精細化的資源管理、差異化執(zhí)行環(huán)境的動態(tài)構建能力。

3. 高性能

前面提到調度系統(tǒng)中隨著任務量的增長，業(yè)務復雜度的提升，需要調度執(zhí)行的DAG實例梳理，以及DAG的復雜度都會不斷提升，buffalo主要從以下幾個方面來做到高容量、低延遲的編排和調度。

1) 水平擴展

如上高可用架構部分介紹，調度引擎采用多活架構，可水平擴展，不同服務之間通過數(shù)據(jù)哈希分片，將任務負載分布到多臺服務進行調度，同時各服務通過執(zhí)行批次和狀態(tài)進行冪等處理，保障任務執(zhí)行的唯一性。

2) 事件驅動

a. 定時輪詢（如左圖）

傳統(tǒng)的任務執(zhí)行方式大多采用定時輪詢的方式，這種方式需要定時查詢所有待執(zhí)行的任務實例，然后逐一校驗任務實例的依賴條件是否滿足（如任務依賴、數(shù)據(jù)依賴、并發(fā)限制等），這種方式在面臨大數(shù)據(jù)量任務時，有幾個核心問題：

?遍歷耗時：系統(tǒng)中可能有非常多的任務待執(zhí)行（有些滿足條件、有些不滿足條件），這樣每次獲取的任務列表會非常長（可能數(shù)十萬或百萬），這樣遍歷一遍非常耗時

?大量無用計算：在這些獲取的任務列表中，每個任務都需要進行多種條件校驗，且只有少數(shù)任務是滿足執(zhí)行條件，絕大部分的校驗是無用校驗

b. 基于事件驅動（如右圖）

相比定時輪詢，事件驅動不會采用定時拉取、全量校驗的方式，而是在任務所依賴條件的狀態(tài)發(fā)生變更時，才會基于事件做出相應的條件計算和校驗動作，這樣可以有效避免定時輪詢面臨的兩個核心問題。同時針對不同的事件類型，可以分別進行異步并行處理，有效提升整體的處理性能。

3) 內存調度

前面提到Buffalo具備在物理機集群和k8s集群上啟動任務執(zhí)行的能力，所以需要具備這兩種資源的管理和資源調度能力，資源調度的性能也是影響任務分發(fā)時效的關鍵部分。

調度引擎namenode采用的是多活的高可用架構，如果資源調度部分也采用該架構（如左圖），那么涉及到同一資源的并發(fā)訪問和修改的問題，進而引入分布式鎖和外部存儲，這樣整體的性能很難達到理想的目標。

因此，我們在namenode多活架構的基礎上，將資源調度部分做了一個主備架構的處理（如右圖），會從多個namenode里選擇一個作為主資源調度器，其他作為熱備，所有namenode的任務資源請求都由主節(jié)點進行處理，這樣主節(jié)點在內存中保存了所有的資源信息，資源調度過程在內存中就可進行，避免了分布式鎖和對外部存儲的依賴，性能有大幅提升。

4) 冷熱數(shù)據(jù)分離

當系統(tǒng)中任務量較大，任務執(zhí)行產生的實例數(shù)據(jù)會快速增長，當前buffalo每日的實例數(shù)據(jù)增量接近百萬，隨著任務量的增長還會持續(xù)增長，如果沒有適當?shù)姆桨竵硖幚?，?shù)據(jù)庫很難支撐如此快速的數(shù)據(jù)增長。

調度系統(tǒng)中的任務有個明顯特征 -定時，就是任務會定時執(zhí)行，執(zhí)行完成后的實例，除人為干預外其狀態(tài)不會再自動發(fā)生變更，這部分數(shù)據(jù)一般只會做查詢，所以這部分數(shù)據(jù)可以做獨立存儲。我們將狀態(tài)還會發(fā)生變更或頻繁操作的數(shù)據(jù)稱作熱數(shù)據(jù)，將這些已經執(zhí)行結束且基本只有查詢需求的數(shù)據(jù)稱作冷數(shù)據(jù)，并將冷數(shù)據(jù)單獨存儲。

當冷熱數(shù)據(jù)分離后，有三個核心問題需要解決：

1）數(shù)據(jù)結轉

任務實例執(zhí)行完成，處于結束狀態(tài)的實例都可以被結轉，目前采用定時結轉的策略。為避免冷數(shù)據(jù)單表數(shù)據(jù)量過大，結轉規(guī)則可以按照季度、月或則更小周期進行拆分存儲。

2） 數(shù)據(jù)定位

當數(shù)據(jù)結轉到冷數(shù)據(jù)表后，這些實例的狀態(tài)不會發(fā)生變更，單可能還會被未執(zhí)行的實例所依賴，用戶也可能會對這些實例做檢索操作，所以這些實例需要能從冷數(shù)據(jù)表中快速被定位。

?索引表：數(shù)據(jù)結轉到冷數(shù)據(jù)表時，會根據(jù)冷數(shù)據(jù)表的分區(qū)粒度，在索引表記錄各冷分區(qū)表中的數(shù)據(jù)范圍，如計劃運行時間在2023-01-01 至 2023-03-31的數(shù)據(jù)存儲在2023Q1分區(qū)表，這樣在定位時可以圈定數(shù)據(jù)范圍，避免全量掃描。

?數(shù)據(jù)定位：因實例數(shù)據(jù)是有周期性的，有非常強的時間特性，所以可以結合任務實例的計劃運行時間，和索引表的數(shù)據(jù)范圍，快速定位任務某個范圍的實例所在的分區(qū)。

3）冷數(shù)據(jù)操作

冷數(shù)據(jù)被操作的幾率比較低，但也存在操作的可能性，比如歷史實例的重跑、強制成功等操作。為了保持調度引擎架構的簡單性，所有相關的任務執(zhí)行的處理，都是基于當前表（熱表），所以為了能保障被結轉的冷數(shù)據(jù)和熱數(shù)據(jù)一樣支持所有操作，冷數(shù)據(jù)被操作時會從冷數(shù)據(jù)表恢復至熱數(shù)據(jù)表，從而實現(xiàn)與熱數(shù)據(jù)相同的效果。

4、開放能力

開放API：通過Http協(xié)議進行開放，支持任務配置管理、任務實例操作、狀態(tài)查詢、日志查詢等能力，通過藏經閣進行開放來服務業(yè)務

開放事件：基于JDQ異步消息的方式將任務狀態(tài)、實例狀態(tài)進行開放，聯(lián)動業(yè)務個性化處理。狀態(tài)發(fā)生變更及時同步，確保業(yè)務觸達的及時性

三、未來規(guī)劃

Buffalo調度系統(tǒng)仍在持續(xù)的優(yōu)化和迭代升級，不僅提供更好的用戶體驗、更極致的性能，也包括容器化能力、插件化擴展能力、開放能力、精細化的資源管理能力等，希望大家提出更好的想法和建議，一起打造穩(wěn)定、高效、易用的調度平臺。

審核編輯 黃宇