一、什么是调度系统

调度系统，更确切地说，作业调度系统（Job Scheduler）或者说工作流调度系统（workflow Scheduler）是任何一个稍微有点规模，不是简单玩玩的大数据开发平台都必不可少的重要组成部分。除了Crontab，Quartz这类偏单机的定时调度程序／库。开源的分布式作业调度系统也有很多，比较知名的比如：oozie，azkaban，chronos，zeus等等，此外，还有包括阿里的TBSchedule，SchedulerX和腾讯的Lhotse。

二、为什么需要调度系统

我们都知道大数据的计算、分析和处理，一般由多个任务单元组成（Hive、Sparksql、Spark、Shell等），每个任务单元完成特定的数据处理逻辑。

多个任务单元之间往往有着强依赖关系，上游任务执行并成功，下游任务才可以执行。比如上游任务结束后拿到 A 结果，下游任务需结合 A 结果才能产出 B 结果，因此下游任务的开始一定是在上游任务成功运行拿到结果之后才可以开始。

而为了保证数据处理结果的准确性，就必须要求这些任务按照上下游依赖关系有序、高效的执行。一个较为基础的处理方式是：预估出每个任务处理所需时间，根据先后顺序，计算出每个任务的执行的起止时间，通过定时跑任务的方式，让整个系统保持稳定的运行。

一个完整的数据分析任务最少执行一次，在数据量较少，依赖关系较为简单的低频数据处理过程中，这种调度方式完全可以满足需求。然而在企业级场景中，更多的是需要每天执行，如果任务数量较多，在任务启动的时间计算上就将耗费大量时间，另外如果出现上游任务执行时长超出原定预计时间或者运行异常的问题，上述的处理方式将完全无法应对，也会对人力物力造成重复损耗。因此，对于企业数据开发过程来说，一个完整且高效的工作流调度系统将起到至关重要的作用。

三、调度系统的两大种类

调度系统分为作业调度系统和资源调度系统两大类，但很多时候大家往往把这两类的概念混为一谈。

1、资源调度系统

资源调度系统的关注的重点是底层物理资源的分配管理，目标是最大化地利用集群机器的CPU、磁盘、网络等硬件资源，所调配和处理的往往是与业务逻辑没有直接关联的诸如通用程序进程这类的对象。

2、作业调度系统

作业调度系统关注的重点是在正确的时间点启动正确的作业，确保作业按照正常的依赖关系及时准确地执行。资源的利用率通常不是第一关注要点，业务流程的正确性才是最重要的。作业调度系统有时也会考虑负载均衡问题，但保证负载均衡更多的是为了系统自身的健壮性，而资源的合理利用作为一个可以优化的点，往往依托底层的资源调度系统来实现。

那么，为什么市面上会存在这么多的作业调度系统项目，作业调度系统为什么没有像HDFS、Hive、 HBase 之类的组件那样形成一个相对 标准化的解决方案呢？归根结底，还是由作业调度系统的业务复杂性决定的。

一个成熟易用、便于管理和维护的作业调度系统，需要和大量的周边组件对接，不仅包括各种存储计算框架，还可能要处理或使用到血缘管理、权限控制、负载流控、监控报警、质量分析等各种服务或事务。这些事务环节，每家公司都有自己的解决方案，所以作业调度系统所处的整体外部环境千差万别，而且，各公司各种业务流程的定制化需求又进一步加大了环境的差异性，所以，调度系统很难做到既能灵活通用地适配广大用户的各种需求，又不太晦涩难用。

市面上现有的各种开源作业调度系统，不是在某些环节、功能上是缺失的，使用和运维的代价很高，需要大量二次开发；就是只针对特定的业务场景，形态简单，缺乏灵活性；要不就是在一些功能环节上是封闭自成体系的，很难和外部系统进行对接。

那么，理想中的完备作业调度系统，到底都要处理哪些事务呢？要做好这些事务都有哪些困难要克服，有哪些方案可以选择，市面上的开源调度系统项目又是如何应对这些问题的，下面就让我和大家一起来探讨一 下。

四、作业调度系统的两大种类

根据实际的功能定位，市面上的作业调度系统主要分为以下两大类：定时分片类作业调度系统和DAG工作流类作业调度系统。这两类系统的架构和功能实现通常存在很大的差异。

1、定时分片类作业调度系统

定时分片类系统的方向，重点定位于任务的分片执行场景，这类系统的代表包括TBSchedule、SchedulerX、 Elastic-job、 Saturn。

这种功能定位的作业调度系统，其最早的需求来源和出发点往往是做一个分布式Crontab和Quartz。

一开始各个业务方自成一体，自己搞自己的单机定时任务，随着越来越多，分散管理的代价越来越高。再加上有些业务随着数据量的增加，各种定时任务为了提高运行效率，也需要以分布式的方式在多台机器上并发执行。这时候，分布式分片调度系统也就应运而生了。

这类系统的实际应用场景，往往和日常维护工作或需要定时执行的业务逻辑有一定的关联。比如需要定时批量清理一批机器的磁盘空间， 需要定时生成一批商品清单，需要定时批量对一批数据建索引， 需要定时对一批用户发送推评通知等。

这类系统的核心目标基本是以下两点：

（1）对作业分片逻辑的支持：将一个大的任务拆成多个小任务，分配到不同的服务器上执行，难点在于要做到不漏、不重，保证负载均衡，节点崩溃时自动进行任务迁移等。

（2）高可用的精确定时触发要求：因为往往涉及实际业务流程的及时性和准确性，所以通常需要保证任务触发的强实时和可靠性。

所以，负载均衡、弹性扩容、状态同步和失效转移通常是这类调度系统在架构设计时重点考虑的特性。

从接入方案和流程上来说，因为要支持分片逻辑和失效转移等，这类调度系统对所调度的任务通常都是有侵入性要求的。

常见的做法是用户作业需要依赖相关分片调度系统的客户端库函数，扩展一个作业调度类作为作业触发的入口类。一般还需要接收和处理分片信息用于对数据进行正确的分片处理。通常还需要实现一些接口用于满足服务端的管理需求，比如注册节点、注册作业、启动任务、停止任务、汇报状态等。有些系统还要求作业执行节点常驻守护进程，用于协调本地作业的管理和通信。

2、DAG工作流类调度系统

DAG工作流类调度系统的关注重点：定位于任务的调度依赖关系的正确处理，分片执行的逻辑通常不是系统关注的核心，或者不是系统核心流程的关键组成部分，如果某些任务真的关注分片逻辑，往往交给后端集群（比如MR任务自带分片能力）或具体类型的任务执行后端去实现。

这类系统的代表包括oozie、azkaban、chronos、zeus、 Lhotse, 还有各种大大小小的公有云服务提供的可视化工作流定义系统。

DAG工作流类调度系统所服务的往往是作业繁多、作业之间的流程依赖比较复杂的场景。比如大数据开发平台的离线数仓报表业务，从数据采集、清洗，到各个层级的报表的汇总运算，再到最后教据导出到外部业务系统，一个完整的业务流程可能涉及成百上千个相互交叉，依赖关联的作业。

所以DAG工作流类调度系统关注的重点通常包括以下几点：

（1）足够丰富和灵活的依赖触发机制：比如时间触发任务、依赖触发任文混合触发任务

而依赖触发任务自身可能还要考虑多亲依赖、长短周期依赖(如小时村任务依赖天任务，或者反过来)、依赖范围判定(比如所依赖任务最后一次成功就可以触发下游，还是过去一个星期的所有任务都成功才可以触发下游)、自身历史任务依赖、串并行触发机制等。

（2）作业的计划、变更和执行流水的管理和同步

定时分片类调度系统中固然也要考虑这个需求，但通常相对简单。而在DAG工作流类调度系统中，因为任务触发机制的灵活性和作业依赖关系的复杂性，这个需求就尤为重要，需要提供的功能更加复杂，具体的问题解决起来也困难很多。

（3）任务的优先级管理、业务隔离、权限管理

在定时分片类调度系统中，具体执行端的业务在很多情况下本来就是隔离的，注册了特定业务的节点才会去执行特定的任务。而且业务链路一般都比较短，再加上强实时性要求，所以对优先级的管理通常要求也不高，基本靠资源隔离来实现资源的可用，一般不存在竞争资源的问题，权限管理也是一样的。

而在DAG工作流类调度系统中，往往一大批作业共享资源执行，所以优先级、负载隔离和权限管控的问题也就突显出来了。

（4）各种特殊流程的处理，比如暂停任务、重刷历史数据、人工标注失败或成功、临时任务和周期任务的协同

这类需求本质上也是业务流程的复杂性带来的，比如业务逻辑变更、脚本写错、上游数据有问题、下游系统挂掉等，而业务之间的网状关联性，导致处理问题时需要考虑的因素很多，也就要求处理的手段应足够灵活强大。

（5）完备的监控报警通知机制

最简单的有任务失败报警、超时报警，复杂一点的有流量负载监控、业务进度监控和预测， 如果做得再完善一点，还可以包括业务健康度监控分析、性能优化建议和问题诊断专家系统等。

需要注意的是，这两类系统的定位目标并不是绝对冲突矛盾的。只不过要同时圆满地支持这两类系统的需求，从实现的角度来说是很困难的，因为侧重点不同，在架构上多少会对某些方面做些取舍，当前的系统都没有做到完美的两者兼顾。但并不代表这两类系统的实现就一定是不可调和的，好比离线批处理计算框架和流式实时计算框架，长期以来它们各行其道，但是随着理论和实践的深入，也开始有依托一种框架统一处理两类计算业务的可能性出现。