目录
一、DolphinScheduler架构原理
1.1 系统架构图
1.2 DolphinScheduler核心概念
1.2 创建工作流
1.2.1 如何触发一个工作流实例
1.2.2 任务调度链路监控
1.2.3 Workflow-DAG解析
DAG解析
Dispatch分发流程
Master和Worker的交互过程
1.3 任务运行状态
该篇文章主要介绍DolphinScheduler-3.2.0工作流实例的工作周期
一、DolphinScheduler架构原理
1.1 系统架构图
在介绍之前,先对架构进行简单介绍。
内部服务主要分为四个部分:
(1)API服务,用于与UI交互;
(2)用于告警通知的Alert服务;
(3)主节点(master)和工作节点(worker)是去中心化的,可以部署多个Master和多个Worker,它们可以分布在不同的位置并独立工作。
(4)工作流运行在Master节点上,具体的任务节点在 Worker 节点上运行,例如 shell、Python、Flink 和 Spark 等任务节点。
1.2 DolphinScheduler核心概念
为更好的了解DolphinScheduler ,先介绍其核心概念:
- Process(工作流):由任务以有向无环图形式构成,执行时解析一个工作流为多个任务,可设置工作流优先级,工作执行全局参数、超时告警;
- Task(任务):调度执行的最小单元,包含Shell、Spark、Flink、Sql、MR等多种类型。可设置任务执行优先级、任务执行参数、超时告警、超时失败;
- Command(待调度指令):工作流经手动调度或定时调度生成的数据,存储在数据库DB中;
- Instance(任务实例):任务执行后,会生成相应的实例,记录执行时任务的状态及执行内容,任务实例可查看下载日志;
- Master(调度服务):提供对工作流手动调度、定时调度、超时告警、任务容错、任务执行监控等功能;
- Worker(运行服务):解析工作流,识别任务类型,调用对应任务类型的逻辑,生成任务实例;
- Alert(告警服务):可通过Email、FTP、微信等多种方式,告知工作流、任务执行结果。
下面具体展示调度任务的创建、被调度执行的过程:
- 根据具体的业务需求,通过Web界面以DAG形式创建工作流,生成Process并落库;
- 手动调度或定时调度生成待调度指令Command,存储在数据库DB中;
- Master监听读取Command记录,解析后动态分配至Worker,选择对应的任务类型执行;
- Worker执行完成后,生成Process Instance(工作流实例)、Task Instance(任务实例)并落库;
- Alert告警模块监听Instance实例,通过Email等发送任务执行结果。
1.2 创建工作流
1.2.1 如何触发一个工作流实例
接下来,让我们看看如何创建工作流实例。
简单来说,我们可以通过页面、客户端或命令行等方式触发工作流实例的启动。不管是通过页面运行、使用客户端提交还是运行数,系统都会创建一条待调度指令Command,并先存储在数据库中,然后Master进行异步轮询处理,每个 Master 会根据自己的下标来获取需要自己处理的 Command,并将Command转化为工作流实例。
1.2.2 任务调度链路监控
为了保障调度任务的稳定性,有必要对任务调度的生命周期进行监控。DolphinScheduler服务调度任务的全流程是先从quartz中产生Command,然后将Command转化为工作流实例,再从工作流实例生成一系列对应的任务实例,需要对该任务链路的生命周期进行监控。
(1)例如:通过监控quartz元数据,发现漏调度和重复调度问题。
(2)例如:监控command表积压情况,从而监控master是否服务正常,以及master服务的性能是否能够满足需求
(3)例如:通过监控任务实例等待提交时间,从而监控worker服务是否正常,以及worker服务的性能是否能够满足需求。
通过如上的全生命周期监控,可以及时发现worker服务的性能问题,尽早解决,避免影响到用户调度服务。
1.2.3 Workflow-DAG解析
DAG解析
此时,Master 就开始对工作流实例进行处理,这涉及到DAG解析的三个步骤:①DAG 构建、②任务数据初始化、③任务节点提交。
①DAG构建的目的是获取一个工作流节点的拓扑图,具体取决于任务节点的设置和状态。②数据初始化的处理是当工作流实例重跑或容错的场景下,此时需要加载一些历史数据,并跳过已成功执行的任务。③提交任务节点,根据DAG拓扑图,开始从 DAG 中获取下一个要提交的任务节点,并将其提交到任务队列中,最后将其分发Worker节点执行。当处理完任务实例后,会从DAG拓扑继续找出它的下游节点,提交分发,循环处理直到整个DAG运行完成。
Dispatch分发流程
对于 Dispatch分发流程,首先有一个Worker group的概念,即对一个或几个Worker节点打上分组的标签。比如 Spark 集群组,Flink 集群组,配置的任务时可以配置Worker分组,在dispatch分发时只会分发到对应的目标Worker组。
目前DS使用 lower-weight的分发策略来确定最优的Dispatch分发对象,结合心跳机制,worker 每5秒上报一次心跳到注册中心,汇报本轮自己的状态是否busy(结合cpu、内存、当前处理任务数来判断),Master定时从注册中心中获取worker心跳,并将其存储到数据库DB中。
Master和Worker的交互过程
当任务实例被分发给Worker节点后,涉及到 Master 和 Worker 之间的交互。在正常流程下,当任务实例分发给 Worker 节点后,工作节点不会立即执行任务,而是将任务放入队列中,然后由另一个线程来消费。
Worker接收任务成功,Master会将任务实例的状态设置为已分发,并记录下对应的Worker host。当Worker真正开始执行任务时,它会向Master 发送消息反馈任务正在 Running,Master 收到后会回复ack 确认,以确保通信的稳定性,不会丢失任何信息。
当Worker处理完任务后,会发送任务Finish的消息,Master收到后更新任务的状态、参数和应用信息。
1.3 任务运行状态
在介绍了正常流程后,还有一些与运行状态相关的操作,例如暂停和停止。我们可以通过页面上的操作来触发这些操作,例如触发停止,实际上任务的停止是执行在 Worker 节点上的,完成后也会经过 Finish-ack 的流程。
此外,还有一些超时检测,Master会检测任务是否达到超时时间点,如果达到终止时间点,它会发送一个事件给对应的Worker,进行相应的处理。
监听机制,例如当 Worker 节点挂掉时,Master会通过注册中心监听到,并进行任务容错处理。如果 Master 节点挂掉,其他 Master 节点将进行抢锁来接管工作流实例,确保系统的正常运行。
参考文章:
Apache DolphinScheduler 在奇富科技的首个调度异地部署实践
https://mp.weixin.qq.com/s/r9_cDkErlcChgu3wA5o2Iw
浅析 Apache DolphinScheduler 工作流实例的生命周期