一次真实的 Kettle 数据迁移实战2 亿行订单表搬家的全程复盘【免费下载链接】pentaho-kettlePentaho Data Integration ( ETL ) a.k.a Kettle项目地址: https://gitcode.com/gh_mirrors/pe/pentaho-kettle数据迁移最怕的不是数据量大而是看着成功了实则埋了雷。Pentaho Data Integration江湖人称 Kettle是开源世界应用最广的 ETL 工具专门干抽取—转换—加载这件事。上个月我接到一个任务把一张 2 亿行的订单表从旧库搬进新平台全程用了 Kettle中间翻车三次、返工两次。这篇 Kettle 数据迁移教程不打算罗列功能清单而是把我踩过的坑和最终的解法原样摊开——读完你会拿到一套能直接照抄的打法先盘点、再分批、后增量、终对账外加一张落地检查单。周五下午那通电话把迁移两个字拍在了我桌上客户说得很轻松就一张订单表搬到新库就行。入职三年的直觉告诉我凡是用就开头的需求通常都不简单。我去查了一下那张表2 亿行、1.2TB、九成字段带索引主键还是雪花 ID——连个规整的自增序号都没有。更麻烦的是时间窗正式迁移只能放在周六凌晨两点到六点四个小时。白天系统还在跑新订单照常落库意味着我没法让旧系统彻底停下来。这一条直接决定了后面所有的技术选型。动手之前先给老库做一次CT 扫描真正开始搭流程之前我先花了一整天摸家底。Kettle 的 Spoon 图形界面里有个经常被忽略的功能——元数据搜索Edit → Search Meta data它能在复杂转换里快速定位某个步骤的字段定义、数据库连接和备注说明。对于数据迁移来说这一步相当于手术前的 CT把每张表有哪些字段、字段是什么类型、哪几个字段被索引、哪张表和哪张表有关联一次性摊开看清楚。图注用 Spoon 的元数据搜索功能梳理字段结构与数据流是数据迁移动手前最重要的一道工序。看完 CT 结果我记下三笔账要搬的字段有 47 个、其中有 3 个字段在新库改了类型和长度、有 2 张关联字典表必须一起搬。这三笔账成了后面所有流程的验收标准。这个阶段的产物不是流程而是一张字段映射表。别嫌它土后面每一次怎么证明搬对了的争论最后都得回到这张表上。第一次翻车全量抽取把 JVM 内存直接打爆第一版方案很天真一个 Table Input 步骤SELECT * FROM orders一个 Table Output 步骤写进新库中间啥也不加。测试环境跑了几万行丝般顺滑。于是我在周六凌晨一点半按下了执行按钮——半小时后日志开始刷OutOfMemoryErrorCarte 服务直接假死。问题出在 Table Input 的实现方式上它一次把查询结果全部装进内存再往下游传。2 亿行数据多少内存都不够。Kettle 的 Table Input 步骤支持直接写 SQL源码在 engine/src/main/java/org/pentaho/di/trans/steps/tableinput/TableInput.java但它不会替你自动分页得自己动手。正确的做法是按主键范围分批抽取每一批就是一个独立的小查询SELECT * FROM orders WHERE order_id BETWEEN ? AND ?配合一个循环作业把游标从 0 推进到 2 亿每批 20 万行。批与批之间互不干扰哪批挂了就从哪批重跑——这就是俗称的断点续传。改完之后内存占用从 16G 掉到 2G 以内批与批之间还能开并行吞吐量反而上去了。数据是过去了字段却变了味类型与编码的两记暗拳第二批坑藏在新旧库的数据类型差异里。旧库某字段是VARCHAR(255)新库设计成了TEXT这还好说真正阴人的是金额字段旧库用DECIMAL(18,2)偏偏有几个历史订单存了-0.00搬过去之后新库的校验逻辑不认直接整批回滚。更隐蔽的是字符集问题。旧库是GBK新库是UTF-8我抽样了前一万行看着都正常结果在某个第三方备注字段里一万行之后才出现乱码——抽样太浅假象太深。解法很朴素也很管用在转换链里显式声明目标字段类型。用 Select Values 步骤把 47 个字段逐一映射长度、精度、编码、是否允许空值全部写死金额字段加一个计算步骤统一规范化。Kettle 里这类转换步骤很多Select values - some variants.ktr这类示例转换就放在仓库的示例目录里assemblies/samples/src/main/resources/transformations/拿来改改就能用。顺带说一句乱码问题请整表全量扫描一遍字符集别抽样。抽样校验的代价是几分钟乱码入库后的代价是几天的返工。深夜 11 点迁移窗口撞上了业务高峰前面两关过了还剩一个最大的心结白天系统还在写数据。周六凌晨我搬完的是截至迁移时刻的快照可周日早上八点一开门新订单写进了旧库而我的目标表安安静静躺在新库里——两边的数据从此分道扬镳。这就引出了增量同步的问题。当时有两条路一是用 CDC变更数据捕获工具监听旧库的日志把变更一条条搬过去二是如果旧表有可靠的更新时间戳字段就按时间戳把上次迁移之后新增或修改的记录筛出来定时跑增量任务。我的订单表恰好有updated_at字段于是走第二条路代价最小。增量任务的骨架长这样先记下上次迁移的截至时间点下次启动时只取updated_at 上次时间点的数据用主键去目标表做 upsert——新记录插入、旧记录更新删除的先不管因为业务上订单不删只做状态流转。这一套下来周日早上九点新旧库的数据就差不到五分钟完全在可接受范围内。如果连时间戳字段都没有别硬造轮子直接上 CDC 工具或者干脆在旧库补一个updated_at触发器——这个改动通常在 DBA 那里审批很快。没搬丢、没搬错用什么证明——对账三件套迁移完成不等于交付完成。客户真正关心的问题是你怎么证明 2 亿行一张不少、金额一分不差我用了三个手段缺一不可行数对账COUNT(*)旧库等于新库这是底线。注意要按时间范围分批对不然 2 亿行跑一次 COUNT 能把你等睡着。字段值对账对主键和几个关键字段做交集/差集比对找出旧有新增无和旧无新增有的记录。Kettle 里有专门的 Data Validator 步骤官方示例叫Data Validator - all usecases with error handling.ktr专门干这个。统计值对账对金额、数量等数值字段分别算SUM和AVG两边一比差多少一目了然。别小看这步它最能兜住字段值类型被悄悄截断这类隐蔽问题。对账不是验证一遍就完。增量同步模式下每跑完一批增量都要把这三件套重跑一遍直到业务双跑期结束、确认无误后再让新库正式接管。让流程自己跑起来而不是半夜爬起来点按钮如果每次迁移都要人盯着这个方案就是不完整的。Kettle 的作业Job可以把设置变量 → 分批抽取 → 转换 → 加载 → 归档 → 发通知串成一条流水线流程中途断了也能从上一步续跑。图注Kettle 作业把变量设置、文件处理、归档等环节串成自动流水线是批量数据同步方案落地为生产作业的标准形态。我这里用了它的 Carte 服务来跑定时任务周六凌晨两点的全量迁移、每天早上七点的增量同步全部由 Carte 调度失败时自动触发邮件告警。关于 Carte 的接口细节官方有一份现成的文档可以直接查CarteAPIDocumentation.md。结尾的加分项让工具说客户的语言最后一个容易被忽略的细节这个迁移方案是要交给对方运维团队长期维护的。客户界面是英文运维团队的操作习惯偏中文那就得把作业名、错误提示做成双语。Kettle 的语言资源文件是键值对结构仓库里带了 Pentaho Translator 工具见图可以批量维护不同语言环境下的界面文本和报错信息避免报错看不懂、不会修的尴尬。图注用 Pentaho Translator 批量维护多语言消息键保证迁移作业在跨语言团队里也能被看懂、被维护。明天就能开始的一条路复盘完这趟迁移我把最要紧的经验压缩成一张四行清单下次直接照做盘点先行动手前用元数据搜索把字段、类型、索引、关联表摸透产出一张字段映射表。分批是底线凡是超过内存量级的数据一律按主键分批抽取批批可断点续传。增量别偷懒有时间戳用时间戳没时间戳上 CDC双跑期结束前不要切正式流量。对账才算完行数、字段值、统计值三件套每批增量跑完都对一遍用日志留证。如果你想自己练一遍而不是只看文章最快的路径是把这个仓库克隆下来git clone https://gitcode.com/gh_mirrors/pe/pentaho-kettle然后打开assemblies/samples/src/main/resources/transformations/目录从 Getting Started Transformation.ktr 开始逐个打开 Data Validator、Metadata injection 这几个示例转换跑一遍。真实的数据迁移从来不是一次执行就结束的事它是一套搬得过去、对得上账、续得上流的机制——而这套机制今天就能在你的电脑上开始搭。【免费下载链接】pentaho-kettlePentaho Data Integration ( ETL ) a.k.a Kettle项目地址: https://gitcode.com/gh_mirrors/pe/pentaho-kettle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考