避坑指南：Kettle命名参数传递中‘执行每一个输入行‘的3个关键用法

深入解析Kettle作业流：'执行每一个输入行'的三大核心场景与避坑实战

如果你在Kettle的作业流中传递过参数，大概率遇到过这样的困惑：为什么上游转换明明输出了多行数据，下游转换却只接收到第一条，或者干脆参数值丢失了？这背后往往与作业中转换设置里那个看似不起眼的 “执行每一个输入行” 复选框密切相关。这个选项是连接作业流与转换流、实现批量数据逐行处理的关键枢纽，理解不透彻，数据流就会“断片”。

对于负责数据同步、批量处理的运维和开发工程师而言，这种参数传递的“玄学”问题不仅影响任务准确性，还耗费大量调试时间。本文将跳出常规操作手册的平铺直叙，从数据流引擎的底层逻辑出发，结合企业级实践中常见的三种复杂场景，为你彻底拆解“执行每一个输入行”的运作机制、核心用法与避坑指南。我们将通过清晰的流程对比、参数传递的追踪实验，让你不仅知其然，更知其所以然，从此告别参数传递的“灵异事件”。

1. 基石认知：作业流与转换流的本质差异与参数传递桥梁

在深入“执行每一个输入行”之前，必须厘清Kettle中作业（Job） 与转换（Transformation） 的根本区别，这是理解所有参数传递问题的前提。

作业是控制流的核心，它按顺序或条件执行各个作业项（如转换、Shell脚本、发送邮件等）。作业项之间传递的是一个结果对象（Result Object），这个对象可以包含多行数据，但它不是像转换中那样持续流动的数据流，而是“等待-传递”的批处理模式。一个作业项执行完毕后，将其结果对象传递给下一个作业项。

转换则是数据流的核心，它由一系列步骤（Step）组成，数据行在这些步骤间以管道流的方式并行或串行处理，数据是持续流动的。

当我们在作业中用一个转换（如“转换A”）生成数据，并希望将这些数据作为参数传递给作业中后续的另一个转换（如“转换B”）时，就面临一个根本矛盾：如何将转换A输出的数据流，转换为作业可以传递的结果对象，再让转换B将这个结果对象作为其执行的输入参数？

这就是 “执行每一个输入行” 选项登场的舞台。它本质上是作业调度器对下游转换（如转换B）的一种执行指令。

1.1 数据传递流程的宏观视图

让我们通过一个典型的“表输入 -> 复制记录到结果 -> 作业 -> 下游转换”流程，来看数据是如何穿越作业与转换的边界：

[转换A: 数据生成端]
表输入 (查询出N行数据)
     |
     v
复制记录到结果 (将数据流封装进结果对象)
     |
     v
[作业层]
作业项A完成 -> 结果对象(含N行数据) -> 作业项B（即转换B）
     |
     v
[转换B: 数据消费端]
（如何接收并利用这N行数据？）

关键在于，作业传递给转换B的，是一个包含N行数据的结果集。转换B作为一个独立的数据流处理单元，它如何消费这个结果集？有两种模式，由“执行每一个输入行”决定。

提示：复制记录到结果 步骤是将转换内数据流输出到作业层的唯一标准方式。它不处理数据，只做搬运。

1.2 “执行每一个输入行”的二元世界

这个复选框勾选与否，决定了转换B的两种截然不同的执行模式：