Kettle实战：数据同步中null与空字符串的坑，附三层清洗方案

做数据开发的老伙计们，只要跟 Kettle 打过交道，一定都遇到过这种让人抓狂的场景：明明源库表里某个字段看着是空的，导过来以后却变成了一个不为空的字符串"NULL"，或者反过来，想要把空字符串清洗成 NULL 做过滤，结果死活匹配不上。这个"null 与空字符"的问题，看似是个小细节，实际上在数据同步、清洗、写入的每个环节都能蹦出来咬你一口。我这些年用 Kettle 做跨系统数据同步，光在这上面就踩过不少坑，今天把实战案例和解决方案整理出来，希望能帮你少走弯路。

这篇内容适合正在用 Kettle 做 ETL 开发、数据清洗或数据迁移的工程师，也适合刚入门、被空值问题搞得一头雾水的新手。我会从 null 和空字符串的本质区别讲起，再拆解几个高频踩坑场景，最后给出一套可以直接抄作业的清洗方案和排查思路。

1. 先搞清楚：null 和空字符到底差在哪

很多人习惯把 null 和空字符串混为一谈，尤其在 Kettle 里吃了几次亏之后，你才会明白这两者是完全不同的东西。理解它们的差异，是解决所有后续问题的基础。

1.1 数据库里的 null 和空字符串

在绝大多数主流数据库里，NULL 和空字符串是两种完全不同的值。NULL 表示"这个字段的值不存在、未知"，它不参与任何计算；而空字符串（''）是一个实实在在的字符串值，长度为 0，只是内容为空。

举个例子，一张用户表里有个字段叫备注（remark），如果某条记录的 remark 是 NULL，说明这条记录压根没填备注；如果 remark 是空字符串，说明用户填了一个空内容，系统存成了长度为 0 的字符串。这两者在数据库层面有很多实际差异：

• 比较方式不同：NULL 不能用等于号判断，必须用 IS NULL；而空字符串可以直接用 = '' 判断。
• 聚合函数行为不同：COUNT(remark) 不会统计 NULL 值，但会统计空字符串。
• 字符串拼接结果不同：在 MySQL 里 CONCAT('前缀', NULL) 结果是 NULL，而 CONCAT('前缀', '') 结果是 '前缀'。
• 索引使用不同：很多数据库对 NULL 和多列索引的处理比较特殊，空字符串则和其他普通值一样。

还需要特别注意的是不同数据库的"脾气"不一样。比如 Oracle 就把空字符串直接当作 NULL 处理，你想在 Oracle 里存一个空字符串，实际上存进去的会是 NULL；而 MySQL、PostgreSQL、SQL Server 则会把 '' 和 NULL 区别对待。这就导致同一个 Kettle 作业，从 MySQL 读数据写 Oracle，或者反过来，空值语义就漂移了。

1.2 Kettle 数据流里的表现差异

Kettle 自身的数据类型体系里，字段一般会有 null 或空字符串两种"空"的状态。当你从数据库表输入读取数据时，Kettle 会把数据库里的 NULL 映射为自身的 null 值，把数据库里的空字符串映射为长度为 0 的字符串值。但问题在于，Kettle 在界面显示上，这两者在预览时看起来差不多，不仔细看都是"空"。

更麻烦的是，Kettle 里很多组件的默认行为会把你原本的值偷偷改掉。比如某些版本的 JDBC 驱动在读取 Oracle 数据时，会把空字符串读成 null；而用"生成记录"或自定义常量时，常量默认可能设置成空字符串而非 null。这些"看不见的转换"才是让你排查到头秃的元凶。

我的建议是：在每个关键步骤后面加一个"数据校验"组件，把需要关注的字段打印出来，用肉眼确认一下到底是 null 还是空字符串，不要凭经验猜。在这个问题上，猜的代价往往是一整晚的排查时间。

2. 最常见的几个踩坑场景

空值和空字符串的问题通常不是独立的，它们往往藏在某个业务操作里，以"结果不对"的形式表现出来。下面这几个场景是我实际工作中反复栽过跟头的，列给你参考。

2.1 表输入阶段：源库的脏数据就埋了雷

第一个坑出现在数据源头。我们经常直接从业务系统的表里用"表输入"组件读数据，但业务系统的数据质量往往一言难尽。同一个字段，有的记录是正常的字符串，有的记录是 null，有的记录是空字符串，还有的是带空格的字符串 ' '，甚至有的系统会把字符串 'NULL' 当成文本存进去。

我遇到过一个真实案例：某公司的客户信息表，客户来源字段（source）里，正常情况下应该填"线上"或"线下"，但实际数据里五花八门：有的是 NULL，有的是空字符串，有的存了 'null' 这个文本，还有的是 ' '（三个空格）。用这些数据去聚合统计的时候，报表里就多出了很多莫名其妙的"客户来源"，比如单独出现一个 "null" 分组，或者一个看着是空格的分组。

这个阶段的核心问题是你没有在源头控制数据格式，脏数据被原样读进来，后面所有环节都要为它买单。所以处理思路应该是：在"表输入"里就把脏值挡在门外，或者至少给它们打上标记。

2.2 字段加工与拼接：空值导致结果异常

第二个坑发生在加工阶段。Kettle 里有大量字段处理的组件，比如字符串剪切、替换、拼接、计算等等。这些组件对 null 和空字符串的处理逻辑并不统一，稍不注意就会产生脏数据。

举个例子，"字符串操作"组件的 trim 类型操作，它可以去掉字符串两端的空格，但如果你对它传入了 null 值，有的版本会直接报错，有的版本会返回 null，还有的版本会返回空字符串，不同环境下表现不一致。再比如用"增加常量"字段给记录添加一个固定前缀，如果原字段是 null，拼接出来的结果可能直接变成 null，也可能只输出前缀部分，完全取决于你用的是什么组件。

还有一个很隐蔽的场景是"字段拆分"。你把一个包含多个子段的字符串按分隔符拆开，比如把"张三,25,北京"拆成姓名、年龄、城市，如果某个子段是空的，拆出来以后可能是空字符串，也可能是 null。后面再做条件判断时，用 IS NULL 去过滤却过滤不掉空字符串，导致重复记录钻进下游。

2.3 写入目标表：约束冲突与数据质量

第三个坑在输出阶段。写入目标数据库的时候，如果目标表字段设了非空约束、唯一约束或外键约束，null 和空字符串的表现是不一样的。一个字段如果是 NOT NULL，那么 null 值会直接报错；空字符串在大部分数据库里却能通过非空约束，但这可能产生语义上不完整的数据。

举个典型例子：你要把清洗后的数据写入数仓的维度表，维度表里有个字段"状态"设为 NOT NULL。源系统里某些记录的状态本来就没填，写入时如果你把 null 原样丢过去，数据库直接报错；如果提前把 null 替换成空字符串，写入成功了，但报表里就会看到一个"空状态"的维度，语义上就是不合理的。

此外，如果目标表有唯一索引，那么 null 值在多数数据库的 unique 约束里是可以重复出现的（MySQL 就是这样），而空字符串只能出现一次。这个差异在同步"编码"字段时尤其致命：多条记录编码为空字符串，第一条写入成功，第二条直接撞唯一索引报错。

3. 一套能直接用的处理方案

既然问题这么多，解决方案也得成体系。我总结下来，一条可靠的数据流里，至少要经过"前置清洗—加工兜底—写入兜底"三层防护，每一层负责不同的问题，缺一不可。

3.1 使用"过滤记录"和"值映射"做前置清洗

前置清洗的目标是：在数据进入复杂加工之前，就把各种"空"的形态统一起来。这里我最常用的是两个组件：过滤记录 和 值映射。

第一步，用"过滤记录"把明显的脏数据分流。你可以设置多个 OR 条件，把这些情况全部筛出来：

• 字段 IS NULL
• 字段 = ''
• 字段 = 'null'（注意这里是小写的字符串，或者你业务里实际可能出现的各种文本形态）
• 字段（trim 之后）=''，这个需要搭配公式或新的计算字段来实现

筛选出来以后，你可以根据业务决定：是直接把脏数据丢掉，还是走另一条分支做标准化处理后合并回来。我倾向于不直接丢弃，因为很多业务场景里，这些脏数据往往能反映源系统的缺陷，丢掉了后面没法追溯。

第二步，用"值映射"把各种"空"统一成你想要的目标形态。值映射组件可以把源值映射为目标值，而且可以设置"默认值"和"不匹配时的处理"选项。如果业务上要求把 NULL 和空字符串统一成 NULL，你就把 null 和空字符串都映射为目标 NULL；如果业务上明确不允许 NULL 存在，就统一替换成 0、空字符串或某个业务默认值。

这里有个细节：值映射组件在处理 null 时的行为在不同版本里有些差异，配置时要仔细看选项。如果版本不支持直接把 null 和空字符串同时映射为 null，那就先用"替换 NULL 值"组件把 null 统一成空字符串，再通过值映射把空字符串处理掉，或者反过来，总之殊途同归。

3.2 用"JavaScript 代码"或"替换 NULL 值"组件兜底

前置清洗之后，加工阶段还是可能会冒出新的空值。比如你用"字段拼接"组件拼接两个字段，其中一个字段在这个分支里恰好是空，拼出来就可能变成 null。所以加工阶段一定要有兜底措施。

我的首选是"替换 NULL 值"组件，它简单直接，可以把指定字段中的 null 值替换成你设定的值。但它有一个局限：只能替换真正的 null，替换不了空字符串。所以如果你要处理的字段里可能有空字符串，得先通过一次"字符串操作"组件的 trim 加上"值映射"把空字符串变成 null，或者用别的方式统一。

如果字段较多，或者你要做更复杂的空值判断，建议直接上一个"JavaScript 代码"组件。写在 JavaScript 里的逻辑非常直观，比如：

var remark = target_get_field_value('remark', ''); if (remark == null || remark == '') { // 统一当成缺省值处理 remark = '默认值'; }

这里要说一下 JavaScript 组件里判断空值的一个经典陷阱：用==和===判断结果是不同的。在 JavaScript 中null == undefined返回 true，null === undefined返回 false，而字符串''与null用==比较时结果是 false。所以不要想当然，写判断条件的时候尽量明确写全x == null || x == undefined || x == ''这类完整判断，避免沾到隐式转换的边。

如果你不想写代码，还有一招更省心的：用"规范化"组件或者"字段选择"组件里对空值的处理选项。这类组件的原理是把空值转换为固定值，有需要的可以自己翻一下组件面板，不同版本叫法略有差异。

3.3 数据库写入端的终极兜底：SQL 层面的处理

最后一层防护是写入端。即使前面的清洗和加工都做了，也难保不会有漏网之鱼。所以在目标数据库的 SQL 层面，用函数再兜一次底是成本最低、最稳的方式。

以 MySQL 为例，我经常在"表输出"组件里写自定义 SQL，或者在"执行 SQL 脚本"组件里做预清洗：

-- 把空字符串统一转为 NULL 后写入 INSERT INTO target_table (id, remark, status) VALUES ( ?, NULLIF(NULLIF(TRIM(?), ''), 'null') -- 把空字符串和 'null' 文本都转成 NULL ?, COALESCE(NULLIF(TRIM(?), ''), '未知') -- 把空的统一填默认值 )

这里用到几个很实用的函数：

• TRIM：去掉字符串两端的空格。很多空值其实带着空格，不 trim 根本发现不了。
• NULLIF(expr, '')：当表达式值等于空字符串时，返回 NULL。这一招可以把空字符串统一成 NULL。
• COALESCE(expr, 默认值)：当表达式为 NULL 时，返回默认值。常用于把 NULL 填充成业务默认值。
• NULLIF(expr, 'null')：如果业务里还混入了 'null' 字符串，也可以这样清理掉。

当然，具体函数名和语法在不同数据库里略有不同，SQL Server 里是 ISNULL，PostgreSQL 里也可以直接用 NULLIF 和 COALESCE，Oracle 里空字符串本身就是 NULL，这就不用多说了。在做跨库迁移时，先在源端把数据查出来看一眼，再决定写哪种函数，能少走很多弯路。

4. 实操案例：以某跨平台系统数据同步为例

光讲理论不够，我把最近处理的一个真实场景完整还原出来，从需求到排查再到最终方案，你可以对照着看。

4.1 业务场景与需求梳理

某公司有两个业务系统，分别是 A 系统的订单模块和 B 系统的用户中心。公司要做跨平台数据分析，需要把 A 系统的订单主数据同步到统一的数据分析库中。同步链路用的是 Kettle 作业，每隔 15 分钟增量抽取一次，写入目标是数据仓库的订单明细表。

需求本身不复杂，订单表里主要有这些字段：订单号、用户ID、用户昵称、订单金额、优惠券编号、备注、下单时间。但是落地之后，下游报表团队开始报数据质量问题：

• 用户昵称这一列出现大量 NULL 和空字符串混杂的情况，报表里没法统一展示。
• 优惠券编号有很多记录是空字符串，但还有部分是 'null' 文本，导致聚合"使用优惠券订单数"时统计多了一倍。
• 备注字段拼接出来的结果经常是"订单备注：null"或者"订单备注："，很影响数据导出。

4.2 第一个坑：源库空字符被当成有效数据

排查从源头开始。我先在 A 系统库里直接跑了一段 SQL 检查：

SELECT COUNT(*) AS total_count, SUM(CASE WHEN user_nickname IS NULL THEN 1 ELSE 0 END) AS null_nick_cnt, SUM(CASE WHEN user_nickname = '' THEN 1 ELSE 0 END) AS empty_nick_cnt, SUM(CASE WHEN TRIM(user_nickname) = '' THEN 1 ELSE 0 END) AS blank_nick_cnt FROM order_table;

结果让我吃了一惊：源库表里空字符串和 NULL 都有，而且还有几十条记录的 user_nickname 是三个空格，这在数据库管理工具里看起来"像空的"，但用程序判断就不是空值。

这就是典型的"源系统没有做数据规范"问题。数据的录入端没有做必填校验，用户昵称没填就存了空字符串，部分历史数据导过来时被解析成了 NULL，还有几个老的录入页面把回车或空格也当成昵称存进去了。这种情况下，如果不做处理，直接用 Kettle 抽数据，空字符串、NULL、空白字符串都会原样进入数仓。

4.3 第二个坑：字符串拼接与聚合函数结果不对

接着看第二个坑。下游报表用 GROUP BY 统计优惠券编号这一维度的订单数时，发现多出了两个奇怪的组：一组显示"null"，一组显示"空"。原因是优惠券编号字段里确实存在 'null' 文本和空字符串，报表工具把它们当作有内容的分组维度了。

更隐蔽的是备注字段。Kettle 作业里原本有一个"字符串操作"步骤，用于把"订单号 + 备注"拼接成审计信息，类似 '订单号：12345，备注：xxx'。但有些订单的备注是 NULL，拼接组件在遇到 NULL 时直接返回了 NULL，下游拿到的审计信息直接缺失；有些备注是空字符串，拼出来是'订单号：12345，备注：'，看起来又很怪。

这个问题也影响到了聚合函数。比如统计"有备注的订单数"用了 COUNT(remark)，由于 NULL 不会被计入 COUNT，但空字符串会被计入，所以统计结果偏大，而且和"无备注订单数"之间对不上。这就是我在前面说的聚合函数对 null 和空字符串行为不一致导致的典型问题。

4.4 最终方案：三层清洗链路

针对这些问题，我在同步作业里搭了一条三层清洗链路。

第一层：源头初始化清洗。在"表输入"组件里，我改写了抽取 SQL，用 NULLIF 函数把空字符串先统一成 NULL，再用 COALESCE 把业务上要展示的字段填上默认值：

SELECT order_id, user_id, COALESCE(NULLIF(TRIM(user_nickname), ''), '未命名用户') AS user_nickname, order_amount, CASE WHEN COALESCE(NULLIF(TRIM(coupon_code), ''), 'null') = 'null' THEN '' ELSE coupon_code END AS coupon_code, NULLIF(TRIM(remark), '') AS remark, order_time FROM order_table WHERE order_time > ?

第一次看到这段 SQL 可能觉得啰嗦，但它非常实用。我这边的思路是：

• 用户昵称是展示型字段，不允许为 NULL，空的和脏的统统替换成'未命名用户'。
• 优惠券编号是维度型字段，存在 'null' 字符串的也清理掉，但保留空字符串，因为业务里"未使用优惠券"和"使用了优惠券但没记编号"是两种含义，统一成空字符串后可以在后续用 CASE 区分。
• 备注字段用 NULLIF 把空字符串和纯空格统一成 NULL，这样统计"有无备注"时结果干净。

第二层：Kettle 内部兜底。表输入出来后，我加了两个组件。先用"替换 NULL 值"把可能出现的 null 值替换成业务默认值，这一步是为了防止某些 JDBC 驱动在读取时把空字符串自动转成 null，导致SQL 层的努力白费。接着用"JavaScript 代码"组件对备注字段做最后一道规范化，把备注为空的情况统一输出为"无备注"：

var remark = remark === null || remark === '' ? '无备注' : '备注：' + remark;

第三层：写入端 SQL 兜底。最后在"表输出"组件里，我没有直接映射字段，而是写了自定义 INSERT SQL，用 NULLIF 再清一遍空值，确保写入数仓的数据一定是统一的格式。三层链路下来，原本的脏数据问题基本根除，下游报表同事也再没来找我反馈过数据对不上。

5. 常见问题速查与排查技巧

和 null 与空字符死磕的次数多了，我积累了一些排查经验和速查判断，直接分享给你。

5.1 问题速查表

下面的表格是我在做同步任务时最常见的几个问题和对应的解决思路，遇到类似情况可以直接对照排查：

5.2 排查思路与方法

如果你现在正被一个空值问题卡住，我建议按下面这个顺序去排查，基本能定位到 90% 的问题：

第一步：先确认数据形态。把你怀疑有问题的字段在源库里查出来，统计一下几种"空"的数量：NULL、''、纯空格、'null' 文本。不要靠预览界面猜，直接 SQL 统计，一个都不能少。

第二步：再看 Kettle 组件行为。用预览功能查看每个组件输出数据里目标字段的形态变化，尤其是那几个容易"隐形改变"的组件：表输入、字段选择、值映射、字符串操作、字段拼接。建议在关键节点加一个"数据校验"组件，直接把空值数量输出到日志。

第三步：最后检查目标端约束。看看目标表的字段定义，有没有 NOT NULL、UNIQUE、外键约束，再对照当前数据推断是不是约束冲突导致的报错。

第四步：养成统一空值的习惯。我个人的习惯是，在每条同步作业的开始和结束，各做一次空值统一。开始的时候统一源数据形态，结束的时候统一写入目标表前的形态。这样做的好处是中间环节永远面对的是"已经规范化"的数据，不容易出幺蛾子。

5.3 一个容易被忽略的小技巧

最后分享一个细节：很多人在 Kettle 里写"过滤记录"条件时，喜欢直接写"字段 IS NULL 或字段 = ''"，但忘记了字段值可能带空格。数据在录入端如果没做 trim，' '（两个空格）和 ''（空字符串）在界面上看起来完全一样，但判断结果天差地别。

我建议在判断之前，先用"字符串操作"组件把目标字段做一次 trim（去除两端空格），再用"替换 NULL 值"或公式统一空值形态，最后再进过滤。前面案例里那个"三个空格的昵称"，就是靠着 trim 这一步才揪出来的，如果直接过滤，它就会从缝隙里溜进去，变成一个"看起来没有实际存在的分组"。

还有个小细节：如果你用了"数据库查询"或"数据流查询"组件做关联，关联字段如果一边是 NULL 一边是空字符串，这俩是匹配不上的，会出现该关联上的数据关联不上，最后变成两条孤儿记录。遇到这种情况，记得在关联之前把两边的关联字段统一空值格式，不然数据库里明明有数据，查出来却是 null。

做完这些处理，数据质量基本就稳了。这几天我回头复盘，最大的感触是：null 和空字符串的问题看着小，但它牵扯到源系统数据规范、JDBC 驱动差异、Kettle 组件行为、目标库约束、下游报表语义五个环节，任何一个环节没对齐，都会在某个意想不到的地方爆雷。项目里如果能把"空值统一"当成一条显式的清洗规则写进同步作业，而不是碰见了才修，后面能省下大把排查时间。