在数据驱动系统（如分析平台）中，一个常见的挑战是管理数据管道之间的依赖关系。
这些平台通常包含位于不同数据层或数据区（例如：数据摄取、数据增强、数据聚合）的数据管道，每个数据层都依赖于上游数据层的数据管道成功完成后才能运行。
虽然近年来实时流式处理数据管道越来越受欢迎，但在许多应用场景下，企业仍然依赖于基于批处理的数据处理方式，尤其是在分析系统中。
在使用 ELT（提取、加载、转换） 或某些架构称之为 ELETL 模式的数据仓库或数据湖架构中，第一批数据管道（提取部分）通常负责从源系统收集数据，并将其摄取到中央数据湖的 落地（Landing） 或原始（Raw） 数据区/数据库中。
这些摄取管道通常根据合适的事件或时间调度执行。下游数据管道则会使用上游管道生成的数据，以进行数据增强、转换和聚合，以支持不同的应用和分析场景。
图1：数据湖摄取模式
然而，这里要考虑一个重要的设计因素，即如何最佳地管理这些相互依赖的数据管道。
接下来，我们将介绍几种管理数据管道依赖关系的技术。从完全解耦的方案开始，逐步增加数据管道之间的耦合程度。
技术方案1：仅依赖时间调度
在这种技术方案中，每个数据管道仅根据时间调度执行，而不会管理与其他数据管道的依赖关系。
例如，如果上游管道每小时运行一次（如 13:00 运行），并且预计需要 20 分钟完成，那么下游管道可以安排在每小时的 30 分（例如 13:30）运行。
图2：基于时间的管道依赖关系
优点：
- 下游和上游管道之间没有耦合或依赖管理。
- 每个管道仅依赖系统时钟时间来运行。
- 不同管道无需了解上游或下游的状态（自管理）。
- 不同管道可以具有不同的执行时间窗口，而不会影响其他工作流。
- 不同团队或开发人员可以独立开发各自的数据层和数据管道。
缺点：
- 由于数据管道完全解耦，如果上游管道运行失败或延迟，下游管道仍然会执行，可能导致处理不完整或缺失的数据。因此，需要在上游管道成功重试或问题解决后重新运行当前任务。
- 上游管道的重试和重新处理不会自动与下游管道协调，需要人工干预。
技术方案2：依赖时间调度+上游管道信号
在此方案中，下游管道仍然按照 技术方案1 的方式进行时间调度，但它们仅在上游管道发出 成功完成 的信号后才会执行。
换句话说，下游管道会等待某种来自上游层的信号后才会开始下一次调度运行。
可能的信号机制包括：
- 在当前处理的数据分区中生成一个隐藏的空文件（例如
.success文件）。 - 在元数据表中插入一条记录。
- 通过事件总线推送通知。
此技术方案本质上为下游管道构建了 延迟逻辑，使其能够延迟执行，直到上游任务发出成功信号。
图3：基于时间 + 信号的管道依赖关系
优点：
- 下游和上游管道之间的耦合度较低，唯一的依赖是 约定的信号机制，例如在数据分区中生成隐藏文件。
- 下游管道仅在上游管道成功完成后才会执行，从而节省计算资源和成本（特别是在云环境中）。
- 如果上游管道延迟执行，下游管道会等待信号，避免在不完整或缺失数据的情况下运行，减少数据运维（DataOps）开销。
- 不同管道仍可保持不同的执行时间窗口，而不会严重影响其他工作流。
- 只要约定好信号机制，不同团队或开发人员仍可独立开发各自的数据层和数据管道。
缺点：
- 上游管道 重新运行 时，已经执行过的下游管道不会自动协调，因此需要手动通知或创建自动触发机制，以便在上游管道重新执行时触发下游管道的重跑。
技术方案3：依赖时间调度+上游管道完成状态
此方案类似于 技术方案2 ，不同之处在于，下游管道不使用 解耦的信号机制 进行工作流协调，而是采用 松耦合方式，直接等待上游管道完成后再启动自身运行。
这意味着，数据管道需要在同一个工作流管理系统中进行编排和管理。
图4：基于时间+上游完成的管道依赖关系
优点：
- 下游管道仅在上游管道成功完成后才会执行，从而节省计算资源和成本。
- 如果上游管道延迟执行，下游管道不会运行，避免处理损坏、不完整或缺失的数据，减少重复执行的需求。
- 如果 技术方案 #2 中的信号机制尚未实现，则无需额外的信号逻辑。
缺点：
- 数据管道层之间的耦合度提高，不同管道之间的依赖关系变得更紧密。
- 下游管道必须明确调用上游管道，并知道如何调用。
- 如果上游管道的名称或任务发生变化，下游管道也需要相应更新。
- 这种方案适用于所有管道运行在相同时间间隔的情况，例如，如果上游管道按小时运行，下游管道也应按小时运行，否则协调依赖关系会变得复杂。
技术方案4：顺序编排的管道
此方案与 技术方案3 类似，但区别在于，每个上游管道在完成后 直接触发 其下游管道，而不是让下游管道等待上游完成的信号。
图5：顺序编排的管道
优点：
- 下游管道仅在上游管道成功完成后才会执行，节省计算资源和成本。
- 避免了因上游管道延迟而导致的数据丢失或错误处理。
- 适用于 同一个团队 负责端到端数据工作流编排的情况。
缺点：
- 不同层次管道之间更加紧密耦合，管道之间的依赖性增加。
- 上游管道必须了解其直接下游管道的相关信息，包括需要调用哪些下游管道以及如何调用这些依赖管道。
- 与之前的技术不同，当新增下游消费者时，上游管道必须进行修改，以便在完成自身运行后触发新的管道。
- 对下游管道的更改（例如修改管道名称）可能会影响上游管道，因为上游必须相应地进行更新。
- 可能需要反馈循环来确定下游作业是否已启动。
- 与之前的技术类似，使用此技术可能需要下游管道采用相同的时间间隔运行。例如，如果父管道按小时运行，那么下游管道理想情况下也应每小时运行一次。
- 由于不同层次的数据管道之间耦合性增强，独立处理每个数据层的工作可能会变得具有挑战性。
当添加多个下游层和集成管道时，这种模式会变得更加复杂。在管理多个下游管道时，要么采用顺序协调的方式（即每个管道仅触发其直接下游管道），要么如图6所示，所有下游管道都由顶层的父管道统一管理和触发------在这种情况下，需要反馈循环来确认某个管道何时完成，以便执行其后续依赖管道。
图6：顺序编排替代方案
要注意，为了让工作流程具有确定性，意味着整个工作流及其依赖的数据管道在每次运行或使用相同输入重新执行时都必须产生相同的结果。
Apache DolphinScheduler：技术方案3+技术方案4
Apache DolphinScheduler 作为一款广受欢迎的大数据任务调度，其任务依赖机制主要符合 "技术方案3-依赖时间概念和上游任务完成" 和 "技术方案4-顺序编排管道" 这两种方式，从而达到了更优的任务依赖管理能力。具体如下：
-
时间+上游任务完成（技术方案3）
- DolphinScheduler 允许定义任务之间的依赖关系，下游任务可以等待上游任务执行完成后再启动。
- DolphinScheduler 的 "前置任务" (Predecessor Task) 机制 确保任务只有在其依赖的上游任务成功完成后才会执行。
- 这种方式可以保证下游任务不会在上游任务失败或延迟的情况下运行，从而避免数据不完整或错误的情况。
-
顺序编排（技术方案4）
- DolphinScheduler 主要是一个 DAG（有向无环图） 驱动的任务编排工具，所有任务按照 任务流 进行调度，上游任务执行完成后会自动触发下游任务执行。
- DolphinScheduler 具备 依赖自动触发 的能力，即上游任务完成后自动调用下游任务，而不是下游任务主动轮询上游任务状态。
- 这种方式更加紧密地绑定了任务之间的关系，适用于由同一个团队管理的完整数据工作流。
适用场景
- 如果数据流中的任务都是在 DolphinScheduler 内部管理的，并且需要依赖某个上游任务执行完毕才能触发下游任务，那么 DolphinScheduler 主要采用 技术方案 #3（时间+上游任务完成）。
- 如果整个数据管道是 端到端编排 （如数据提取、转换、加载、汇总等所有任务均在 DolphinScheduler 统一调度），则 DolphinScheduler 采用的是 技术方案 #4（顺序编排）。
额外机制
除了以上提到的技术方案，DolphinScheduler 还支持 条件判断、失败重试、任务补数 等功能，可以进一步增强任务依赖管理的能力。
对于 跨系统的任务依赖，DolphinScheduler 也可以通过 API 触发外部任务，或者监听某些外部事件（如文件生成、数据库记录等）来决定是否执行任务。
综合来看，DolphinScheduler 的任务依赖管理方式属于 技术方案3和4的结合，同时结合了工作流调度、依赖管理和自动化触发等特性，使其在大规模数据处理场景中更加灵活和高效。
结论
本文介绍了几种常见的 数据管道依赖管理 技术，每种方案都有不同程度的耦合性、操作复杂度和工作流管理需求。根据具体的 使用场景 和 环境，应选择最合适的方案。