1. 任务依赖管理概述
大家好，我是老赵。做数据调度这些年，我见过太多因为依赖关系没理清而导致的线上事故。今天咱们就从最基础的概念聊起——任务依赖到底是什么，为什么它值得你花时间认真对待。
什么是任务依赖
说白了，任务依赖就是「这个任务跑之前，必须先跑完那个任务」。举个例子，你想想看，数据湖里的 ETL 流程：你得先等源数据落地，才能做清洗；清洗完了，才能做聚合；聚合完了，才能写入结果表。每一步都踩着上一步的脚印走。
我在项目中遇到过最典型的场景：一个离线数仓任务，每天凌晨 2 点启动，结果上游的日志采集任务因为网络抖动延迟了 40 分钟。下游任务傻乎乎地按时启动了，读到的全是空数据，整张报表报废。嗯，这就是没有依赖管理的后果。
核心定义：任务依赖是指一个任务的启动或执行结果，必须满足某些前置条件（通常是上游任务的成功完成），才能继续执行。
为什么需要任务依赖管理
你可能会问：「我手动等一等不行吗？」行，但只限于你有 3 个任务的时候。一旦任务数量上了两位数，手动管理就是灾难。
我总结了几条必须上依赖管理的理由：
- 避免数据空洞——下游任务不会在上游数据还没准备好的时候启动，防止产出「半成品」数据
- 提升资源利用率——任务按依赖顺序排队执行，不会出现多个任务抢资源导致集群雪崩
- 故障自动传导——上游挂了，下游自动等待或告警，不用人工盯着看
- 可回溯可重跑——某一天的数据出问题了，可以按依赖关系精准重跑，不用全量回刷
我的经验：曾经有个项目，300 多个任务没有依赖管理，全靠 cron 表达式硬排时间窗口。结果每天凌晨总有 5-6 个任务因为时间窗口重叠而互相阻塞。后来我花了两周把依赖关系梳理清楚，换成了 DAG 调度，集群利用率直接提升了 40%。
常见依赖类型
依赖关系不是只有「你等我」这一种。实际生产中，我遇到过至少三种主流模式。下面这张图可以帮你快速建立整体认知：
DAG 依赖（有向无环图）
这是现代调度系统的标配。DAG 允许一个任务有多个上游和多个下游，形成网状结构，但不能有环——有环就意味着死循环。
我习惯把 DAG 想象成「任务地铁图」。每个站（任务）可以换乘到多条线路，但方向是固定的，不能坐回头车。实际生产中，一个中型数据湖的 DAG 可能有 500-2000 个节点，靠人工根本理不清，必须依赖调度引擎自动解析。
避坑指南：我曾经接手过一个项目，DAG 里被人偷偷塞了一个循环依赖——任务 A 等 B，B 等 C，C 又等 A。调度系统直接卡死，所有任务都处于「等待中」状态。排查了整整一天才找到这个「环」。所以，所有 DAG 调度器都必须做环检测，这是底线。
线性依赖
线性依赖是 DAG 的一种特例——每个任务只有一个上游和一个下游，形成一条直线。说白了就是「流水线作业」。
这种模式在简单的 ETL 流程里很常见。比如：
数据采集 → 数据清洗 → 数据转换 → 数据加载 → 数据校验线性依赖的好处是简单直观，出了问题好排查。坏处是并行度低——整条链上只有一个任务在跑，后面的都得等着。我一般建议：如果任务链超过 5 个节点，就考虑拆成 DAG 来提升效率。
条件依赖
条件依赖就更有意思了——下游任务跑不跑，取决于上游任务的执行结果。这就像代码里的 if/else 逻辑。
我举一个真实案例。在数据质量监控场景中：
- 上游任务做数据质量检查，输出一个「通过/不通过」的状态
- 如果通过，下游执行正常的写入流程
- 如果不通过，下游走告警+重试分支，甚至触发数据修复任务
条件依赖在自动化运维里特别有用。你可以用它实现「失败自动重试 3 次，仍失败则发钉钉告警」这样的逻辑。
| 依赖类型 | 核心特点 | 适用场景 | 复杂度 |
|---|---|---|---|
| DAG 依赖 | 多分支、多层级、无环 | 复杂数据管道、多源汇聚 | 高 |
| 线性依赖 | 串行执行、一条链 | 简单 ETL、小规模流程 | 低 |
| 条件依赖 | 根据结果选择分支 | 数据质量、异常处理 | 中 |
我的建议：刚开始做任务依赖管理时，别一上来就搞复杂的 DAG。先从线性依赖入手，把流程跑通。等你对业务数据的上下游关系摸透了，再逐步引入分支和条件判断。我见过太多团队一上来就画了一个「完美」的 DAG，结果上线第一天就崩了——因为有些依赖关系根本就是错的。
好了，这一章我们聊了任务依赖的基本概念、为什么需要它，以及三种最常见的依赖模式。这些是后续所有调度实践的基础。记住一句话：依赖关系理不清，调度系统就是个定时炸弹。