4.1 Job基本结构与执行流程

4.1 Job基本结构与执行流程

作业是一张「做事顺序」的图

本篇是第 4 章第 1 节，动手编排的起点，先讲清作业由什么构成、和转换有何不同。

作业由「作业条目 job entry」和「连接 connection」组成。条目是动作单元：跑转换、执行 Shell、发邮件、建目录等；连接是带条件的箭头，如「成功则」「失败则」「无条件」。我们强调：作业不处理行数据，它只决定「下一步做什么」。

执行上，作业默认单线程按依赖走。一个「转换」条目被触发时，Kitchen 会起一个子进程跑 Pan，跑完回收。所以作业是轻调度、重编排，真正的算力在它派生的转换里。我们排错时先看作业卡在哪个条目，省去在转换里瞎找。

作业支持嵌套：一个作业条目可以是一个子作业。我们用它做「分层编排」——顶层作业管「日终全流程」，子作业管「订单域」「用户域」。这样 domain 负责人各自维护子作业，顶层只拼装，权责清晰。

「START」是作业的入口，所有流程从它发端；「成功」「失败」「结束」是终态节点。我们规定每个作业必须有显式的失败终态处理，不能让错误默默结束，否则监控发现不了。

变量作用域也在这里体现：作业级变量可被其下所有转换继承。我们在作业开头用「设置变量」统一注入运行日期，下游转换直接 ${p_day} 取值，避免每个转换各自解析。

关键代码与配置

下面这段 xml 给出了可直接落地的配置，输入来自上一步、输出写入目标端：

<job>
  <entry><name>抽取</name><type>TRANS</type><filename>extract.ktr</filename></entry>
  <entry><name>汇总</name><type>TRANS</type><filename>agg.ktr</filename></entry>
  <entry><name>导出</name><type>TRANS</type><filename>export.ktr</filename></entry>
  <connection><from>抽取</from><to>汇总</to><condition>success</condition></connection>
  <connection><from>汇总</from><to>导出</to><condition>success</condition></connection>
</job>
​

三个转换串成成功链，是作业的骨架。我们日常管道 90% 是这种「转换接转换」的结构。

# 用 Kitchen 跑作业，注入运行日
kitchen.sh /file:nightly.kjb -param:p_day=2026-08-25 -level:Basic
# 退出码非0表示作业失败，可触发告警
​

作业级退出码是调度系统的依据。我们让 CI/定时任务严格检查退出码，非 0 即告警，绝不静默。

背景

有人想让「抽取完再汇总」，却在一个转换内部用跳连两个逻辑，结果两者并行执行，汇总读到了空表。

操作

拆成两个转换，用作业条目串行编排，成功才进下一步。

<connection><from>抽取</from><to>汇总</to><condition>success</condition></connection>
​

结果

顺序被显式锁定，汇总永远在抽取之后，空跑消失。

解读

根因是混淆了「并行数据流」与「串行控制流」。转换内跳是并行的，顺序必须交给作业的 success 连接，这是职责边界。

变式

若两段都要并行加速，可保留在转换内；但只要存在依赖，就必须抬到作业层，这条原则不能破。

常见误区与工程取舍

误区：用转换跳表达顺序。跳是并行数据流，顺序交给作业 success 连接。

误区：作业里写数据处理。作业只编排，重活在派生转换。

取舍：顶层拼装子作业，domain 自管子作业，权责清晰易维护。

深入：作业的执行流怎么编排

作业是一张「控制流图」：从起始条目出发，通过 hop 连到各个作业条目（转换、SQL、Shell、邮件等），并按成功/失败分支决定走向。与转换的行级流水不同，作业是「条目级」的——一个转换条目跑完（无论处理多少行）才整体成功或失败，再触发下一个。这让作业适合表达「先抽数、再清洗、再校验、最后发通知」这类有先后依赖的运维流程。编排时把「可独立」的环节串行排好，把「必须成功才继续」的加错误分支。

# 作业里常调一个转换条目，等价于在 Kitchen 中执行（输入：.kjb；输出：按 hop 顺序执行各条目）
kitchen.sh /file:/jobs/etl_daily.kjb -param:p_day=2026-08-25
# 作业内部：转换条目(抽数) --成功--> 转换条目(清洗) --成功--> SQL条目(校验) --成功--> 邮件条目(通知)
​

⚠️ 常见坑（Job 结构）

• 把数据流逻辑写进作业：作业管控制流，数据流水交给转换条目。
• 忽略分支：只连成功线，失败时整条静默中断无告警。
• 条目退出码不核对：Shell 内部失败但返回 0，作业误判成功。

💡 关键直觉

• 作业是「剧本」，转换是「演员」；剧本安排顺序与兜底，演员负责把数据演完。
• 凡是「先做 A 再看结果决定 B/C」的，都是作业的地盘，别用转换硬凑。

工程实录：把数据管道编成作业

转换能跑，但没人定时跑、失败无人知。

用作业把抽数、清洗、校验、通知串成有序控制流。

kitchen.sh /file:/jobs/etl_daily.kjb -param:p_day=2026-08-25
# 内部：转换(抽) -> 转换(洗) -> SQL(校验) -> 邮件(通知)
​

首次实现每日自动跑批与失败告警。

作业是剧本，转换是演员；剧本管顺序与兜底。

多转换并行段用作业里并行 hop，缩短总时长。

参数与阈值速查