📚 课程目录第1章任务调度概述

1. 任务调度概述：什么是任务调度、应用场景与核心概念

大家好，我是你们这趟课程的老朋友。今天咱们聊聊任务调度——这个听起来有点枯燥，但实际工作中天天打交道的家伙。

先问个问题：你有没有半夜被电话吵醒过？「线上ETL跑挂了，明早报表出不来」。我有过，还不止一次。那时候我就想，要是调度系统能再聪明一点，我就能多睡几个小时了。

好，不扯远了。咱们正式开讲。

任务调度，说白了就是「让计算机在正确的时间，按正确的顺序，执行正确的任务」。

你可能会说：「这不就是crontab吗？」嗯，对了一半。单机上的定时任务确实算调度，但咱们今天聊的，是分布式环境下的任务调度——几十上百个任务，跑在成百上千台机器上，还要处理失败重试、依赖关系、资源分配……这复杂度就不是一个crontab能搞定的了。

我个人习惯把任务调度拆成三个维度来看：

这三个维度，就是调度系统的核心骨架。后面咱们会一个一个拆开讲。

一句话总结：任务调度 = 时间 + 资源 + 依赖关系的组合管理。

你想想看，哪些地方离不开任务调度？我随便列几个，你肯定都遇到过。

这是调度系统最经典的战场。每天凌晨，从业务库抽数据，清洗转换，最后加载到数仓。一个典型的ETL流程可能是这样的：

1. 从MySQL抽取订单表（抽）
2. 清洗空值、去重、格式统一（洗）
3. 关联用户维度表（转）
4. 写入Hive分区表（载）
5. 触发下游报表计算（推）

我在项目中遇到过，有个团队把ETL全写在shell脚本里，用crontab串起来跑。一开始还行，后来数据量大了，某个步骤一卡，后面全崩。关键是——你根本不知道崩在哪一步。那叫一个酸爽。

数据管道和ETL有点像，但更强调「流式」和「实时」。比如：

这种场景下，调度系统不光要管「什么时候跑」，还得管「数据到了没有」。依赖关系变得更动态了。

代码提交后，自动触发编译、单元测试、集成测试、打包、部署。每一步都有严格的依赖关系：

代码提交 → 编译 → 单元测试 → 代码扫描 → 打包 → 部署测试环境 → 集成测试 → 部署生产

我记得有一次，CI流水线里测试和部署是并行跑的，结果部署完了测试还没跑完……嗯，线上出了个低级bug。从那以后，我对依赖关系的设计就特别较真。

场景	典型任务数	依赖复杂度	失败容忍度
ETL	50~500	中	高（可重跑）
数据管道	10~200	高（动态依赖）	中（需保序）
CI/CD	5~50	中	低（失败即阻断）

好，接下来是重点。这三个概念，你搞懂了，后面30章就轻松一半。

任务就是调度系统里的最小执行单元。它可以是一个shell命令、一段Python脚本、一个Spark作业，甚至是一个HTTP调用。

每个任务通常包含：

我的经验：给任务设置超时时间，是个好习惯。我曾经见过一个任务跑了72小时没结束，把整个集群的资源都吃光了。从那以后，我每个任务都强制设超时。

依赖就是「任务A必须在任务B之前完成」。听起来简单，但实际坑很多。

依赖分几种：

你想想看，这三种依赖混在一起，调度系统该怎么处理？嗯，这就是咱们这门课要解决的核心问题。

DAG是描述任务依赖关系的数据结构。有向——任务之间有方向；无环——不能出现循环依赖。

为什么不能有环？因为如果A依赖B，B依赖C，C又依赖A……那谁先跑？死锁了。调度系统会直接报错。

下面这张图，就是一个典型的ETL DAG：

你看，数据抽取是根节点，它完成后同时触发清洗和转换。清洗完了才能加载，转换完了才能算报表。最后，加载和报表都完成后，才能做数据校验。

这就是DAG的魅力——把复杂的业务流程，变成一张清晰可执行的图。

注意：DAG里不能有环。我曾经见过一个新手把任务配成了A→B→C→A，结果调度系统直接拒绝执行。排查了半天才发现是配置写错了。

这一章咱们聊了三个事：