公交車伴隨着我們的日常生活已是隨處可見，不同路線的公交車根據各自的時間表有序發出，到達站點，接上站台的乘客再緩緩駛向下一站……早高峰會有短區間的加班車，發車間隔也更短，夜半時分的班次則間隔更長。這一切都服從於公交總站的調度。
在大數據平台中，也會有各式各樣的任務需要按照一定的時間間隔和先后順序有序進行，而管理這一切的就是調度引擎。它不僅要讓任務按時按點的執行，更要面對種種復雜的場景，例如：
10分鍾執行一次的周期任務執行了11分鍾，下一周期是否要直接開始計算
需要A任務執行完成后才執行的B任務，等待了一天還未等到A執行完畢，是否該繼續等待
十萬個任務同時被提交，該以怎樣的順序進行執行
問題種類繁多，如果沒有一個健壯智能的調度引擎，是無法像有序的公交車系統一樣支撐起一個大數據平台的任務執行的。
在市場上存在許多的調度框架，比如:Quartz、Elastic-Job、XXL-JOB等，但是他們僅支持定時提交任務，就好比固定班次的公交車，雖然能按時到達站點，卻難以面對早晚的乘車高峰。這樣單一的調度方式是遠遠滿足不了“曲折離奇、復雜多變”的業務場景。這個時候我們數棧自研的百萬級分布式調度引擎--DAGScheduleX就上場啦，它不僅滿足定時功能，內置豐富的策略來應對不同情況下的場景，如：資源限制、快速失敗、優先級動態調整、快速過期、上下游調度狀態依賴。
數棧支持基礎定時調度與復雜跨周期依賴策略。
在整個數棧架構中，DAGScheduleX作為數棧平台應用和底層大數據集群的紐帶，起着承上啟下的作用，在集群資源范圍內，協調着任務資源分配，安排着任務提交運行與周期性調度。
一、DAGScheduleX的主要流程
二、多集群配置和多租戶隔離
在實際的數據開發中，我們可能會有開發、測試等多環境。若要將任務提交在對應的集群下，我們只需要在數棧的控制台上配置好不同的集群環境，並綁定不同的租戶，此時任務提交會根據不同租戶實現集群隔離。
1. 控制台可以綁定不同類型的集群: 如生產環境A Hadoop、 生產環境B LibrA
2. 多個租戶可綁定一個集群
3. 提交任務時，通過tenantId 區分目標集群了
三、實例生成和提交
DAGScheduleX目前支持多種計算組件，如Flink、Spark、TensorFlow、Python、Shell 、Hadoop MR、Kylin、Odps、RDBMS（多種關系型數據庫）等等，所有上層應用提交任務都只要找好對應的插件類型就可以執行了。
DAGScheduleX支持自定義任務類型，擴展新的插件也是非常的方便，只要定義好對應的插件typeName並實現IClient中的定義的接口方法就可以。接口方法有以下：
init(初始化)方法
judgeSlots(資源判斷)方法
submitJob(提交任務)方法
getJobStatus(獲取任務狀態)方法
getJobLog(獲取任務執行日志)方法
cancelJob(取消任務)方法
一個Task(任務)提交到DAGScheduleX，就會提前一天生成好第二天的Job(實例)任務，到了執行的當天他們都會按照規定好的調度時間去運行，然后再獲取執行結果。當然補數據和立即運行是不受限的，DAGScheduleX還支持跨租戶間任務上下游依賴、任務自依賴、任務優先級調整、控制台任務隊列管理、運維中心任務監控等功能。
四、任務告警
在上下游依賴鏈路較長的時候，一個上游Job(實例)失敗就可能導致下游的數據出現問題。對於這種情況，DAGScheduleX支持多種場景的監控告警:
執行超過規定時長
執行失敗
任務未運行
任務停止
控制台告警通道不僅支持釘釘、短信、郵件等通用告警方式還支持用戶自定義的告警通道：
引入DAGScheduleX的告警sdk
實現ICustomizeChannel中的自定義告警邏輯
控制台告警通道上傳打包好的jar
應用中配置對應的告警場景
五、總結
DAGScheduleX是一個能對任務進行實例生成，實例調度、實例提交、實例運維、實例告警的分布式任務調度引擎。而數棧的離線計算、流計算、算法開發等所有的套件都依賴於調度引擎來執行任務，是很重要的樞紐。
本文首發於：數棧研習社
數棧是雲原生—站式數據中台PaaS，我們在github上有一個有趣的開源項目：FlinkX，FlinkX是一個基於Flink的批流統一的數據同步工具，既可以采集靜態的數據，比如MySQL，HDFS等，也可以采集實時變化的數據，比如MySQL binlog，Kafka等，是全域、異構、批流一體的數據同步引擎，大家如果有興趣，歡迎來github社區找我們玩~