Kettle数据迁移全复盘：从旧系统到新平台的8条实战经验清单

【免费下载链接】pentaho-kettlePentaho Data Integration ( ETL ) a.k.a Kettle项目地址: https://gitcode.com/gh_mirrors/pe/pentaho-kettle

半年前，我接手了把一套跑了近十年的 CRM 迁到新数据平台的苦差事——数据量超过 2000 万条，业务还不能停。用 pentaho-kettle（业内常称 Kettle）做数据迁移，我一路踩坑，也沉淀了不少真东西。这篇文章就是我从旧系统迁到新平台的完整实战复盘：规划怎么做、流水线怎么搭、怎么提速、哪些坑必须绕开，全部浓缩成可直接照做的清单，帮你少走弯路、按时上线。

迁移动手前先回答这 5 个问题：Kettle 数据迁移规划清单

很多人一上来就拖步骤、写 SQL，结果迁到一半才发现一堆没想清楚的事。我把自己的翻车经历整理成了一张规划表，动手前逐条过一遍，能省下后面十倍的返工时间：

资产盘点这步尤其重要。我当时就是用 Spoon 的元数据搜索功能（Edit → Search Meta Data）把所有步骤、数据库连接和字段引用过了一遍，才把家底彻底摸清。


从零跑通第一条 Kettle 迁移流水线：分批抽取、转换、加载实操

规划定了，接下来就是把第一条迁移流水线真正跑起来。我的做法分四步，每一步都有明确的验证点。

第一步：分批抽取（Extract）。大表千万别一次性全量拉，内存分分钟被打爆。我按主键区间把数据切成片，每片一个 SQL 分批拉取：

<!-- 分批抽取：按主键区间切分，避免一次加载过多数据 --> <step> <name>Table Input</name> <type>TableInput</type> <sql>SELECT * FROM old_system.customer WHERE id BETWEEN ? AND ?</sql> </step>

第二步：转换（Transform）。常用的几个步骤我基本固定了套路：Select Values挑字段并重命名、Calculator做计算、Filter Rows过滤脏数据、Merge Rows (diff)对比源和目标差异。

第三步：加载（Load）。关系库用Table Output，但一定先落临时表，验证通过后再整表切换进正式目标表，风险小很多。

第四步：验证。记录数、关键字段值、聚合指标（总和、均值）三重比对，全部一致才算过。


上面这张图就是我后来搭出的作业雏形：先用Get System Info取系统时间生成变量，再按日期处理当天文件，最后用批处理把已处理文件归档——流水线化的思路可以大大减少人工干预。

让 Kettle 迁移提速的 4 个选型技巧：对比之后我这样取舍

提速不是堆机器，而是选对方案。下面是我在项目中纠结过的四组选型，最终取舍和理由一并给你：

相似表批量迁移这块，元数据注入帮我把几十张表的迁移从"复制粘贴改 N 遍"压缩成了维护一张映射表：

MetaInjectHelper helper = new MetaInjectHelper(); helper.setTransformationPath("template.ktr"); helper.injectMetadata(metadataMap);

另外两个容易被忽略的提速点：一是调大 JVM 内存（spoon.sh里的-Xmx参数）；二是如果团队要面向多地区部署，界面的多语言资源可以用 Pentaho Translator 统一管理，别在十几套语言包里手工翻找缺失的 key。


Kettle 数据迁移避坑自检清单：可勾选项直接拿去用

下面这份清单是我项目收尾时的自检表，建议你直接复制，每次上线前逐条打勾：

• 源与目标的字段类型逐字段核对过，隐性转换（如 VARCHAR(255)→TEXT）全部显式声明
• 分批大小用真实数据实测过，JVM 内存已按量调优
• 迁移窗口内源系统写入已暂停，或用时间戳/CDC 捕获了增量
• 复杂业务规则已拆成多个简单步骤，没有塞进一个巨型脚本
• 每个步骤都配置了错误处理，日志能定位到具体某一行
• 失败重跑做了去重设计，断点续传不会产生重复数据
• Carte 监控或日志采集已就位，失败会触发邮件告警
• 记录数、关键字段、聚合指标三重校验全部通过
• 目标表已备份，回滚演练真实执行过一遍

这九条每一条背后都是真金白银的教训，比如"增量去重"那条——我第一次重跑时没做幂等处理，目标表直接多出 40 万条重复数据，整整加了一晚上班才清完。

一次真实 Kettle 迁移复盘：从凌晨翻车到平稳上线

复盘一下那次最惨的上线：凌晨两点，业务方反馈新平台查到的"下单时间"比源系统慢了 8 个小时——典型的时区处理遗漏。当时源库存的是本地时间，目标库按 UTC 存，映射规则里少写了一条转换。教训很简单：所有日期时间字段，必须在映射文档里单独列一节，明确时区规则。

但也正因为前面的分批、临时表、回滚预案都做了，那次翻车我们 40 分钟就完成修复和重跑，没有造成业务损失。这让我坚信：Kettle 数据迁移这件事，工具只解决"能不能搬"，真正决定成败的是规划和流程。

想上手练手的话，建议先拿一张小表把"抽取→转换→加载→验证"完整跑通，再对照仓库assemblies/samples下的示例转换学习标准写法（克隆地址：https://gitcode.com/gh_mirrors/pe/pentaho-kettle）。迁移没有捷径，但按这份清单走，你能把弯路都留给别人。祝迁移顺利！

【免费下载链接】pentaho-kettlePentaho Data Integration ( ETL ) a.k.a Kettle项目地址: https://gitcode.com/gh_mirrors/pe/pentaho-kettle