做 ETL 的同学应该都碰到过这种尴尬定时任务天天跑得好好的某天源端就是不来数据结果流程照样往下冲目标表被清成空表下游报表跟着歪。我在做 Kettle 数据同步的时候就专门把“没有数据流入时停止操作”这个问题单独拎出来做了一期实验也就是这次要分享的 kettle 实验十一。这篇文章会把这期实验的完整思路、配置过程和踩坑记录整理出来核心解决两个问题怎么判断当前数据流是空的判断完之后是直接停止整个流程还是给调度一个明确的失败信号。适合正在用 Kettle 做定时抽取、文件加载或者被空数据坑过的同学参考照着配置就能用。1. 先搞清楚什么样的“没数据”需要干预1.1 四种最典型的空数据流场景先说第一种也是出现频率最高的表输入查不出数据。比如同步订单表WHERE create_date CURRENT_DATE当天本来就没有订单或者上游系统漏推送导致增量表里没记录查询结果就是 0 行。这种场景下大多数人第一反应是“没数据就没数据呗反正任务还要跑”但问题恰恰出在这个“反正”上。第二种是接口返回空列表。Kettle 里用 REST Client 或者 JSON Input 拉取第三方接口对方返回的list是空的或者干脆只返回一个空 JSON 对象。等你解析成行集的时候流里自然一个数据行都没有但后续的表输出照样会执行。第三种是文件场景。CSV、Excel 输入时文件里只有表头没有数据行或者文件本身就是 0 字节。Kettle 的 Excel 输入在“工作表名称”没有匹配到任何行时一样会输出一个空流。很多人以为文件不存在才会报错其实文件在、内容空才是最隐蔽的坑。第四种是数据处理后的中途变空。比如两个表做 Join由于上游脏数据或关联键不一致左连接右表全部为 NULL经过“过滤记录”或者“值映射”之后数据量变成 0。这种场景比前面几种更让人抓狂因为输入有数据、中间步骤也没报错就是最终结果空了如果你在流程末尾做了“清空目标表再插入”那目标表就被误清空了。1.2 空流不处理后果比你想象严重很多初学者觉得“没数据时停止操作”只是锦上添花的功能其实它是数据质量保障里非常重要的一环。我列几个真实发生过的后果你就明白了。第一目标表被覆盖成空表。Kettle 的“表输出”步骤里有一个选项叫“清空目标表”如果勾选了它会在插入数据前先执行 DELETE。源端没数据时这个 DELETE 照常执行然后没有任何数据写进去等于把一个有历史数据的目标表直接清空。这种事故一旦发生在生产环境恢复数据非常痛苦。第二调度平台上的状态信息失真。如果转换没有做空流判断任务会显示“成功”但实际一条数据都没处理。运维看板上一片绿真实情况却是脏数据满天飞。等到下游报表开始报警再回头查已经过去好几个小时了。第三无意义的资源消耗和消息误报。空流任务虽然数据量小但 Job 里的后续步骤还是会启动比如发送邮件通知、触发下游接口调用。有些系统在收到空文件或者空集合时也会有异常行为白白占用连接资源。所以把“没有数据流入时停止操作”这个逻辑放进 ETL 流程里不是为了炫技而是为了让你知道这次任务到底是“正常处理了 0 条数据”还是“根本没拿到数据”。这两个状态的业务含义完全不同。2. 方案选型不是只有一种“停止”的方式2.1 方案一转换内“计算行数 中止步骤”第一种做法最直接在转换里统计输入流的行数用判断组件分流如果为 0 就触发“中止”Abort步骤。Kettle 里有一个专门用来统计行数的步骤叫“计算行数”Number of rows。它会在流结束时输出一行统计结果把当前流的行数写到一个字段里。得到行数后再用“Switch/Case”或者“过滤记录”做分支行数等于 0 走中止分支行数大于 0 走正常处理分支。这个方案的优点是链路短、配置直观一个转换就能完成判断和终止。缺点是中止步骤一旦触发整个转换会以失败状态结束如果你只是想跳过当前批次的处理、但不想让调度平台报错这种方式就不太合适。2.2 方案二作业层“变量传递 简单评估”第二种做法是把判断放到 Job 层。核心思路是先用一个转换算出数据行数并写成作业变量然后在 Job 里用“简单评估”Simple evaluation步骤判断变量的值等于 0 就走“停止”分支不等于 0 才继续执行后续的转换或作业项。这个方案更适合真实生产环境。因为大多数 Kettle 调度都不是只跑一个转换而是一个 Job 里串联多个作业项抽取、清洗、加载、通知。只要把“行数判断”作为一个独立的判断节点放在 Job 流程里整个流程的后续分支就能灵活控制。比如没有数据时可以选择跳过加载步骤也可以选择直接抛一个自定义错误消息。2.3 方案三标志字段传递状态第三种方案相对少见但在某些场景下很实用。它不是在空流时停止而是往数据流里注入一个“标志字段”让后续步骤或者外部系统知道这次数据是空的。具体做法是在表输入之后挂一个“空操作”分支或者使用“生成行”步骤强制输出一行标记数据然后合并到主管道里。这样即使源端没数据流里也会有一行flag 0的记录后续的流程不会因为空流而完全不执行而是可以基于标志字段做自己的处理。这类方案适合那种 “数据为空时还要走完流程去通知下游” 的场景比如给调度系统发送一条“本次无数据”的状态报告。2.4 三种方案怎么选我把三个方案的核心差异整理成了一个表你可以根据自己的场景直接对照选型。方案判断位置空数据时的表现适合场景复杂度计算行数 中止转换内部转换抛错任务失败单转换快速拦截需要调度平台识别失败低作业变量 简单评估作业层可以自定义跳转或停止多步骤作业需要灵活控制后续分支中标志字段传递转换内部流程继续携带空流标记需要上报状态或走完剩余链路中高我个人的建议是如果你刚开始改造存量任务优先从方案二入手因为它在作业层做判断对现有转换的侵入性最小后续维护也最方便。3. 实操转换内无数据停止的标准配置3.1 步骤链路怎么搭这一节我以“表输入 → 计算行数 → Switch/Case → 中止”为例给你拆一套可以直接复用的配置。先看完整的步骤链路表输入 - 计算行数 - Switch/Case - 数据处理流程 | ----- 中止很多初学者会问为什么不是“表输入 → 过滤记录 → 中止”原因在于“过滤记录”的触发机制。如果表输入没有任何数据行流出过滤记录步骤根本不会执行它不知道上游是“没有数据”还是“有数据但没匹配上”。计算行数的价值就在这里它会在流结束后主动输出一行统计结果给下游一个明确的信号。3.2 从零开始配置每一步第一步配置表输入。为了贴近真实场景我用一个非常简单的查询做演示SELECT order_id, order_amount, create_date FROM t_order WHERE create_date 2025-01-15这个查询的日期可以换成变量实验的时候我建议先用一个肯定没数据的日期比如1999-01-01这样方便你观察中止效果。第二步配置“计算行数”步骤。打开步骤后只需要填一个字段名比如row_count。这个步骤不会改变原始数据行它只是在流的末尾追加一行统计。如果源端有 100 条数据它会输出 1 行row_count 100如果源端 0 条数据多数版本下它依然会输出 1 行row_count 0。这一点是后续判断能否成立的基础。这里有个细节容易被忽略计算行数必须等整个输入流全部走完才会输出结果也就是说它是“阻塞型”步骤。如果上游有大量数据中间会有等待这不影响正确性但你要有心理预期别把正常等待当成卡死。第三步配置 Switch/Case。用它做分支判断条件字段选择row_countCase 值填0匹配走的 Target step 选“中止”默认分支选“数据处理流程”。这里我建议优先用 Switch/Case 而不是“过滤记录”。Switch/Case 的直接匹配更直观过滤记录则在复杂表达式场景下更灵活。对于“判断是否等于 0”这种单一条件Switch/Case 写起来更顺手也不容易写错逻辑。第四步配置“中止”步骤。“中止”的作用是让转换在这里停下来并抛出一条错误消息。它有两个关键参数中止的错误消息建议写成业务人能看懂的话比如“订单同步失败源表当天无数据任务已停止”。中止所有步骤一般勾选表示一旦触发就整体停止不再等其它分支。配置完以后如果表输入查不到数据运行日志里会看到类似这样的信息2025/01/15 10:00:01 - 中止 - 订单同步失败源表当天无数据任务已停止 2025/01/15 10:00:01 - Spoon - 转换已被中止执行结果失败整个转换的最终状态会被标记为“失败”调度平台能直接拿到这个失败信号。3.3 为什么用“中止”而不是“空操作”我知道有些教程会让你用“空操作”Dummy来处理空数据分支我也用过但它在大多数生产场景下不够用。空操作只是让流程不报错地跑过去它不会给调度系统任何提示。你从日志上看任务还是成功的这就回到了开头的那个问题空流被当成正常处理了。“中止”就不一样它主动抛出异常状态。对于用kitchen.sh或pan.sh跑批的团队来说退出码非 0调度工具就能感知到然后按你的规则发告警或者重试。所以我的结论是如果你明确希望“没有数据时停止并让人知道”就大胆用中止如果你只是想跳过再考虑空操作。3.4 想在停止前发一封提醒邮件怎么处理有些业务场景对“没有数据”非常敏感希望停止的同时给负责人发一封邮件。这种情况下不要在中止步骤上费脑筋直接在 Switch/Case 的 0 分支上挂一个“发送邮件”步骤再连到中止步骤就行。链路会变成表输入 - 计算行数 - Switch/Case - 数据处理流程 | ----- 发送邮件 - 中止发送邮件步骤配置 SMTP 服务器和收件人列表即可这里不展开。实际测试的时候注意不要用假的 SMTP 地址不然任务会卡在发邮件超时上反而掩盖了空流判断这个核心实验点。4. 进阶在作业里优雅地“没有数据就停止整个流程”4.1 为什么单转换不够用上面的转换内中止方案虽然简单但有一个硬伤它只能停止当前转换。如果整个 Job 里有十来个转换比如先抽订单、再抽退款、再抽支付流水订单没数据时你希望的是“今天所有流程都别再往下走了”而不是订单转换停了、后面退款和流水还在跑。这种场景就必须把判断上移到作业层用“转换输出变量 作业判断”的方式做全局控制。4.2 第一步把数据行数输出成作业变量我们先建一个专门用来统计行数的转换命名为“00_获取数据量.ktr”结构是表输入 - 计算行数 - 设置变量“计算行数”的输出字段名还是row_count然后挂一个“设置变量”步骤。这里要注意“设置变量”步骤不是简单地把流里的字段映射成变量它需要你指定四列变量名比如src_row_count变量的值来源选择流里的字段row_count变量类型一般选 String 或 Integer实验里选 Integer 更直观有效范围这里有“JVM 范围”、“作业范围”、“转换范围”几个选项必须选“作业范围”否则 Job 里的判断步骤读不到配置界面上每一行对应一个字段映射把row_count映射到src_row_count即可。这一步的目的是让后面 Job 的判断节点能读到“这次抽取到底拿到多少行”。4.3 第二步在 Job 里配置简单评估Job 的结构比转换简单核心节点就这么几个START - 00_获取数据量 - 简单评估 - 成功分支继续处理 | ----- 失败分支停止整个作业打开“简单评估”步骤配置逻辑是对变量src_row_count做“等于”判断值为 0。也就是说当变量值等于 0 时说明源端没有数据走失败分支。这里有一个非常容易踩的坑变量在“简单评估”里的写法是${src_row_count}但 Kettle 的变量机制是字符串所以如果你在评估条件里写“等于 0”它实际比较的是字符串0。如果变量没赋上值它会变成空字符串判断结果可能反过来。为了排查这种问题建议在“00_获取数据量”转换里的“设置变量”后面加一个“写日志”步骤把变量值打出来比如输出字段src_row_count 日志级别basic 日志信息当前源端行数为 ${src_row_count}这样每次跑 Job日志里都能看到行数变量有没有传成功一目了然。4.4 第三步根据判断结果控制后续分支“简单评估”步骤本身不产生成功或失败它需要你把两个分支分别连到对应的处理逻辑上。成功分支表示“变量不等于 0”也就是有数据往下连接真正要做数据处理的转换比如“01_增量加载.ktr”。失败分支表示“变量等于 0”也就是没数据这里怎么处理取决于你的需求。可以用“空操作”静默跳过也可以直接在 Job 里放一个选择性中止。Kettle 的 Job 里没有类似转换里“中止”那么直接的步骤但你可以用“发送邮件”发告警然后用一个“关闭作业”的方式强制结束。如果你希望整个 Job 在无数据时以失败状态结束可以这样失败分支不要连“成功”结果而是直接连一个有“将执行结果设为失败”的作业项或者把失败分支的下一个转换设置成注定失败的脚本步骤。这样操作后Job 的最终状态就会是“失败”调度平台也能感知到。4.5 变量作用域延迟的典型问题用“设置变量” Job 判断的时候有同学会遇到这种情况单独跑“00_获取数据量”时日志里能正常打印src_row_count 0但回到 Job 里跑“简单评估”的判断结果却是“有数据”后面的处理照常执行了。这个问题绝大多数时候出在“设置变量”步骤的有效范围上。如果你选了“JVM 范围”变量在整个 JVM 生命周期内生效但 Job 的判断步骤可能读取时机和你预期不一样如果你选了“转换范围”那个变量只在当前转换内部可见Job 根本拿不到。只有“作业范围”才是传递给当前 Job 上下文正确的方式。另外一个容易被忽略的点是如果“00_获取数据量”转换因为某些原因执行失败变量根本不会写入那“简单评估”读取到的不是“0”而是空值。所以在 Job 的判断逻辑里最好把“空值”和“等于 0”都视为“无数据”来处理避免判断条件覆盖不全。5. 常见问题与独家避坑记录5.1 高频问题速查表我把自己和身边同事做过类似实验时遇到过的问题整理成了表格每次排查对照着看就行。问题现象可能原因解决办法0 行时计算行数没有输出统计行不同版本对空流的处理有差异升级较新版本或在表输入后增加“生成行”步骤兜底中止步骤触发了但日志里没有业务提示中止消息为空在中止前挂“写日志”先把原因打出来Job 判断总是走“有数据”分支变量未传递到作业范围检查“设置变量”的有效范围改为“作业范围”变量值是 0但判断条件不成立变量类型变成字符串比较逻辑不匹配在计算行数转出后用“字段选择”转类型或评估时用字符串比较表输入没数据后面的表输出还是清空了目标表判断步骤位置太靠后把计算行数和中止放到表输入后、表输出前空文件也能通过 TXT/CSV 输入空文件和“无文件”是两回事先统计文件行数再根据行数决定是否继续计算行数让大表跑得很慢计算行数是阻塞步骤要等全量读完大表场景改用 SQL COUNT 或者数据库端做行数统计5.2 判断位置尽量前置在实验过程中我踩过最深的坑就是在整个转换的末尾才做行数判断。当时想的很简单反正最后要写目标表我在写表之前判断一下不就行了。但问题在于中间的清洗步骤可能已经把数据改得面目全非有些步骤在空流时还会把目标表锁住或者产生临时表。后来我把规则改成了一条空流判断必须紧跟数据源步骤之后。也就是说表输入、CSV 输入这类源头步骤一旦还原数据第一件事就是统计行数并判断没有数据就立刻中止而不是等它流经各种转换步骤。这样能最大程度减少无效计算和副作用排查问题也容易。5.3 “停止”和“失败”要分清做这期实验之前我在团队里做过一个测试无数据时用“空操作”结束任务结果任务状态是成功业务人员完全不知道当天没数据后来换成“中止”任务状态变成失败异常告警和排查机制才真正生效。所以在设计空流处理时你首先要回答一个问题这次空流是“可预期的正常情况”还是“需要被关注的异常情况”如果增量同步本来就是“有数据就更新没数据就跳过”空操作没毛病如果这个表每天必须有数据空了就说明上游链路出问题了那就必须让它失败让调度报警。很多人纠结要不要报错其实本质是没想清楚业务的期望状态。5.4 空文件场景要额外检查文件本身最后提醒一个容易被忽略的细节文件类数据源的空流判断不是只看行数还要考虑文件是否存在、是否被占用、是否有权限打开。有一次我用 Excel 输入文件内容有几十行但因为文件名带日期而日期变量传错了导致读到了一个空模板文件行数是 0。如果只看行数会以为是数据问题实际是文件定位的问题。这种情况下你的空流判断逻辑最好拆成两层先检查文件的元信息存在性、大小、修改时间再统计数据行数。不要一刀切地把所有“0 行”都归结为无数据要看是“读到了空文件”还是“没读到文件”。这套实验做下来我个人最大的体会是判断空数据流这件事难点其实不在配置上而在想清楚“由谁来负责判断、判断完给谁看”。如果你只是希望日志里别刷空数据转换里用计算行数加中止就够了如果你要的是整个作业在源端无数据时停下来不影响下游步骤那一定要把判断放到作业层用变量传值来做。另外分享一个小技巧实验阶段麻烦一点在每个关键分支都挂“写日志”把行数和走向打出来。跑通了之后你会发现排查任何空流问题都特别快因为日志已经替你圈定了范围。