【任务调度系统第一篇】：大数据任务调度框架

1.前言

任务调度系统在大数据平台架构中扮演着比较重要的角色。下图是引自网易的猛犸大数据平台lambda架构图。

其中的Azkaban就是其任务调度组件。概括来说，任务调度在大数据平台中所扮演的角色主要有：

1. 任务编排：对任务流按照一定的逻辑串起来。这在大数据开发中，显得比较重要，对于一个工作任务，可能有不同的子任务串起来的，并且有些子任务是并行执行的。举个例子，在做一个机器学习的模型时，可能第一步就是数据清洗，然后是提取特征，接着才是模型预测。然后提取特征的过程中，可能要分为提取属性特征和行为特征。那么这里用拓扑图可以表示为如下图：
   

2. 任务调度执行：任务调度组件的核心使命肯定是让离线任务按照我们既定的执行计划去周期调度地执行。那么任务调度系统就需要能够按照任务的调度计划去自动执行任务。

3. 运维功能：作为一个系统肯定要有健全的运维功能，比如说提供任务运行报表功能，调度日志等等。类似于下图：

2.目前主流的任务调度系统

目前主流的任务调度框架有：

1. xxl job: XXL-JOB 是一个轻量级分布式任务调度框架，支持通过 Web 页面对任务进行 CRUD 操作，支持动态修改任务状态、暂停/恢复任务，以及终止运行中任务，支持在线配置调度任务入参和在线查看调度结果。其官网： http://www.xuxueli.com/xxl-job/#/
2. Azkaban：Azkaban是由Linkedin公司推出的一个批量工作流任务调度器，主要用于在一个工作流内以一个特定的顺序运行一组工作和流程。官网：https://azkaban.github.io/
3. elastic Job：Elastic-Job 是一个分布式调度解决方案，由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。定位为轻量级无中心化解决方案，使用 jar 包的形式提供分布式任务的协调服务。支持分布式调度协调、弹性扩容缩容、失效转移、错过执行作业重触发、并行调度、自诊断和修复等等功能特性。官网：http://elasticjob.io/
4. Apache Oozie：Oozie 是一个工作流调度系统，用来管理 Hadoop 任务。官网：http://oozie.apache.org/

以上只列举四种吧。对于这些调度框架，虽然基本原理相似，但是在细节功能点上各有千秋。因为笔者在实际开发中，有幸接触了xxl job和azkaban。所以本专栏也主要介绍和分析这两个框架。

3. azkaban和xxl job的异同点

不同点：

1. azkaban的最大亮点是任务的编排，类似阿里云的odps里的任务流开发，感觉是基于azkaban的。可以把一个大任务拆分成不同的子任务，然后按照一定的逻辑编排起来。但是xxl job基本上没有任务编排功能，仅仅是支持某个任务可以设定他的子任务，这其实灵活性就没有那么强。
2. xxl job的分布式性能要比azkaban好。xxl job在设计的时候就考虑了高可用性（HA），采用了执行器和调度中心分离的方式。执行器可以分别部署在不同的机器上，他们之间通过数据库维护着彼此的心跳。然后调度中心是分别部署在不同的机器上，执行器都分别向各个存活着的调度中心注册。但是azkaban的高可用性相比于xxl job就要差点，其仅仅保证了执行器的HA性能，调度中心不支持。当调度中心挂掉之后，用户就不能提交任务了，但是已经提交了的任务的正常调度还是可以继续。
3. 从源码级别看，xxl job更轻量级。其采用spring boot， Mybatis的主体框架，代码量相比于azkaban少了好多。azkaban的代码很少用框架，连MVC， 数据库ORM等都是在代码里自己实现，所以代码量较多。不过笔者的建议是，多读读azkaban的源码，对提高java的能力更有帮助。不过出于维护，xxl job肯定更好，可以减少很多维护成本。
4. Web UI不同。xxl job的Web UI 基本上很完善，可以开箱即用。在web界面上可以在线开发任务。但是azkaban的Web界面就比较简单，需要我们线下自己压缩好任务包，通过界面上传任务。所以对于产品化来说，xxl job的成本更低。

相同点：

1. 其底层的任务调度插件都是依赖于quartz。这点也然我认识到quartz应该是通用的调度插件。
2. 都是采用调度调度中心和执行器分离的方式。其中执行器的高可用性原理是一样的。都是各个执行器节点每隔一点时间间隔（比如5s）向共同依赖的数据库写如心跳，然后彼此通过心跳来感知对方是否存活。

后记

本专题后续的文章也主要是围绕这两个框架来展开，希望对他们的原理和用法做一番剖析。