3.1 Transformation基本结构与数据流

3.1 Transformation基本结构与数据流

转换不是脚本，是一张带方向的数据网

本篇是第 3 章第 1 节，是动手章的入口，先讲清正文的「图」由什么构成，后面三节才往里填步骤。

一个转换由「步骤」和「跳 hop」组成。步骤是处理单元，跳是有向边，表示数据从哪个步骤流向哪个。注意跳是数据流不是控制流：它不表示「先算完 A 再算 B」，而是 A 产出的行被送往 B。我们新人常误解这点，把跳当函数调用，结果画出的图逻辑拧巴。

数据流是行级的：Kettle 一次处理一行（或一批行），从上一步的出口流到下一项的入口。每个步骤有自己的输入行集和输出行集，彼此通过线程解耦。理解这个，才能解释为什么「过滤」步骤可以分出两条跳——满足条件的走一条，不满足走另一条。

转换有两种执行视图：串行和并行。默认各步骤并行跑，靠行集衔接；某些步骤（如排序、分组）需要看完全部数据才能产出，会隐式阻断流水线，成为性能拐点。我们在设计时会把这类「阻塞步骤」尽量后置、且单独评估其内存。

还有「映射（子转换）」的概念：一个步骤可以嵌入另一个转换，用于复用一段加工逻辑。我们有一套通用的「地址标准化」转换，被十几个上层转换当子转换调用，改一处全生效。这让图保持清爽，也符合第二章说的模块化价值。

保存时注意：一个 .ktr 只描述一个转换，跨转换的协调交给作业。我们见过有人把五个独立逻辑塞进一个转换靠跳连，结果谁先谁后说不清。结构清晰比少开文件重要，这条原则第三章始终管用。

关键代码与配置

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

<trans>
  <step><name>表输入</name><type>TableInput</type></step>
  <step><name>过滤</name><type>FilterRows</type></step>
  <step><name>有效输出</name><type>TableOutput</type></step>
  <step><name>无效输出</name><type>TextFileOutput</type></step>
  <hop><from>表输入</from><to>过滤</to></hop>
  <hop><from>过滤</from><to>有效输出</to><true></hop>
  <hop><from>过滤</from><to>无效输出</to><false></hop>
</trans>
​

过滤步骤分出真假两条跳，是数据流分支的典型用法。我们常用它把脏数据导入文件待人工处理，干净数据继续主链路。

# 在转换里开启步骤性能监控，看每行集吞吐量
pan.sh /file:demo.ktr -level:Rowset
# 日志会显示每个步骤 输入行数 / 输出行数 / 缓冲区
​

Rowset 级别日志是定位「哪一步拖后腿」的利器。我们每次上线新转换都先跑一遍这个级别，把瓶颈步骤记进文档。

背景

一位同事想表达「先校验再写」，却用跳把「校验」连到「写」，结果校验步骤没产出任何行，下游直接空跑。

操作

我们改为：校验作为「过滤」步骤，合法行走真跳去写，非法行走假跳去错误表。

<step><name>校验</name><type>FilterRows</type>
  <field>id</field><condition><>[is not null]</condition></step>
​

结果

数据流和控制意图都对上了，空跑消失，错误数据也有了去处。

解读

根因是混淆了跳的语义。跳只搬运行，不表达先后；要表达「条件分支」就用能分叉的步骤。这课让我们重画了好几张旧图。

变式

若校验逻辑复杂，可单独抽成子转换，主转换用「映射」步骤调用，主图仍然只有一条干净主线。

常见误区与工程取舍

误区：跳=先后。跳是数据流方向，控制流交给作业或能分叉的步骤。

误区：阻塞步骤随便放。排序/分组会卡流水线，应后置并单独评估内存。

取舍：一个 .ktr 装一种逻辑，跨转换协调交给作业，图比少文件重要。

深入：一个转换的最小骨架怎么搭

标准转换呈「输入步骤 → 转换步骤 → 输出步骤」三段，靠 hop 串成数据流。输入步骤负责把数据从源拉进行集；转换步骤在内存里对每行做变换（过滤、映射、计算）；输出步骤把结果写回目标。搭的时候先放输入、确认能预览到行，再叠转换、每加一个就预览一次，最后接输出。这种「小步预览」能让你在十步之内就发现字段名拼错、类型不对这类低级问题，而不是堆完三十步才排错。

<trans>
  <step><name>表输入</name><type>TableInput</type>
        <sql>SELECT id, amount, status FROM src_orders</sql></step>
  <step><name>值映射</name><type>ValueMapper</type>
        <field_from>status</field_from><field_to>status_cn</field_to></step>
  <step><name>表输出</name><type>TableOutput</type><table>dst_orders</table></step>
  <hop><from>表输入</from><to>值映射</to></hop>
  <hop><from>值映射</from><to>表输出</to></hop>
</trans>
<!-- 三段式：输入取数→内存映射→写出（输入：src_orders；输出：dst_orders 带中文状态） -->
​

⚠️ 常见坑（转换结构）

• 一上来就堆三十步：出错后无从定位，应小步预览。
• hop 连错方向：数据流向反了，下游拿到空行集。
• 在转换里做控制流：判断、循环、发邮件属于作业，别塞进转换。

💡 关键直觉

• 转换是「数据的水管」，不是「程序的逻辑」；水管只负责把水从 A 送到 B 并过滤。
• 预览（Preview）是你的第一道测试：每个输入步骤都能单独预览，先确认取到数再加料。