Apache DolphinScheduler 跨工作流复杂依赖功能详解

大家好，我叫高楚枫，来自阿里云 EMR 团队的开发工程师，同时也是 Apache DolphinScheduler 的 PMC 成员之一。

今天非常高兴能在这里和大家分享关于跨工作流复杂依赖的功能详解。

引言

在现代的数据处理和调度过程中，工作流的依赖管理变得越来越复杂，尤其是当涉及多个工作流的依赖关系时。Apache DolphinScheduler 为此提供了强大的跨工作流依赖功能，帮助开发者更高效地管理和调度复杂任务。

今天的分享会从以下五个方面进行讲解：

• Apache DolphinScheduler 和 Airflow 中的跨工作流依赖的体现方式
• 跨工作流依赖场景的复杂性
• 跨工作流依赖执行流程详解
• 跨工作流的补数场景
• 常见问题及案例分析

接下来，我将为大家逐一讲解这些内容。

DS的跨工作流依赖

首先，给大家介绍一下 Apache DolphinScheduler 中跨工作流依赖的实现方式，大家可以看下面这个截图，主要通过一个名为 dependent task 的任务插件来实现。

对于那些熟悉 Apache DolphinScheduler 的朋友来说，可能会觉得奇怪，因为它看起来像是一个普通的任务插件。

那么，这其中有什么特别之处？为什么跨工作流依赖功能显得复杂呢？实际上，这背后有以下三个关键点：

两种插件形式

在 Apache DolphinScheduler 中，插件有两种形式：

• Worker task：例如运行 shell 脚本、Spark 作业、Flink 作业等，它们都在 worker 上执行。这类插件具有极强的扩展性，且可以方便地进行插拔。
• Master 上的 logic task： dependent task 则是运行在 master 上的逻辑任务，和工作流调度的核心逻辑存在强耦合性。在涉及复杂的依赖关系时，这种逻辑任务会产生更多的组合情况，从而显著增加任务调度的复杂度。

依赖的定义

大家可以看看下面这张图片，当你在 DolphinScheduler 中创建一个 dependent task 后，你可以选择项目名称、工作流名称和任务名称，从而指定跨工作流的任务依赖。甚至在跨项目的工作流中，也可以通过这种方式进行配置。

有些人可能会问：为什么我们不在同一个工作流里解决依赖关系？

这是因为，在像 Apache DolphinScheduler 或 Airflow 这样的开源调度工具中，调度的属性是在工作流级别上定义的，而不是任务本身。

如果两个任务之间存在依赖关系，但它们的调度周期不同，就需要通过跨工作流依赖来解决。

这里已经涉及到了一些概念，任务的调度周期、依赖的周期以及依赖失败的处理策略都是非常重要的概念。这些将在后续部分中跟大家详细讲解。

跨工作流依赖的存储方式

在 Apache DolphinScheduler 中，dependent task 作为任务插件被存储在数据库中。在数据库的 task parameters 中，会有相应的刚才在上图看到的对应的项，保存了与依赖任务相关的配置参数。

例如，dependent type 可以指定为 dependent on task，表示依赖于跨工作流中的具体任务。还有另一种形式是 all task，即依赖于整个工作流的执行结果。

当前 DolphinScheduler 中的跨工作流依赖管理还存在一些复杂性。这边详细去讲的话，又会有其他的情况。

比如在生产环境中，某些用户希望判断工作流实例中每个任务的成功与否，这需要通过手动组合多个依赖项来实现。虽然目前还没有一键依赖所有任务的功能，但通过 dependent task 中的逻辑组合按钮，我们可以实现复杂依赖关系的配置。

技术细节

在跨工作流依赖的实现中，Apache DolphinScheduler 通过多个唯一标识符来管理项目、工作流和任务。

这些标识符包括 project code、definition code 和 task code，它们分别对应项目名称、工作流名称和任务名称。这些唯一标识符是由后台自动生成的，用于识别跨工作流的依赖关系，确保各项任务之间的依赖能够准确生效。

Airflow的跨工作流依赖

除了 Apache DolphinScheduler，Apache Airflow 中也可以通过Sensor来实现跨工作流依赖实现。