公交车伴随着我们的日常生活已是随处可见，不同路线的公交车根据各自的时间表有序发出，到达站点，接上站台的乘客再缓缓驶向下一站……早高峰会有短区间的加班车，发车间隔也更短，夜半时分的班次则间隔更长。这一切都服从于公交总站的调度。
在大数据平台中，也会有各式各样的任务需要按照一定的时间间隔和先后顺序有序进行，而管理这一切的就是调度引擎。它不仅要让任务按时按点的执行，更要面对种种复杂的场景，例如：
- 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是一个能对任务进行实例生成，实例调度、实例提交、实例运维、实例告警的分布式任务调度引擎。而数栈的离线计算、流计算、算法开发等所有的套件都依赖于调度引擎来执行任务，是很重要的枢纽。
本文首发于：数栈研习社
