优化Kettle大数据处理性能的五大实战技巧

1. 从一次“龟速”迁移说起：为什么你的Kettle突然变慢了？

几年前我接手一个老系统的数据迁移项目，需要把几千万条用户订单记录从一个旧库挪到新设计的表结构里。一开始挺顺利，我用了Kettle，也就是大家常说的Pentaho Data Integration，画了几个简单的“表输入”和“表输出”步骤，测试了几万条数据，嗖嗖地就跑完了，当时觉得这工具真省心。

结果等到正式跑全量数据时，噩梦开始了。前几个小时还能忍，越到后面速度越慢，从每分钟处理几万条掉到每分钟几百条，整个迁移预估要跑好几天，这谁受得了？我盯着日志，看着那条缓慢爬升的记录条数，心里直发毛。这其实就是很多朋友第一次用Kettle处理大数据时都会踩的坑：数据量小的时候，Kettle是个灵活的瑞士军刀；数据量一大，如果没调教好，它可能就变成了一把生锈的钝刀。

问题的根源在哪呢？本质上，Kettle是一个运行在JVM（Java虚拟机）上的ETL工具。当数据量激增时，几个关键环节很容易成为瓶颈：数据库连接与通信效率、数据在内存中的流转方式、任务执行的并发策略，以及JVM本身的内存管理。 比如，默认情况下，Kettle向数据库写入数据是每1000条提交一次事务，对于几十万条数据这没问题，但对于几千万条，频繁的事务提交会带来巨大的I/O开销。再比如，数据库连接的参数默认是为通用场景设计的，未必适合大批量、高速的数据灌入。

所以，优化Kettle处理大数据的性能，绝不是简单换个更快的服务器，而是需要一套“组合拳”。下面我就结合自己踩过的那些坑和填坑的经验，分享五个经过实战检验的优化技巧，让你手里的Kettle重新“飞”起来。

2. 第一招：给数据库连接“开小灶”——参数优化是基石

很多人优化性能，一上来就想着堆硬件、改代码，其实最容易见效的往往是调整配置。Kettle与数据库打交道，连接参数就是它的“通行证”，通行证权限不对，速度自然上不去。

2.1 通用加速参数：让批量操作真正“批”起来

首先，无论你的输入或输出数据库是MySQL、PostgreSQL还是其他，有一组参数是提升批量读写效率的利器。你可以在Kettle里，双击你的数据库连接，在“连接属性”或“选项”参数栏里添加它们。

useServerPrepStmts=false
rewriteBatchedStatements=true
useCompression=true
characterEncoding=utf8

我来解释一下这几个“宝贝”是干嘛的：

• rewriteBatchedStatements=true：这是MySQL JDBC驱动的“王牌”参数。没有它，你即使让Kettle批量发送10000条INSERT语句，驱动也是拆成一条条发给数据库，批量名存实亡。开启后，JDBC驱动会帮你把多条SQL语句重写为一句INSERT INTO ... VALUES (...), (...), ...的形式，一次网络往返就能插入大量数据，效率提升是数量级的。我实测过一个2000万行的表，开启这个参数后，写入速度提升了近8倍。
• useServerPrepStmts=false：