4.2 Job条目类型

4.2 Job条目类型

作业工具箱里到底有哪些原语

本篇是第 4 章第 2 节，盘点最常用的作业条目，是画作业时「选哪个元件」的参考手册。

「转换」条目（TRANS）用来跑一个 .ktr，是作业里出现最多的。我们约定每个原子数据处理都做成独立转换，作业只负责把它们按顺序或条件串起来，这样单测和复用都方便。

「Shell 脚本」条目执行系统命令，常用于调用外部工具（如 gzip、scp）。我们用来在抽取前解压、抽取后传文件。但要小心：脚本失败要返回非 0，Kettle 才能识别，很多人忘了 exit 1 导致假成功。

「发送邮件」条目在成功或失败时通知人。我们把它挂在失败分支，让 oncall 第一时间收到；也挂成功分支做日报。邮件内容可带变量，如本次处理行数，便于快速判断。

「检查文件是否存在」「检查表是否存在」这类条件条目，用于做幂等前置判断。我们日终作业开头先检查目标分区是否已存在，存在则先清理再跑，避免重复数据。这是幂等设计的关键原语。

「设置变量」「获取变量」让作业成为参数的源头。我们在作业 START 后第一件事就是设运行日、设批次号，下游所有转换共享。这比在每个转换里各自算日期健壮得多。

关键代码与配置

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

<entry><name>解压</name><type>SHELL</type>
  <script>gunzip -f /data/in/orders.csv.gz</script>
</entry>
<entry><name>通知</name><type>MAIL</type>
  <subject>日终完成 行数=${row_cnt}</subject>
  <recipients>etl@corp.com</recipients>
</entry>
​

Shell 做前置解压、Mail 做收尾通知，是作业的常见两端。我们所有脚本都确保失败时 exit 非0。

<entry><name>检查分区</name><type>CHECK_TABLE_EXISTS</type>
  <tablename>dwd_orders_20260825</tablename>
</entry>
<connection><from>检查分区</from><to>清理</to><condition>true</condition></connection>
<connection><from>检查分区</from><to>抽取</to><condition>false</condition></connection>
​

条件条目实现幂等：分区在就先清，不在就直接抽。我们所有日终作业都带这道检查，重跑安全。

背景

作业里 Shell 解压命令写错路径，实际没解压成功，但脚本没显式 exit 1，Kettle 当作成功继续，下游读不到文件空跑。

操作

给 Shell 条目加 set -e 和末尾 exit $?，失败时让作业进入失败分支发邮件。

# Shell 条目脚本开头
#!/bin/bash
set -e
gunzip -f /data/in/orders.csv.gz
exit $?
​

结果

解压失败立刻触发告警，当天问题当发现，不再静默空跑。

解读

根因是「成功信号」不可靠。作业条目的退出码是编排正确性的命脉，外部脚本必须老老实实回报状态。

变式

更稳的做法是用「检查文件是否存在」条目在解压后验靶，双保险，连脚本忘了 exit 也能兜住。

常见误区与工程取舍

误区：Shell 不返回非0。外部命令必须显式回报状态，否则假成功。

误区：重复跑产生重复数据。用检查类条目做幂等前置。

取舍：原子处理拆成独立转换，作业只做串接与条件，结构才清晰。

深入：几类高频作业条目怎么用

「转换」条目调用一个 .ktr，是作业干数据活的主力；「SQL」条目执行库内语句，常用于建临时表、跑校验查询；「Shell」条目跑系统命令，适合调外部工具；「检查文件是否存在」「检查表是否存在」做前置守卫；「发送邮件」在成功或失败时通知。一个工程化习惯：把「校验」类条目放在关键步骤之后，校验不过就走失败分支发告警，而不是等下游投诉。

# Shell 条目示例：调用外部数据质量脚本（输入：当日数据目录；输出：退出码 0/非0 供作业判断）
/bin/check_quality.sh --day ${p_day} --path /data/incoming
# 退出码写入作业上下文；非0 触发失败分支 → 发送邮件告警，整条作业标记为失败
​

⚠️ 常见坑（作业条目）

• 漏配失败分支：关键条目失败无人知，第二天才发现数据没更新。
• Shell 退出码不规范：脚本内部报错却返回 0，作业误判成功。
• 邮件条目放错位置：应放在失败分支与最终成功两处，而非只在一端。

💡 关键直觉

• 作业条目的「成功/失败」两条 hop 都要画出来，才算一个健壮的剧本。
• 校验条目是「质量闸门」，放在转换之后比放在人肉巡检之前便宜得多。

工程实录：用校验闸门防污染

转换跑成功，但下游发现数据少了一半，无人察觉。

在关键转换后放 SQL 条目做行数校验，失败走告警分支。

# Shell 条目做外部质量检查，退出码决定作业走向
/check_quality.sh --day ${p_day}   # 非0 触发失败分支 -> 邮件告警
​

数据异常在当天就被拦下，不再污染下游。

校验条目是质量闸门，放在转换之后比人肉巡检便宜。

多道校验串成链路，逐层收紧质量。

参数与阈值速查

现场口诀

作业条目配置记住：「成功走绿线、失败走红线、关键条目配重试」。任何只连成功分支的作业都是裸奔——一次失败就整条静默中断，等你发现时数据早已断更。失败分支不是可选项，是生产作业的标配。