4. 任务依赖关系建模：上下游任务定义、依赖条件设置与传递阻断

依赖关系建模，说白了就是给任务排个「谁先谁后」的规矩。你想想看，数据湖里几十上百个任务，要是没个依赖约束，跑起来肯定乱套。我刚开始做调度系统时，就吃过这个亏——一个下游任务在上游还没写完数据时就启动了，结果整张报表全是脏数据。

这一章，我们就来聊聊怎么把依赖关系理清楚。我会从最基础的上游下游定义讲起，再到依赖条件的设置，最后说说依赖传递和阻断这些进阶玩法。

4.1 上下游任务的定义

先明确一个基本概念：上游任务是数据的生产者，下游任务是数据的消费者。听起来简单，但实际建模时有很多细节。

我个人习惯把任务依赖分为两种类型：

• 强依赖：下游必须等上游完成，缺了就不能跑。比如ODS层没写完，DWD层不能启动。
• 弱依赖：下游可以不等上游，或者只等一部分。比如两个独立的统计任务，谁先跑完都行。

在实际项目中，我见过不少团队把依赖关系搞得太复杂。其实有个简单的判断标准：如果下游任务读取了上游任务产出的数据，那就是强依赖。否则，尽量用弱依赖。

4.2 依赖条件设置

依赖条件不只是「上游跑完就行」。我遇到过的情况是：上游任务跑完了，但结果是失败的，下游还傻乎乎地启动，最后产出一堆错误数据。所以，依赖条件必须精细化管理。

4.2.1 成功依赖

这是最常见的依赖条件。下游任务只在上游任务成功结束后才启动。

// 伪代码示例：成功依赖判断
if upstream_task.status == "SUCCESS":
    downstream_task.allow_start()
else:
    downstream_task.wait()

嗯，这里要注意：成功依赖不能只看任务状态码。我曾经遇到过一个任务，状态码返回了SUCCESS，但实际数据只写了一半——因为任务在最后一步提交事务时出了问题。所以，我建议在成功依赖之外，再加一层数据完整性校验。

4.2.2 失败依赖

失败依赖听起来有点反直觉——为什么要等一个失败的任务？其实场景很明确：容错和补偿。

举个例子，数据湖里有个「数据质量监控任务」，它专门检查数据异常。如果发现异常，它会标记为失败，然后触发一个「数据修复任务」。这个修复任务依赖的就是监控任务的失败状态。

// 失败依赖示例
if upstream_task.status == "FAILED":
    repair_task.allow_start()  // 触发修复流程
else:
    repair_task.skip()         // 数据正常，无需修复

我曾经在一个金融数据湖项目里用过这个模式。上游的「交易对账任务」如果失败，下游的「异常交易告警任务」就会启动。这个设计帮我们提前发现了不少问题。

4.2.3 超时依赖

超时依赖是个容易被忽略的点。任务跑太久怎么办？不能一直等下去吧。

我建议给每个任务设置一个超时阈值。如果上游任务在指定时间内没完成，下游可以选择：

• 跳过依赖：下游用历史数据或默认值继续跑
• 触发告警：通知运维人员介入
• 自动重试：重新调度上游任务

4.3 依赖传递与阻断

依赖传递是个双刃剑。用好了，能自动管理复杂的任务链条；用不好，一个小故障会引发雪崩。

4.3.1 依赖传递机制

依赖传递的意思是：如果A依赖B，B依赖C，那么A间接依赖C。当C失败时，B和A都会受到影响。

我画了一张图来说明这个关系：

你看，任务C失败后，如果没有阻断机制，B和A都会被阻塞。但如果在B层设置了阻断，A就可以继续运行——当然，前提是A不依赖B的实时数据。

4.3.2 阻断策略

我常用的阻断策略有三种：

策略	说明	适用场景
硬阻断	上游失败后，下游直接跳过该依赖，使用默认值或历史数据	非关键路径上的任务，比如报表中的辅助指标
软阻断	上游失败后，下游继续等待，但触发告警	核心链路，需要人工介入判断
条件阻断	根据失败原因决定是否阻断。比如数据源不可达时阻断，数据格式错误时不阻断	有丰富错误码和异常处理机制的系统

4.4 实战：依赖建模的避坑指南

讲了这么多理论，我来分享几个实际踩过的坑。

坑一：循环依赖

我曾经在一个ETL流程里，不小心把A依赖B、B依赖C、C又依赖A的循环依赖给配出来了。结果调度系统直接死锁，所有任务都卡住不动。后来我养成了一个习惯：在依赖建模完成后，用拓扑排序检查一遍，确保没有环。

坑二：过度依赖

有些同事喜欢把所有任务都串起来，觉得这样「安全」。其实过度依赖会让调度效率极低。我见过一个案例，明明两个任务可以并行跑，但因为依赖关系配得太细，硬是串行执行，每天多花了半小时。

坑三：忽略依赖的时效性

依赖关系不是一成不变的。数据湖的schema会变，数据源会变，业务逻辑也会变。我建议每季度review一次依赖配置，把那些已经不需要的依赖清理掉。