上周帮朋友处理一个数据库迁移的活儿，他公司要把老旧的 MySQL 搬到 PostgreSQL 上，数据量不大但表结构乱七八糟，外键约束、字段类型、字符编码全都不统一。我第一反应就是 Kettle，毕竟这玩意儿我用了快十年，从 ETL 到数据同步，从简单清洗到复杂转换，它几乎没让我掉过链子。朋友半信半疑，问要不要找专业团队，我说先试试看，结果一个下午搞定，他当场就服了。
Kettle，全名叫 Pentaho Data Integration，开源免费，社区活跃，关键是对新手友好。你下载个客户端，拖拖拽拽就能搭出一条数据迁移流水线。我见过太多人一上来就写脚本，Shell 加 SQL 加 Python，调试起来头大，出错了还得翻日志。Kettle 最大的好处是可视化，每一步都看得见，哪个字段映射错了，哪个步骤报错，双击就能改。而且它支持几乎所有主流数据库，MySQL、Oracle、SQL Server、PostgreSQL，甚至包括 MongoDB 这种 NoSQL，迁移时不用纠结底层差异。
具体操作其实不复杂。你在 Kettle 里建一个转换，先拖出“表输入”步骤，连上源数据库，写 SQL 把要迁移的表数据读出来。这里有个小坑，很多人直接 SELECT *，但字段类型不兼容时容易报错，比如 MySQL 的 TINYINT 在 PostgreSQL 里没有对应类型，得提前转成 SMALLINT 或 BOOLEAN。我的习惯是先查一下源库的字段定义，写 SQL 时用 CAST 或 CONVERT 函数处理好类型，省得后面报错再回头改。数据读出来后，拖一个“字段选择”步骤，把字段名、类型、长度都调整一遍，比如把 VARCHAR(255) 改成 TEXT，或者把 DATETIME 改成 TIMESTAMP。再拖“表输出”步骤，连上目标库，指定表名和写入模式，插入、更新还是清空重写，随你选。
但迁移从来不是简单的复制粘贴。我遇到过最头疼的是字符集问题，源库是 latin1 编码，存了一堆中文乱码，目标库是 UTF8，直接迁移过去，中文全变成问号。解决办法是在“表输入”步骤里加个“字符集”设置，指定源库编码，然后在“字段选择”里再加一个“字符串处理”，把编码转成 UTF8。还有外键约束，源表有自增主键，目标表也有自增，但数据写进去后 ID 对不上，关联表全崩。这种情况下，我会在“表输出”步骤里关闭“自动生成主键”，手动把源 ID 写进去，再重建外键。Kettle 里有个“执行 SQL 脚本”步骤，迁移完数据后跑一遍建约束的 SQL，完美解决。
性能优化也是个绕不开的话题。几十万条数据，Kettle 默认单线程跑，像蜗牛爬。我一般会在“表输入”步骤里设置“每个事务中的行数”，比如 5000 条一批，减少内存占用。然后打开“并行执行”选项，让多个表同时读取。如果数据量上千万，还得用“批量加载”模式，Kettle 支持 PostgreSQL 的 COPY 命令和 MySQL 的 LOAD DATA，写入速度能提升十倍以上。有一次迁移 1.2 亿条日志，单线程跑了 6 小时，改成批量加载加并行，40 分钟搞定。不过要注意，批量加载会影响事务和索引，最好先删掉索引，迁移完再重建。
日志和错误处理是很多人忽略的点。Kettle 默认报错就停，但你迁移几百张表，一张表出问题就全停了，那得干瞪眼。我的做法是在“表输出”步骤里勾选“忽略插入错误”，把错误行写到单独的文件里，迁移完再回头处理。还有个“错误处理”步骤，可以专门捕获类型转换失败、主键冲突这类异常，写到日志表里。这样即使有脏数据，迁移也能跑完，拿着错误日志去修数据就行。朋友那次迁移时，有个表里混了 NULL 值和空字符串，PostgreSQL 的 NOT NULL 约束直接报错，Kettle 记录下所有问题行，我一句 UPDATE 就全修好了。
自动化调度是 Kettle 的隐藏技能。你可以在 Kettle 里建一个 JOB，把多个转换串起来，先迁移主表，再迁移子表，然后重建索引，做数据校验。再配一个定时任务，比如每天凌晨 2 点跑一次增量同步。JOB 支持条件判断和循环，比如检测源表有没有新数据，有就同步，没有就跳过。很多公司做数据库迁移时只想着一次性搬家，但业务不等人，往往需要边迁移边同步。Kettle 的 CDC（变更数据捕获）功能，通过比较时间戳或日志文件，只同步增量数据，能做到分钟级延迟。
说说踩过的坑。有次迁移 Oracle 到 MySQL，源库用了 CLOB 字段存大文本，MySQL 的 TEXT 字段最大只有 64KB，直接报错。我查了 Kettle 的文档，发现有个“Blob 转换为文本”步骤，可以把 CLOB 拆成多行，或者改用 LONGTEXT 类型。还有一次，源库自增字段的 ID 不是连续的，中间有跳号。迁移过去后，目标库自增 ID 重新生成，关联表全乱了。后来我学乖了，每次迁移前先备份，跑完后做数据校验：检查总数、抽样检查、核对关联，确保万无一失。
数据库迁移这事儿，说难不难，说简单也不简单。Kettle 就像一个工具箱，里面的扳手、螺丝刀一应俱全，但你得知道在什么场景用什么工具。我见过有人用 Kettle 迁移几十 TB 的数据，也见过有人迁移几百条记录还手忙脚乱。关键在于理解数据本身，而不是工具本身。Kettle 再强大，也救不了设计混乱的表结构。所以每次迁移前，我都会花时间梳理源库的字段定义、约束关系、数据质量，再动手做 ETL。工具是辅助，脑子才是核心。如果你正打算做数据库迁移，别急着找外包，先下载个 Kettle 试试，说不定自己就能搞定。
