调度系统基础：核心概念与常见框架

调度系统，说白了就是数据任务的“交通指挥中心”。你想想看，一个数据平台每天要跑几百上千个任务，谁先谁后、失败了怎么办、资源不够怎么排队——这些都得靠调度系统来管。我做了这么多年调度，见过太多因为调度设计不合理导致的线上事故，所以这一章咱们把基础打扎实。

一、调度系统的三个核心概念

不管你用哪种调度框架，这三个概念都是绕不开的。我习惯把它们称为调度系统的“三驾马车”。

1. DAG（有向无环图）

DAG 是调度的骨架。每个任务是一个节点，依赖关系是一条有向边，整个图不能有环——有环就意味着死循环。

我在项目中遇到过一个问题：业务方画 DAG 时不小心连了个环，结果调度器一直在循环触发，把集群打满了。嗯，从那以后我要求所有 DAG 提交前必须做环检测。

2. 任务实例

任务实例是 DAG 的一次具体运行。同一个 DAG，每天跑一次，就会生成一个实例。实例有状态：等待、运行中、成功、失败、重试中……

我个人习惯把实例状态机画在墙上，每次排查问题就看当前实例卡在哪个状态。说白了，调度系统的大部分 bug 都出在状态转换上。

3. 调度周期

调度周期就是任务多久跑一次。常见的周期有：分钟级、小时级、天级、周级。但这里有个坑——调度时间和业务时间是两码事。

概念	说明	常见问题
DAG	任务依赖关系图	环检测、并行度控制
任务实例	DAG 的一次运行记录	状态机设计、幂等性
调度周期	任务触发的时间间隔	调度时间 vs 业务时间

二、常见调度框架对比

市面上调度框架很多，但真正在生产环境大规模使用的，也就那么几个。我挑三个最有代表性的来说。

1. Apache Airflow

Airflow 是 Python 生态里最火的调度框架。它的 DAG 是用 Python 代码定义的，灵活性很高。我早期做数据平台时用过一段时间，社区活跃，插件丰富。

但 Airflow 有个硬伤——调度器是单点的。任务量一上来，调度器就容易成为瓶颈。我记得有一次线上 5000 多个 DAG，调度器直接卡死了，重启了三次才缓过来。

# Airflow DAG 示例
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime, timedelta

default_args = {
    'owner': 'data_team',
    'depends_on_past': False,
    'start_date': datetime(2024, 1, 1),
    'retries': 3,
    'retry_delay': timedelta(minutes=5)
}

dag = DAG(
    'data_backfill_dag',
    default_args=default_args,
    schedule_interval='0 2 * * *',  # 每天凌晨2点
    catchup=False  # 回填场景下要设为 True
)

2. Apache DolphinScheduler

DolphinScheduler 是国产调度框架，去中心化架构，支持多 Master 多 Worker。我后来迁移到它，主要看中两点：一是原生支持补数（回填），二是 UI 操作比 Airflow 友好。

它的 DAG 是可视化拖拽生成的，对业务同学比较友好。但说实话，我更喜欢代码定义 DAG，因为版本控制方便。不过 DolphinScheduler 也支持用 YAML 定义工作流，算是个折中方案。

特性	Airflow	DolphinScheduler	自研系统
架构	中心化（Scheduler 单点）	去中心化（多 Master）	视设计而定
DAG 定义	Python 代码	可视化 / YAML	自定义 DSL
回填支持	catchup 参数	原生补数功能	需自研
社区活跃度	高	中	无
适合场景	中小规模、Python 技术栈	大规模、Java 技术栈	定制化需求强

3. 自研调度系统

当业务规模大到一定程度，开源框架可能撑不住。我上一家公司就自研了一套调度系统，核心原因有两个：一是 Airflow 调度器扛不住万级 DAG，二是回填场景需要定制化的限流和优先级策略。

自研调度系统的难点不在于写代码，而在于设计。我见过太多自研调度系统，功能没做全，bug 倒是一堆。如果你团队没有 3 个以上懂调度的工程师，我建议还是先用开源框架。

三、调度系统的核心知识体系

下面这张图是我自己总结的调度系统知识体系，涵盖了从底层到上层的核心模块。你可以把它当作学习路线图。

四、如何选择调度框架

这个问题我经常被问到。我的建议是：先看团队技术栈，再看业务规模，最后看回填需求。

• 团队是 Python 技术栈：选 Airflow，学习成本低，社区资源多。
• 团队是 Java 技术栈，规模中等：选 DolphinScheduler，原生支持补数，运维省心。
• 规模大、定制化需求强：考虑自研，但要做好长期维护的准备。