0.前言

有了数据平台，有了数据仓库，那就需要一个系统来调度和管理数仓的任务，因此调度系统的地位可见之重要。没有工作流调度系统之前，公司里面的任务都是通过 crontab 来定义的，时间长了后会发现很多问题：

• 大量的crontab任务需要管理；
• 任务没有按时执行，各种原因失败，需要重试；
• 多服务器环境下，crontab分散在很多集群上，日志查看不方便。

于是，出现了一些管理crontab任务的调度系统。而在大数据领域，关注的首要重点是在正确的时间点启动正确的作业，确保作业按照正确的依赖关系及时准确的执行。这个时候涌出了大量的调度工具。这也是本篇梳理的原因。

有个形象的说法：

调度选得好，下班回家早；

调度用得对，半夜安心睡。

一、Azkaban

1.1  Azkaban介绍

 Azkaban是由Linkedin开源的一个批量工作流任务调度器。用于在一个工作流内以一个特定的顺序运行一组工作和流程。Azkaban定义了一种KV文件格式来建立任务之间的依赖关系，并提供一个易于使用的web用户界面维护和跟踪你的工作流。

1.2 Azkaban的特点

1. Web用户界面。

2. 方便上传工作流。

3. 方便设置任务之间的关系。

4. 调度工作流。

5. 认证/授权(权限的工作)。

6. 随时操作(kill,重启)工作流。

7. 模块化和可插拔的插件机制。

8. 不同的项目可以归属于不同的空间，而且不同的空间又可以设置不同的权限 多个项目之间是不会产生任何的影响与干扰。

1.3 Azkaban优缺点

优点：简单，上手快

• 在所有引擎中，Azkaban可能是最容易开箱即用的。UI非常直观且易于使用。调度和REST API工作得很好。

• 有限的HA设置开箱即用。不需要负载均衡器，因为你只能有一个Web节点。你可以配置它如何选择执行程序节点然后才能将作业推送到它，它通常看起来非常好，只要有足够的容量来执行程序节点，就可以轻松运行数万个作业。

• Azkaban有较完善的权限控制。

缺点

• 出现失败的情况：Azkaban会丢失所有的工作流，因为Azkaban将正在执行的workflow状态保存在内存中。

• 操作工作流：Azkaban使用Web操作，不支持RestApi，Java API操作

• Azkaban可以直接操作shell语句。在安全性上可能Oozie会比较好。

二、Oozie

 2.1 Oozie介绍

 Oozie由Cloudera公司贡献给Apache的基于工作流引擎的开源框架,是用于Hadoop平台的开源的工作流调度引擎,是用来管理Hadoop作业,属于web应用程序，由Oozie client和Oozie Server两个组件构成,Oozie Server运行于Java Servlet容器（Tomcat）中的web程序。

2.2 Oozie特点

1. 实际上Oozie不是仅用来配置多个MR工作流的，它可以是各种程序夹杂在一起的工作流，比如执行一个MR1后，接着执行一个java脚本，再执行一个shell脚本，接着是Hive脚本，然后又是Pig脚本，最后又执行了一个MR2，使用Oozie可以轻松完成这种多样的工作流。使用Oozie时，若前一个任务执行失败，后一个任务将不会被调度。

2. Oozie的工作流必须是一个有向无环图，实际上Oozie就相当于Hadoop的一个客户端，当用户需要执行多个关联的MR任务时，只需要将MR执行顺序写入workflow.xml，然后使用Oozie提交本次任务，Oozie会托管此任务流。

3. Oozie定义了控制流节点（Control Flow Nodes）和动作节点（Action Nodes）,其中控制流节点定义了流程的开始和结束，以及控制流程的执行路径（Execution Path）,如decision,fork,join等;而动作节点包括Haoop map-reduce hadoop文件系统，Pig,SSH,HTTP,eMail和Oozie子流程。

2.3 Oozie优缺点

优点

• Oozie与Hadoop生态系统紧密结合，提供做种场景的抽象。

• Oozie有更强大的社区支持，文档。

• Job提交到hadoop集群，server本身并不启动任何job。

• 通过control node/action node能够覆盖大多数的应用场景。

• Coordinator支持时间、数据触发的启动模式。

• 支持参数化和EL语言定义workflow，方便复用。

• 结合HUE，能够方便的对workflow查看以及运维，能够完成workflow在前端页面的编辑、提交 能够完成workflow在前端页面的编辑、提交。

• 支持action之间内存数据的交互。

• 支持workflow从某一个节点重启。

缺点

• 对于通用流程调度而言，不是一个非常好的候选者，因为XML定义对于定义轻量级作业非常冗长和繁琐。

• 它还需要相当多的外设设置。你需要一个zookeeper集群，一个db，一个负载均衡器，每个节点都需要运行像Tomcat这样的Web应用程序容器。初始设置也需要一些时间，这对初次使用的用户来说是不友好的。

三、XXL-JOB

 3.1 XXL-JOB介绍

 XXL-JOB是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。

官网首页：https://www.xuxueli.com

3.2 XXL-JOB特点

1. 简单：支持通过Web页面对任务进行CRUD操作，操作简单，一分钟上手。

2. 动态：支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生效。

3. 调度中心HA（中心式）：调度采用中心式设计，“调度中心”自研调度组件并支持集群部署，可保证调度中心HA。

4. 执行器HA（分布式）：任务分布式执行，任务”执行器”支持集群部署，可保证任务执行HA。

5. 注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址。

6. 弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务。

7. 触发策略：提供丰富的任务触发策略，包括：Cron触发、固定间隔触发、固定延时触发、API（事件）触发、人工触发、父子任务触发。

8. 调度过期策略：调度中心错过调度时间的补偿处理策略，包括：忽略、立即补偿触发一次等。

9. 阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默认）、丢弃后续调度、覆盖之前调度。

10. 任务超时控制：支持自定义任务超时时间，任务运行超时将会主动中断任务。

11. 任务失败重试：支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；其中分片任务支持分片粒度的失败重试。

12. 任务失败告警；默认提供邮件方式失败告警，同时预留扩展接口，可方便的扩展短信、钉钉等告警方式。

13. 路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性HASH、最不经常使用. 最近最久未使用、故障转移、忙碌转移等。；

14. 分片广播任务：执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务。

15. 动态分片：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。

16. 故障转移：任务路由策略选择”故障转移”情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。

17. 任务进度监控：支持实时监控任务进度。

18. Rolling实时日志：支持在线查看调度结果，并且支持以Rolling方式实时查看执行器输出的完整的执行日志。

19. GLUE：提供Web IDE，支持在线开发任务逻辑代码，动态发布，实时编译生效，省略部署上线的过程。支持30个版本的历史版本回溯。

20. 脚本任务：支持以GLUE模式开发和运行脚本任务，包括Shell、Python、NodeJS、PHP、PowerShell等类型脚本。

21. 命令行任务：原生提供通用命令行任务Handler（Bean任务，”CommandJobHandler”）；业务方只需要提供命令行即可。

22. 任务依赖：支持配置子任务依赖，当父任务执行结束且执行成功后将会主动触发一次子任务的执行, 多个子任务用逗号分隔。

23. 一致性：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行。

24. 自定义任务参数：支持在线配置调度任务入参，即时生效。

25. 调度线程池：调度系统多线程触发调度运行，确保调度精确执行，不被堵塞。

26. 数据加密：调度中心和执行器之间的通讯进行数据加密，提升调度信息安全性。

27. 邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件。

28. 推送maven中央仓库: 将会把最新稳定版推送到maven中央仓库, 方便用户接入和使用。

29. 运行报表：支持实时查看运行数据，如任务数量、调度次数、执行器数量等；以及调度报表，如调度日期分布图，调度成功分布图等。

30. 全异步：任务调度流程全异步化设计实现，如异步调度、异步运行、异步回调等，有效对密集调度进行流量削峰，理论上支持任意时长任务的运行。

31. 跨语言：调度中心与执行器提供语言无关的 RESTful API 服务，第三方任意语言可据此对接调度中心或者实现执行器。除此之外，还提供了 “多任务模式”和“httpJobHandler”等其他跨语言方案。；

32. 国际化：调度中心支持国际化设置，提供中文、英文两种可选语言，默认为中文。

33. 容器化：提供官方docker镜像，并实时更新推送dockerhub，进一步实现产品开箱即用。

34. 线程池隔离：调度线程池进行隔离拆分，慢任务自动降级进入”Slow”线程池，避免耗尽调度线程，提高系统稳定性。

35. 用户管理：支持在线管理系统用户，存在管理员、普通用户两种角色。

36. 权限控制：执行器维度进行权限控制，管理员拥有全量权限，普通用户需要分配执行器权限后才允许相关操作。

四、Airflow

 4.1 Airflow介绍

Airflow 是一个使用 Python 语言编写的 Data Pipeline 调度和监控工作流的平台。

Airflow 是通过 DAG（Directed acyclic graph 有向无环图）来管理任务流程的任务调度工具，不需要知道业务数据的具体内容，设置任务的依赖关系即可实现任务调度。

这个平台拥有和 Hive、Presto、MySQL、HDFS、Postgres 等数据源之间交互的能力，并且提供了钩子（hook）使其拥有很好地扩展性。除了使用命令行，该工具还提供了一个 WebUI 可以可视化的查看依赖关系、监控进度、触发任务等。

4.2 Airflow特点

• 分布式任务调度：允许一个工作流的task在多台worker上同时执行。

• 可构建任务依赖：以有向无环图的方式构建任务依赖关系。

• task原子性：工作流上每个task都是原子可重试的，一个工作流某个环节的task失败可自动或手动进行重试，不必从头开始任务。

4.3 优缺点

优点

• 提供了一个很好的UI，允许你通过代码/图形检查DAG（工作流依赖性），并监视作业的实时执行。

• 高度定制Airflow。

缺点

• 部署几台集群扩容相对复杂及麻烦。

• Airflow的调度依赖于crontab命令，调度程序需要定期轮询调度计划并将作业发送给执行程序。

• 定期轮询工作，你的工作不能保证准时安排。

• 当任务数量多的时候，容易造成卡死。

五、DolphinScheduler

 5.1 DolphinScheduler介绍

Apache DolphinScheduler(Incubator,原Easy Scheduler)是一个分布式数据工作流任务调度系统，主要解决数据研发ETL错综复杂的依赖关系，而不能直观监控任务健康状态等问题。Easy Scheduler以DAG流式的方式将Task组装起来，可实时监控任务的运行状态，同时支持重试、从指定节点恢复失败、暂停及Kill任务等操作。

作为强大的带有有向无环图（DAG）可视化界面的分布式大数据工作流调度平台，DolphinScheduler解决了复杂的任务依赖关系和简化了数据任务编排的工作。它以开箱即用的、易于扩展的方式将众多大数据生态组件连接到可处理 100,000 级别的数据任务调度系统中来。

5.2 设计特点

一个分布式易扩展的可视化DAG工作流任务调度系统。致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用 其主要目标如下：(https://github.com/apache/dolphinscheduler)

• 以DAG图的方式将Task按照任务的依赖关系关联起来，可实时可视化监控任务的运行状态。。

• 支持丰富的任务类型：Shell、MR、Spark、SQL(mysql、postgresql、hive、sparksql),Python,Sub_Process、Procedure等。

• 支持工作流定时调度、依赖调度、手动调度、手动暂停/停止/恢复，同时支持失败重试/告警、从指定节点恢复失败、Kill任务等操作。

• 支持工作流优先级、任务优先级及任务的故障转移及任务超时告警/失败

• 支持工作流全局参数及节点自定义参数设置。

• 支持资源文件的在线上传/下载，管理等，支持在线文件创建、编辑。

• 支持任务日志在线查看及滚动、在线下载日志等。

• 实现集群HA，通过Zookeeper实现Master集群和Worker集群去中心化。

• 支持对Master/Worker cpu load，memory，cpu在线查看。

• 支持工作流运行历史树形/甘特图展示、支持任务状态统计、流程状态统计。

• 支持补数。

• 支持多租户。

• 支持国际化。

以上特点简单总结：

• 高可靠性：去中心化的多Master和多Worker, 自身支持HA功能, 采用任务队列来避免过载，不会造成机器卡死。

• 简单易用 DAG监控界面，所有流程定义都是可视化，通过拖拽任务定制DAG，通过API方式与第三方系统对接, 一键部署。

• 丰富的使用场景 支持暂停恢复操作. 支持多租户，更好的应对大数据的使用场景. 支持更多的任务类型，如 spark, hive, mr, python, sub_process, shell。

• 高扩展性 支持自定义任务类型，调度器使用分布式调度，调度能力随集群线性增长，Master和Worker支持动态上下线。

六、总结

参考资料：公众号(大数据左右手)-大数据调度系统选得好,下班回家早;调度用得对,半夜安心睡

大数据环境下，调度工具比不可少，离线批任务和准实时任务都需要调度去驱动。下文介绍主流大数据调度工具对比DolphinScheduler 、Azkaban、Airflow、Oozie、Xxl-job

非常推荐Apache DolphinScheduler

    —— 调度选的好，下班回家早；调度选的对，半夜安心睡；

Apache DolphinScheduler是一个分布式去中心化，易扩展的可视化DAG工作流任务调度系统。致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用，目前已累计有 400+ 公司在生产上使用。

特点

1. 高可靠性

去中心化的多Master和多Worker, 自身支持HA功能, 采用任务队列来避免过载，不会造成机器卡死

2. 简单易用

DAG 监控界面，所有流程定义都是可视化，通过拖拽任务定制DAG，通过API方式与第三方系统对接, 一键部署

3. 丰富的使用场景

支持暂停恢复操作. 支持多租户，更好的应对大数据的使用场景. 支持更多的任务类型，如 spark, hive, mr, python, sub_process, shell

4. 高扩展性

支持自定义任务类型，调度器使用分布式调度，调度能力随集群线性增长，Master和Worker支持动态上下线

主要能力

• Task以DAG形式关联，实时监控任务的状态。
• 支持Shell、MR、Spark、SQL、依赖等10多种任务类型。
• 工作流优先级、任务优先级，全局参数及局部自定义参数
• 工作流可定时、依赖、手动、暂停/停止/恢复
• 支持补数、多租户、日志在线查看及资源在线管理
• 完善的系统服务监控，任务超时告警/失败。
• 去中心化设计确保系统的稳定、高可用。
• 支持每日十万数据量级任务稳定运行