数百个ETL作业的依赖关系怎么管理？
先说结论
作业调度的三个核心原则：
① 依赖形成DAG： 所有作业的依赖关系形成一个有向无环图。上游作业成功后才触发下游。绝不允许用固定时间触发（比如“每天凌昨3点跑”），因为上游可能延迟。
② 分层调度： ODS先跑，DWD依赖ODS，DWS依赖DWD，ADS依赖DWS。严格禁止跨层依赖（比如ADS直接依赖ODS），否则依赖关系会乱成一团。
③ 失败重试 + 告警： 作业失败自动重试（我们配置的是重试3次，间隔5分钟），超过3次发告警并阻断下游。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
当你的数仓只朎10个作业时，手动排序就行。但当作业数达到数百个时，调度设计就成了核心问题。谁先跑谁后跑、失败了怎么办、怎么保证SLA，这些都是生产环境的实际问题。
业务场景：我们的调度架构
我在三家公司用过三种调度工具，思路完全一样：
元宇宙社交App： Airflow。用Python定义DAG，每个Task是一个Hive SQL作业。灵活但需要自己写代码。
出海硬件公司： Databricks Workflows。和Databricks深度集成，配置简单。
当前短剧出海公司： 阿里云DataWorks。可视化配置依赖关系，上手快。
工具不同但思路一样：DAG依赖 + 分层调度 + 失败重试告警。理解了思路，换工具也不怕。
实战踩坑：循环依赖
我在元宇宙社交App时遇到过一个坑：某个同事写了一个作业，A表依赖B表，B表又依赖A表的昨天分区。逻辑上看起来没有循环（因为是不同分区），但Airflow认为这是循环依赖，拒绝启动。
解决方案：把B表的依赖仏A表改为A表的DWS层汇总表（已经提前算好的），打破了循环。教训：设计依赖时一定要严格按分层来，不要跨层依赖。
面试加分：SLA保障
面试官可能会追问：“怎么保证报表每天早上8点前出数？”
我的做法：从最终产出时间倒推，算出每个作业的“最晚开始时间”。如果某个作业超过这个时间还没开始跑，就提前告警。而不是等到早上8点才发现数据没出。
总结
三个核心：DAG依赖、分层调度、失败重试告警。面试时能说清楚自己用过什么工具、怎么管理的、遇到过什么坑，就很实在。
下一篇聊Hive到云平台的迁移——从自建EMR到Databricks/MaxCompute，有哪些坑？
你们用的什么调度工具？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长