第四章：Job设计与调度

第四章：Job设计与调度

本章要回答的三个问题

• 作业和转换在职责上怎么分

• 作业里有哪些常用条目可以编排

• 失败了怎么兜底而不是整条崩溃

为什么单独设这一章

转换管数据，作业管事情。很多管道跑不稳，是因为该用作业兜的地方用了转换硬扛。这一章把编排讲透，是生产可靠性的基石。

读完能解决什么

读完后你能用作业把多个转换、系统命令、邮件告警串成一条可重试、可观测的流水线，并设计出错时的兜底分支。

各节分工

先决条件

需要第三章的转换基础，因为作业里大部分条目就是「跑一个转换」。请准备把前面画的小转换串起来。

往下走到哪

作业解决编排，第五章解决「连什么源什么目标」，两者结合才能落地真实项目。

本章常见误区

误区一：用转换处理「先干 A 再干 B 再判断」的控制流。控制流是作业的地盘，转换只管数据流水，混用会让图既难读又难重试。

误区二：忽略作业条目的成功率与退出码。一个 Shell 条目即使脚本内部失败，若退出码没正确返回，作业会误判成功，埋下静默失败隐患。

误区三：不做错误处理，任由任一环节失败就整条中断。生产作业必须配错误处理与重试，否则一次临时网络抖动就能让整夜任务白跑。

与邻章边界

第四章编排作业，但作业里真正干数据活的还是第三章的转换（通过「转换」条目调用）。错误处理的具体重试参数在本章，而「转换内部为何慢」在第六章，部署运行在第九章。

速查清单

• 作业结构：起始、条目（转换/Shell/SQL/邮件等）、hop 连线、条件分支
• 条目类型：转换、SQL、Shell、文件存在判断、发送邮件、检查表是否存在
• 错误处理：条目级「忽略错误」「重试次数」「重试间隔」
• 变量：作业级变量可下传给被调用的转换
• 日志：作业日志级别与文件落盘是排错依据

本章能产出的能力

读完你能把一组转换与运维动作（校验、告警、清理）编成一个可重试、可监控的作业流水线。你还能为关键条目配置错误兜底，让临时故障自动恢复，而不是半夜被一条失败短信叫醒。

为什么这一章不能跳过

只用转换不用作业，你就没有「先抽数、再校验、失败就告警」的兜底。我们见过生产管道因为没编作业，一次网络抖动就让整夜任务白跑、早上才发现。作业是让管道「自己照顾自己」的关键。

本章最小上手练习

把上一章的转换用「转换」条目放进作业，后面接一个「SQL」条目做行数校验，校验失败走失败分支发邮件。这条链路跑通，你就拥有了第一个可重试、可告警的流水线。

自测：你真的懂了吗

• 能否画出含成功/失败两条分支的作业
• 能否为关键条目配置重试次数与间隔
• 能否讲清转换条目与 Shell 条目的退出码如何影响作业走向

本章在你项目里的落点

把本章用到实处，第一件事是新建一个作业，用「转换」条目调用你已有的转换，再接一个 SQL 条目做行数校验，校验不过就走失败分支发邮件。这一步做完，你的管道就从「能跑」变成「会自己报警」。第二件事是给关键条目配重试，应对夜间偶发的网络抖动。这两步不依赖任何新组件，却立刻把健壮性拉满。

补充：作业设计的第一性原理是「先想清失败怎么办，再想成功怎么走」。每条成功线画完，立刻补一条失败线连告警，这一步的成本几乎为零，却能在深夜救你一次。