浅析 Apache DolphinScheduler 工作流实例的生命周期

857技术社区

发布于 2023-07-26 10:31:22

5350

发布于 2023-07-26 10:31:22

文章被收录于专栏：857-Bigdata857-Bigdata

点击蓝字关注我们

“

大家好，我是蔡顺峰，白鲸开源的数据工程师，同时也是Apache DolphinScheduler项目的committer和PMC成员。今天我想和大家分享的主题是工作流实例的生命周期。

”

文｜蔡顺峰

编辑整理｜ 曾辉

讲师介绍

蔡顺峰

白鲸开源研发工程师

项目介绍

Apache DolphinScheduler是一个分布式任务调度平台，旨在提供即插即用的数据管道解决方案。

它具有以下几个特性：高可用性体现在去中心化的架构上，其中包括 Master 和 Worker ，可以部署多个节点，并具备容错机制，保证工作流的自动恢复。其次，它具有丰富的插件，涵盖了任务、数据源、告警和注册中心等方面。

Apache DolphinScheduler支持多种外部调用方式，如常见的 Web UI 和开放的 API，在社区中还有一个名为 PyDS 的子项目，它是一个 Python客户端，还可以通过提交yaml文件来启动工作流，类似于在K8S中提交YAML文件来启动一个工作流。

它的工作流和任务状态与任务插件有一定关联，并且支持各种依赖类型。此外，它还具备参数传递等功能，包括全局参数和任务本身的参数传递逻辑。

Apache DolphinScheduler 作为 Apache 基金会的顶级项目，在中国非常受欢迎，同时在海外也有用户开始尝试和咨询，我们有450多位贡献者，在GitHub上拥有一万个Star，其次它背后用有一家商业开源公司—白鲸开源。

新特性

新特性主要集中在DS 3.0和3.1版本上。对于使用过DS的用户来说，可以了解到在2.0和3.0之间最大的区别是UI的改进，整个UI进行了重新设计，并且性能也有了大幅提升。

在MLOPS方面，我们引入了许多任务组件，旨在提供更好的调度和机器学习支持。

最近，我们还在ChatGPT中尝试了一些大模型，感兴趣的同学可以阅读我们的公众号上的文章。用一杯星巴克的钱，训练自己私有化的ChatGPT

另外，我们还与云服务提供商进行了对接，主要集中在任务插件和数据源方面，我们已经与亚马逊云和阿里云对接，如阿里云的OSS和亚马逊的S3、Redshift等数据源。

稳定性

在稳定性方面，我们在高可用性的基础上做了一些重要的改进，主要集中在 Master 和 Worker 的代码重构上，以解决在高并发任务下的稳定性问题。

服务拆分方面，我们根据架构设计进行了服务拆分，使服务更轻量级。我们希望DS整个项目更易用，以便用户和贡献者更方便地使用，从而保证项目的持续发展，而核心的重点部分则是稳定性和性能的提升。

此外，我们也在开放方面做了很多工作，如在基础上向外拓展各种客户端形式，如 Python 客户端和 yaml 提交等，目的是降低接入成本。

最后是生态系统，在保持核心稳定的前提下，我们丰富了插件，并且甚至可以在将来把某些插件拆分出去，独立进行版本迭代，以提高插件的迭代效率。

工作流实例生命周期

在介绍之前，先对架构进行简单介绍。

首先，在服务中，我们有一个数据库 DB，以及一个用于服务注册和发现的注册中心。

我们的内部服务主要分为四个部分：

API 服务，用于与 UI 交互；
然后是负责告警通知的 Alert 服务；
主节点（master）和工作节点（worker）是去中心化的，可以部署多个 Master 和多个Worker，它们可以分布在不同的位置并独立工作。
基本概念是工作流运行在 Master 节点上，具体的任务节点在 Worker 节点上运行，例如 shell、Python、Flink 和 Spark 等任务节点。

创建工作流

接下来，让我们看看如何创建工作流实例。

简单来说，我们可以通过页面、客户端或命令行等方式触发工作流实例的启动。不管是通过页面运行、使用客户端提交还是运行数，系统都会创建一条命令，并先存储在数据库中，然后Master进行异步轮询处理，每个 Master 会根据自己的下标来获取需要自己处理的 Command，并将 Command 转化为工作流实例。

此时，Master 就开始对工作流实例进行处理，这涉及到 DAG 解析的三个步骤：DAG 构建、数据初始化和任务节点提交。DAG 构建的目的是获取一个工作流节点的拓扑图，它可以是全量的或局部的，具体取决于任务节点的设置和状态。

数据初始化的处理是当工作流实例重跑或容错的场景下，此时需要加载一些历史数据，并跳过已成功执行的任务。第三步是提交任务节点，根据 DAG 拓扑图，我们开始从 DAG 中获取下一个要提交的任务节点，并将其提交到任务队列中，最后将其分发Worker节点执行。当处理完任务实例后，会从DAG拓扑继续找出它的下游节点，提交分发，循环处理直到整个DAG运行完成。

OK，接下来重点讲下 Dispatch 分发流程。首先有一个 Worker group 的概念，即对一个或几个Worker 节点打上分组的标签，比如 Spark 集群组，Flink 集群组，任务在配置的时候可以配置Worker分组，在dispatch分发时只会分发到对应的目标 Worker 组。

第二步是如何确定最优的分发对象，目前 DS 使用 lower-weight 的分发策略，结合心跳机制，worker 每5秒上报一次心跳到注册中心，汇报本轮自己的状态是否busy（结合cpu、内存、当前处理任务数来判断），Master 定时同步到内存中做，在 Dispatch 的时候去除本轮“不可用”的 Worker 对象，至此，分发流程基本结束。

值得一提的是，社区已经对整个逻辑组件的流程做了统一，一方面是将原本各个逻辑组件内部处理做了流程统一，方便管理，提升稳定性；

另一方面，在 Dispatch 的时候做了抽象，可以分发给 Worker 节点，也可以分发给 Local 自己，甚至后续可以直接分发到 K8s 环境中，提高了想象力空间。

当任务实例被分发给 Worker 节点后，涉及到 Master 和 Worker 之间的交互。在正常流程下，当任务实例分发给 Worker 节点后，工作节点不会立即执行任务，而是将任务放入队列中，然后由另一个线程来消费。

此时，Worker 接收任务成功，Master 会将任务实例的状态设置为已分发，并记录下对应的 Worker host。当 Worker 真正开始执行任务时，它会向 Master 发送消息反馈任务正在 Running，Master 收到后会回复 ack 确认，以确保通信的稳定性，不会丢失任何信息。

当 Worker 处理完任务后，会发送任务 Finish 的消息，Master 收到后更新任务的状态、参数和应用信息。

运行状态

在介绍了正常流程后，还有一些与运行状态相关的操作，例如暂停和停止。我们可以通过页面上的操作来触发这些操作，例如触发停止，实际上任务的停止是执行在 Worker 节点上的，完成后也会经过 Finish-ack 的流程。