版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/xpliruizhi123/article/details/54580850

最近发现KETTLE抽数越来越慢，特别是增量INSERT/UPDATE的时候，速度已经达到了令人发指的地步（从一个400W数据规模的表中每天增量量抽取30W数据的TRASFORMATION 竟然要20个小时！！！！读取速率是5条/s......），这个情况是在我的KETTLE工具从3.2升级到7.0版本后发现的，（以前也慢，只是还能接受，升级之后已经到了不改不行的地步了），但是KETTLE是进步的，所以原因还是要从自身找起。

目前为止我发现的导致KETTLE抽取数据慢有以下几个原因：

A：SPOON 启动时候内存较小，在spoon.bat这个启动文件中，配置的有JVM的内存XMX,("%PENTAHO_DI_JAVA_OPTIONS%"=="" set PENTAHO_DI_JAVA_OPTIONS="-           Xms8192m" "-Xmx8192m" "-XX:MaxPermSize=4096m"),默认这个是256M，512M  256M， 其中Xms是指JVM初始分配的堆栈的内存，Xmx是指JVM分配的堆栈的内存 （JAVA代码能涉及到的存储数据变量的内存）最大是多少，所以XMS必须要<= XMX,XX:MaxPermSize,是指JVM给自己分配的非堆栈内存（供虚拟机程序自己开销）我的因 为是在服务器上跑，因此改成了8192M\8192M\4096M,这个改不能是无限的加大，需要考虑总的内存大小，一般来说网上参考是最大堆栈内存不超过总内存的3/8有的也说是 一半，总之得有个度。

B：抽数的源数据库关键字段没有索引，以我这张表为例，我每天需要按照日期（data_update_date）从DB2增量抽取更新数据,但是这个字段没有建索引，因此也会导致抽数慢。

C：抽数的源数据库关键字段索引在SPOON里面失效，给大家看两段SQL就知道了：

SQL1:select TO_CHAR(TO_DATE(t_date,'YYYYMMDD')+1,'YYYYMMDD') from delta_table where t_name='~~~'

SELECT * FROM SAPCP1.ZCSSDH053 WHERE REPORT_CREATE_DATE >= ?

SQL2:select    t_date   from delta_table where t_name='~~~'

SELECT * FROM SAPCP1.ZCSSDH053 WHERE REPORT_CREATE_DATE >  ?

两段SQL执行的都是相同的数据提取过程，但是在REPORT_CREATE_DATE 字段建立索引的情况下，SQL1比SQL2快20倍。原因是用 > 号的时候，索引会失效，而用>=则不会。

于是我在网上搜索了这种明明应该走 但是并没有走索引的情况（以下是粘贴的）
                            使用<> （有的时候单独的使用< 或者>的时候也有可能）
                            like的时候不能确定最前面的字符 也就是把’％_’的时候
                            单独使用复合索引的非前导列
                           表没有分析
                           字符类型不匹配 发生了显示的或者隐式的转换或者对索引列进行了运算
                            使用了 not in 或者 not exist
                           基于cbo时全表扫描代价小
                            b-tree索引is not null的时候会走，is not null的时候不会走 位图的时候都会 复合索引的时候 is not null会 is null时要看前导列

D：目的地数据库表的索引太多，这个原因显而易见，因为插入数据的时候会重新更新索引表，索引太多，插入时候会变慢。

E：插入流程中数据COMMIT过程太频繁，数据插入的COMMIT太频繁也是很影响效率的，，30W的数据提交300次和提交30次速度显然是不一样的，只要你的设置的内存能暂时容得下插入的数据，COMMIT可以尽量设高一点（kettle有限制不能超过50000）

F：INSERT/UPDATE  过程与 表输入，这两个流程肯定是后者快很多，但是笔者在实际过程中会遇到一个问题就是，万一ETL抽数流程的某个环节发生了错误，导致ETL后面的流程DUMP掉，要么没插入要么部分插入，这样的话，肯定是没有更新关键字段的。（关键字段更新是放在所有流程最后一步），这样的话，当笔者解决掉这个问题重新启动流程，如果重头开始，对于INSERT/UPDATE字段没什么问题，数据重复会进行更新，但是对于表输入的话，就会有问题，昨天写入的数据已经存在了，这样不作处理肯定还会报错。KETTLE 7.0 解决了这个问题，在JOB层设计的时候提前设定好失败数据回滚的操作，在回滚的操作里面删掉已经插入的数据，这样的话用表输入就没有后顾之忧了。

最后，30W数据进过以上优化时间从20个小时缩短到0.5个小时~~我暂时发现这些优化方式，各位高人有其他方法欢迎交流~~~！！！！