作业编排与依赖是什么
编排解决的是多个作业之间「谁先谁后、什么时候可以开始」。主流做法是把关系表达成依赖图：每个作业声明它依赖哪些上游，调度器在上游成功后触发下游，上游失败时按策略阻塞或跳过下游。要点有三：依赖必须显式声明，不能靠把两个任务的时间错开来隐含假设顺序；依赖图必须做环检测，否则调度器会反复触发或永不触发；跨系统的依赖还需要统一的状态回传，否则上游成功下游并不知道。
基本信息
| 常见工具 | Apache Airflow、DolphinScheduler、Control-M、Jenkins Pipeline、Kubernetes Job 配合外部编排 |
|---|---|
| 依赖表达 | depends_on 声明、上下游任务清单、信号文件、消息触发、状态表 |
| 必须检查 | 环形依赖、缺失上游、被跳过或失败的上游 |
| 核心要求 | 上游失败时下游必须被阻塞，不能默认继续 |
典型使用场景
- 数据管道：抽取完成后再做转换与装载
- 发布流程：数据库迁移完成后再启动应用
- 巡检作业：采集全部完成后才生成报告
- 跨团队协作：上游批次产出文件后再触发下游处理
- 定时任务之间存在隐含顺序时，改造为显式依赖
依赖表达与反例
依赖表达与反例
# 下游只在全部上游成功后触发，上游失败时阻塞
job: load
depends_on: [extract, validate]
on_upstream_failure: block
job: extract
schedule: "0 2 * * *" # 只有起点作业携带时间
# 反例：两个任务只靠时间错开
# 02:00 抽取，02:30 装载 —— 抽取变慢时装载会读到不完整数据依赖表达方式对比
| 表达方式 | 适用场景 | 主要风险 |
|---|---|---|
| 依赖图声明 | 同一编排平台内的作业 | 依赖环与缺失上游需要校验 |
| 信号文件 | 脚本之间的轻量协作 | 残留文件导致误判就绪 |
| 消息触发 | 跨系统解耦 | 需处理重复投递与丢失 |
| 时间错开 | 简单且稳定的场景 | 上游变慢即失效 |
| 数据库状态位 | 需要审计与追溯的流程 | 需处理并发写与状态清理 |
编排的价值在于把「顺序」变成可检查的对象：能画出依赖图、能检测环、能在上游失败时明确下游该做什么，而不是依赖运维人员的记忆和时间间隔。
上游失败却让下游照常运行，往往比整体不运行更危险：下游基于残缺数据产出结果，并被写入下游系统继续扩散，事后清理成本远高于一次任务失败。