kettle工具异常退出及宕机各种情况整理以及使用心得

项目场景：

一台服务器运行近60个转换任务，其中不乏涉及大数据量、高调度频率和复杂的mapping

---

问题描述：

KETTLE在使用过程偶尔会出现异常退出及宕机情况

---

原因分析：

（1）软件自身存在不规律间息性异常退出（发生频率并不高）

（2）工作流以及抽取频度较多，适当分发

（3）内存溢出（1、高并发问题 2、初始化设置）

---

解决方案：

改善：

1、重新设置JVM大小
2、重新规划工作流（合并相同频度工作流、优化语句）
(1) 注：合并相同频度工作流出现退出情况无法排查
3、拆分工作流（降低Kettle压力方式之一）

其它：
1、kettle执行过程出现Couldn’t get row from result set Io异常:Socket read timed out。
原因：出现这个问题原因可能是MySQL数据库设置的wait_timeout过短（缺省为8小时），由于MySQL服务在长时间不连接之后断开了，断开之后的首次请求会抛出这个异常

kettle使用注意事项：

1）进入到Kettle部署的路径
2）执行 chmod *.sh，将所有shell文件添加可执行权限
3）在Kettle路径下，如果要执行transformation，就运行./pan.sh -file=?.ktr -debug=debug -log=log.log 其中。-file说明你要运行的transformation文件所在的路径；-debug说明日志输出的级别；-log说明日志输出的路径
4）同理，对于job的执行，请将./pan.sh更换成./kitchen.sh，其他部分说明不变。

2、Kettle环境变量使用。

    在transformation中，Core Objects->Job->Set Variables，可疑设置环境变量，对于绝对路径和相对路径的转换很有帮助，Kettle的跨平台很大程度依靠他的 

3、其它功能的使用。

    其它功能包括DB存储过程调用，流查询，值映射，聚合记录等。 

4、Kettle定时功能。

    在Job下的'start模块'，有一个定时功能，可以每日，每周等方式进行定时，对于周期性的ETL，很有帮助。

5、Kettle经验之日志。

    Kettle对于日志的处理，存在一个BUG，看过上一篇的人或许已经看到了我的留言，Kettle对于日志处理有一个BUG， 当日志多于49M（不是50M，也不是49M），Kettle就会自动停止，这一点我在源码里面也没有找到对应的设置和约束， 原因还找不到，因为是日志没有写，所以原因也不好跟踪还不知道具体原因。 

6、Kettle之效率提升。

    Kettle作为一款'ETL工具'，肯定无法避免遇到效率问题，当很大的数据源输入的时候，就会遇到效率的问题。对此有几个解决办法： 
    1）数据库端创建索引。对需要进行查询的数据库端字段，创建索引，可以在很大程度上提升查询的效率，最多的时候，我不创建索引， 一秒钟平均查询4条记录，创建索引之后，一秒钟查询1300条记录。 
    2）数据库查询和流查询注意使用环境。因为数据库查询为数据输入端输入一条记录，就对目标表进行一次查询，而流查询则是将目标表读取到内存中，数据输入端输入数据时，对内存进行查询，所以，当输入端为大数据量，而被查询表数据量较小（几百条记录）， 则可以使用流查询，毕竟将目标表读到内存中，查询的速度会有非常大的提升（内存的读写速度是硬盘的几百倍，再加上数据库自身条件的制约，速度影响会更大）。同理，对于目标表是大数据量，还是建议使用数据库查询，不然的话，一下子几百M的内存被干 进去了，还是很恐怖的。 
    3）谨慎使用javascript脚本，因为javascript本身效率就不高，当你使用js的时候，就要考虑你每一条记录，就要执行一次js所需要的时间了。 
    4）数据库commit次数，一条记录和一百条记录commit对效率的影响肯定是不一样的。 
    5）表输入的sql语句的写法。有些人喜欢在表输入的时候，将所有关联都写进去，要么from N多个表，要么in来in去，这样，就要面对我在2）里面说道的问题，需要注意。 
    6）注意日志输出，例如选择数据库更新方式，而且日志级别是debug，那么后台就会拼命的输出日志，会在很大程度上影响速度， 
       此处一定要注意。 

7、Kettle最佳实践

    一、当输入对象为CSV文件时，将NIO Buffer Size从默认的50000改到最佳的200000。 

    二、当输出对象为表输出时，将提交记录数量从默认的1000改到最佳的4000。 

   三、尽可能关闭转换过程中一切与数据库相关的日志，如表日志、索引日志等。 

    四、在数据库去重时，使用普通索引而不是唯一性索引。 

    五、在插入数据之前，先使索引unusable，数据导完之后再rebuild索引。需要注意的是，像数据库去重这种需要索引来优化查询速度的情况可以排除在外。 

    六、索引和表数据使用不同的表空间，尽可能的减少IO争用。 

    七、Kettle所在操作系统优先选择Windows，在有些情况下Linux的插入速度明显偏低。 
    
    八、尽量使用数据库连接池 

    九、尽量提高批处理的'commit size' 

    十、尽量使用缓存，缓存尽量大一些 

   十一、Kettle 是Java 做的，尽量用大一点的内存参数启动Kettle. 

    十二、可以使用sql 来做的一些操作尽量用sql 

   十三、 'Group , merge , stream lookup ,split field' 这些操作都是比较慢的，想办法避免他们。 

   十四、插入大量数据的时候尽量把索引删掉 

十五、尽量避免使用update ， delete 操作，尤其是update ， 如果可以把update 变成先delete ，后insert。

十六、能使用truncate table 的时候，就不要使用delete all row 这种类似sql

十七、如果删除操作是基于某一个分区的，就不要使用delete row 这种方式（不管是delete sql 还是delete 步骤），直接把分区drop 掉，再重新创建

十八、尽量缩小输入的数据集的大小（增量更新也是为了这个目的）

十九、尽量使用数据库原生的方式装载文本文件(Oracle 的sqlloader ， mysql 的bulk loader 步骤)

二十、尽量不要用kettle 的calculate 计算步骤，能用数据库本身的sql 就用sql ，不能用sql 就尽量想办法用procedure ， 实在不行才是calculate 步骤。