怎么做大数据工作流调度系统？大厂架构师一语点破！

编者说：文章介绍了EasyScheduler的架构设计，以及每个组件工作的方式。如果你的工作中遇到需要大数据工作流的场景可以尝试使用这个架构。由于文章比较长建议先收藏再阅读。

Easy Scheduler 大数据工作流调度系统已经开源，下载地址：https://github.com/analysys/

在对调度系统架构说明之前，我们先来认识一下调度系统常用的名词。

名词解释

• DAG：全称Directed Acyclic Graph，简称DAG。工作流中的Task任务以有向无环图的形式组装起来，从入度为零的节点进行拓扑遍历，直到无后继节点为止。举例如下图

• 流程定义：通过拖拽任务节点并建立任务节点的关联所形成的可视化 DAG
• 流程实例：流程实例是流程定义的实例化，可以通过手动启动或定时调度生成
• 任务实例：任务实例是流程定义中任务节点的实例化，标识着具体的任务执行状态
• 任务类型：目前支持有SHELL、SQL、SUB_PROCESS、PROCEDURE、MR、SPARK、PYTHON、DEPENDENT，同时计划支持动态插件扩展，注意：其中子 SUB_PROCESS 也是一个单独的流程定义，是可以单独启动执行的
• 调度方式：系统支持基于cron表达式的定时调度和手动调度。命令类型支持：启动工作流、从当前节点开始执行、恢复被容错的工作流、恢复暂停流程、从失败节点开始执行、补数、调度、重跑、暂停、停止、恢复等待线程。其中 恢复被容错的工作流 和 恢复等待线程 两种命令类型是由调度内部控制使用，外部无法调用
• 定时调度：系统采用 quartz 分布式调度器，并同时支持cron表达式可视化的生成
• 依赖：系统不单单支持 DAG 简单的前驱和后继节点之间的依赖，同时还提供 任务依赖 节点，支持 流程间的自定义任务依赖
• 优先级：支持流程实例和任务实例的优先级，如果流程实例和任务实例的优先级不设置，则默认是先进先出
• 邮件告警：支持 SQL任务 查询结果邮件发送，流程实例运行结果邮件告警及容错告警通知
• 失败策略：对于并行运行的任务，如果有任务失败，提供两种失败策略处理方式， 继续 是指不管并行运行任务的状态，直到流程失败结束。结束 是指一旦发现失败任务，则同时Kill掉正在运行的并行任务，流程失败结束
• 补数：补历史数据，支持 区间并行和串行 两种补数方式

系统架构

架构说明

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进行事件监听和分布式锁。我们也曾经基于Redis实现过队列，不过我们希望EasyScheduler依赖到的组件尽量地少，所以最后还是去掉了Redis实现。

Task Queue

提供任务队列的操作，目前队列也是基于Zookeeper来实现。由于队列中存的信息较少，不必担心队列里数据过多的情况，实际上我们压测过百万级数据存队列，对系统稳定性和性能没影响。

Alert

提供告警相关接口，接口主要包括 告警 两种类型的告警数据的存储、查询和通知功能。其中通知功能又有 邮件通知 和**SNMP(暂未实现)**两种。

API

API接口层，主要负责处理前端UI层的请求。该服务统一提供RESTful api向外部提供请求服务。接口包括工作流的创建、定义、查询、修改、发布、下线、手工启动、停止、暂停、恢复、从该节点开始执行等等。

UI

系统的前端页面，提供系统的各种可视化操作界面，详见**系统使用手册**部分。

• 架构设计思想
• 去中心化vs中心化
• 中心化思想

中心化的设计理念比较简单，分布式集群中的节点按照角色分工，大体上分为两种角色：

Master的角色主要负责任务分发并监督Slave的健康状态，可以动态的将任务均衡到Slave上，以致Slave节点不至于“忙死”或”闲死”的状态。

Worker的角色主要负责任务的执行工作并维护和Master的心跳，以便Master可以分配任务给Slave。

中心化思想设计存在的问题：

• 一旦Master出现了问题，则群龙无首，整个集群就会崩溃。为了解决这个问题，大多数Master/Slave架构模式都采用了主备Master的设计方案，可以是热备或者冷备，也可以是自动切换或手动切换，而且越来越多的新系统都开始具备自动选举切换Master的能力,以提升系统的可用性。
• 另外一个问题是如果Scheduler在Master上，虽然可以支持一个DAG中不同的任务运行在不同的机器上，但是会产生Master的过负载。如果Scheduler在Slave上，则一个DAG中所有的任务都只能在某一台机器上进行作业提交，则并行任务比较多的时候，Slave的压力可能会比较大。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!