1 概述
1.1 名词解释
DAG： 全称Directed Acyclic Graph，简称DAG（有向无环图）。工作流中的Task任务以有向无环图的形式组装起来，从入度为零的节点进行拓扑遍历，直到无后继节点为止。
流程定义（单个作业job的定义）：通过拖拽任务节点并建立任务节点的关联所形成的可视化DAG
流程实例（作业流jobflow）：流程实例是流程定义的实例化，可以通过手动启动或定时调度生成，流程定义每运行一次，产生一个流程实例
任务实例：任务实例是流程定义中任务节点的实例化，标识着具体的任务执行状态
任务类型： 目前支持有SHELL、SQL、SUB_PROCESS(子流程)、PROCEDURE、MR、SPARK、PYTHON、DEPENDENT(依赖)，同时计划支持动态插件扩展，注意：其中子 SUB_PROCESS 也是一个单独的流程定义，是可以单独启动执行的
调度方式： 系统支持基于cron表达式的定时调度和手动调度。命令类型支持：启动工作流、从当前节点开始执行、恢复被容错的工作流、恢复暂停流程、从失败节点开始执行、补数、定时、重跑、暂停、停止、恢复等待线程。其中 恢复被容错的工作流 和 恢复等待线程 两种命令类型是由调度内部控制使用，外部无法调用
定时调度：系统采用 quartz 分布式调度器，并同时支持cron表达式可视化的生成
依赖：系统不单单支持 DAG 简单的前驱和后继节点之间的依赖，同时还提供任务依赖节点，支持流程间的自定义任务依赖
优先级 ：支持流程实例和任务实例的优先级，如果流程实例和任务实例的优先级不设置，则默认是先进先出
邮件告警：支持 SQL任务 查询结果邮件发送，流程实例运行结果邮件告警及容错告警通知
失败策略：对于并行运行的任务，如果有任务失败，提供两种失败策略处理方式，继续是指不管并行运行任务的状态，直到流程失败结束。结束是指一旦发现失败任务，则同时Kill掉正在运行的并行任务，流程失败结束
补数：补历史数据，支持区间并行和串行两种补数方式
1.2 调度器对比
| DolphinScheduler | Azkaban | Airflow | Oozie | |
|---|---|---|---|---|
| 定位 | 解决数据处理流程中错综复杂的依赖关系 | 为了解决Hadoop的任务依赖关系问题 | 通用的批量数据处理 | 管理Hdoop作业（job）的工作流程调度管理系统 |
| 任务类型支持 | 支持传统的shell任务，同时支持大数据平台任务调度：MR、Spark、SQL(mysql、postgresql、hive/sparksql)、python、procedure、sub_process | Command、HadoopShell、Java、HadoopJava、Pig、Hive等，支持插件式扩展 | Python、Bash、HTTP、Mysql等，支持Operator的自定义扩展。 | 统一调度hadoop系统中常见的mr任务启动、Java MR、Streaming MR、Pig、Hive、Sqoop、Spark、Shell等 |
| 可视化流程定义 | 是 所有流定时操作都是可视化的，通过拖拽来绘制DAG。配置数据源及资源，同时对于第三方系统，提供api方式的操作。 | 否 通过自定义DSL绘制DAG并打包上传 | 否 通过python代码来绘制DAG,使用不便 | 否 配置相关的调度任务复杂，依赖关系、时间触发、事件触发使用xml语言进行表达 |
| 任务监控支持 | 任务状态、任务类型、重试次数、任务运行机器、可视化变量等关键信息一目了然 | 只能看到任务状态 | 不能直观区分任务类型 | 任务状态、任务类型、任务运行机器、创建时间、启动时间、完成时间等。 |
| 自定义任务类型支持 | 是 | 是 | 是 | 是 |
| 暂停/恢复/补数 | 支持暂停、恢复 补数操作 | 否 只能先将工作流杀死在重新运行 | 否 只能先将工作流杀死再重新运行 | 支持启动/停止/暂停/恢复/重新运行： Oozie支持Web，RestApi，Java API操作 |
| 高可用支持 | 支持HA 去中心化的多Master和多Worker | 通过DB支持HA -但Web Server存在单点故障风险 | 通过DB支持HA -但Scheduler存在单点故障风险 | 通过DB支持HA |
| 多租户支持 | 支持dolphinscheduler上的用户可以通过租户和hadoop用户实现多对一或一对一的映射关系，这对大数据作业的调度是非常重要。 | 否 | 否 | 否 |
| 过载处理能力 | 任务队列机制，单个机器上可调度的任务数量可以灵活配置，当任务过多时会缓存在任务队列中，不会操作机器卡死 | 任务太多时会卡死服务器 | 任务太多时会卡死服务器 | 调度任务时可能出现死锁 |
| 集群扩展支持 | 是 调度器使用分布式调度，整体的调度能力会随集群的规模线性增加，Master和Worker支持动态上下线 | 是 -只Executor水平扩展 | 是 -只Executor水平扩展 | 是 |
2 架构设计
2.1 架构图
2.2 架构说明
-
MasterServer
MasterServer采用分布式无中心设计理念，MasterServer主要负责 DAG 任务切分、任务提交监控，并同时监听其它MasterServer和WorkerServer的健康状态。 MasterServer服务启动时向Zookeeper注册临时节点，通过监听Zookeeper临时节点变化来进行容错处理。
该服务内主要包含:
-
Distributed Quartz分布式调度组件，主要负责定时任务的启停操作，当quartz调起任务后，Master内部会有线程池具体负责处理任务的后续操作
-
MasterSchedulerThread是一个扫描线程，定时扫描数据库中的 command 表，根据不同的命令类型进行不同的业务操作
-
MasterExecThread主要是负责DAG任务切分、任务提交监控各种不同命令类型的逻辑处理
- MasterTaskExecThread主要负责任务的持久化
-
-
WorkerServer
WorkerServer也采用分布式无中心设计理念，WorkerServer主要负责任务的执行和提供日志服务。WorkerServer服务启动时向Zookeeper注册临时节点，并维持心跳。
该服务包含：
-
FetchTaskThread主要负责不断从Task Queue中领取任务，并根据不同任务类型调用TaskScheduleThread对应执行器。
- LoggerServer是一个RPC服务，提供日志分片查看、刷新和下载等功能
-
-
ZooKeeper
ZooKeeper服务，系统中的MasterServer和WorkerServer节点都通过ZooKeeper来进行集群管理和容错。另外系统还基于ZooKeeper进行事件监听和分布式锁。
-
Alert
提供告警相关接口，接口主要包括告警两种类型的告警数据的存储、查询和通知功能。其中通知功能又有邮件通知和SNMP(暂未实现)两种。
-
API
API接口层，主要负责处理前端UI层的请求。该服务统一提供RESTful api向外部提供请求服务。 接口包括工作流的创建、定义、查询、修改、发布、下线、手工启动、停止、暂停、恢复、从该节点开始执行等等。
2.3 去中心化设计
- 在去中心化设计里，通常没有Master/Slave的概念，所有的角色都是一样的，地位是平等的，全球互联网就是一个典型的去中心化的分布式系统，联网的任意节点设备down机，都只会影响很小范围的功能。
- 去中心化设计的核心设计在于整个分布式系统中不存在一个区别于其他节点的”管理者”，因此不存在单点故障问题。但由于不存在” 管理者”节点所以每个节点都需要跟其他节点通信才得到必须要的机器信息，而分布式系统通信的不可靠性，则大大增加了上述功能的实现难度。
- 实际上，真正去中心化的分布式系统并不多见。反而动态中心化分布式系统正在不断涌出。在这种架构下，集群中的管理者是被动态选择出来的，而不是预置的，并且集群在发生故障的时候，集群的节点会自发的举行"会议"来选举新的"管理者"去主持工作。
- dolphinscheduler的去中心化是Master/Worker注册到Zookeeper中，实现Master集群和Worker集群无中心，并使用Zookeeper分布式锁来选举其中的一台Master或Worker为“管理者”来执行任务。
2.4 容错设计
海豚调度的容错分为了两部分，即服务容错与任务重试
2.4.1 服务容错
服务容错借助zk的分布式锁实现
2.4.2 任务重试
任务重试分两种情况，如果是任务级别的失败，是由调度系统自动调起，如任务中设置了失败重试次数。另外一种情况是流程失败，是指任务达到最大失败重试次数
