Kettle 小结

接触了Kettle也有一段时间了，挖个坑总结一下。

Kettle的使用和总结，是基于Pentaho解决方案。这本书虽然网上认为是进阶书籍，但在实际的使用过程中，发现也是入门的绝好方式。书中对Kettle有了很完善的使用方法，介绍了大多数的使用方案。整体的流程可以结合实例进行参考，通过该书入门Kettle是一种不错的方式。

具体的Kettle安装，使用网上也有很多。源码的分析在网上也是有的（其实我还没有到看源码的地步）。就我个人的理解而言，Kettle对大多数的数据库操作进行了封装，在使用中可以方便的调用，减少写代码时候的对照。p.s.手写过移库的操作就知道，有些库的字段命名感人，对照起来还麻烦。

在数据迁移的过程中，整体的流程是 连接 →表名、字段名获取→数据读取并进入缓冲池→数据的输出。在连接时，调用了驱动；字段名、表名获取调用了sql语句；在Kettle缓冲区中，可以设置批量操作、、事务、分区\集群，并发等；输出同输入。在这些部分中，很明显的可以发现，Kettle减少了我们对底层的操作，让开发者可以集中注意力于数据的迁移，数据的清洗等过程。在使用的过程中，方便。但具体的实践过程中，也有其他的问题。

以下是我在使用时遇到的问题。

1.增量更新问题

增量更新有4种方法，当时选取的是根据时间戳进行增量更新。在SQL Server 2008 R2中，时间的类型是DateTime，在表输入的过程中，发生的问题是，这个DateTime类型和Kettle的当日的类型是匹配不上的，DateTime会显示为诡异的0.0000000020170307这种形式（乘以较大数输出发现的），但Kettle的日期形式是timestamp类型的，两者匹配不上！！！当时的心情是崩溃的，先是写死了一个固定的日期设定，发现在实际生产中不现实，遂弃用。再是自己手动增加一个timestamp类型匹配，然后被领导否了，拒绝在生产库上加奇怪的字段。最后的解决方案是在SQL语句中过滤，用了DateDiff函数判断是否在更新时间内产生新数据，从而获得结果。

2.定时问题

Kettle中自带定时，在job中的start中，但是。。。不好用啊。。。只要你设置了重复启动这个选项，你的job基本上是跑不动的，所以。。。心塞塞啊。最后没办法写了批处理文件来调用，但是时间间隔这东西，貌似也只能控制在一定范围内了。。。此外，这里提供Tips。在配置java环境时，可以将kettle的文件目录添加到Path中，这样调用Kitchen时会减少很多的操作。

3.端口占用

当时，历经了入门的蛋疼阶段，总算磨出了第一个增量更新，虽然很简陋，但是本机上还是跑的很欢了。于是领导给了一台测试机跑了跑，然而第二天就跑挂了23333。被批了一顿，查了查问题，端口占用多了。增量嘛，5秒一次嘛，高并发嘛，短连接嘛，这些东西聚在一起，出现的问题是科科，端口占用多了。Kettle的转换是每个转换都是线程啊，当时还作死改了并发数，每个转换就占用了2，30个端口，要增量的库一多，BOOM。解决：连接池，事务。在连接池中设置连接数，会显著的减少端口数，使用唯一的连接这个选项可以将转换进行事务操作，减少因为奇怪的问题导致数据库的污染。

4.mysql中文的操作和大数据的插入

mysql的jdbc。。。不作评价。。。移动到库里是？？？这种的，需要在连接选项时设置parameterEncoding utf8。本来在本地是正常的，一到生产上就蛋疼，事实证明，备份很重要，多试错也很重要。还有就是大数据插入问题，当你调用jdbc时，会惊讶的发现mysql的jdbc驱动为什么插入库这么慢？？？这时，你就需要去加几个字段了，有三个字段需要修改，

useServerPrepStmts=false

rewriteBatchedStatements=true

useCompression=true

改了后，有飞一样的感觉。

总结

Kettle这货，在迁移的时候还是很好用的。但是很底层的事情，需要你自己去解决。当然，现在的开源软件也是很成熟的。但是，貌似厉害的开源都被收购了（mysql，sun），所以入坑要谨慎，毕竟公司省的就是你的劳动力钱，否则为啥放着现成的BI软件不用，找你从头开始学。最近也有很多待解决的问题，比如性能问题，Kettle这货一开起来就是70的cpu使用率，在批处理的调用下，如果你开了其它东西，性能会慢很多，当然，貌似这个值是固定的，只要你cpu够好，数值还是很低的。还有，在增量时，在杂项中选择将日志记录到数据库，会时不时显示有错误，但是在Kitchen执行的过程中，写入的error日志中却找不到。很诡异的问题。。。