Kettle注意事项

[size=medium][color=red]注意事项[/color][/size]

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，其他部分说明不变。

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

[color=red]3，其它功能的使用。[/color]
其它功能包括DB存储过程调用，流查询，值映射，聚合记录等。

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

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

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

[color=red]7,Kettle最佳实践[/color]
一、当输入对象为CSV文件时，将NIO Buffer Size从默认的50000改到最佳的200000。

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

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

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

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

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

七、Kettle所在操作系统优先选择Windows，在有些情况下Linux的插入速度明显偏低。

[color=red]八、尽量使用数据库连接池 [/color]

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

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

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

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

[color=red]'Group , merge , stream lookup ,split field' 这些操作都是比较慢的，想办法避免他们。 [/color]

[size=medium][color=red]插入大量数据的时候尽量把索引删掉[/color][/size]

　　尽量避免使用update ， delete 操作，[color=red]尤其是update[/color] ， 如果可以把update 变成先delete ，后insert。

　　[color=red]能使用truncate table 的时候，就不要使用delete all row 这种类似sql[/color]

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

　　[color=red]尽量缩小输入的数据集的大小[/color]（增量更新也是为了这个目的）

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

　　[color=red]尽量不要用kettle 的calculate 计算步骤[/color]，能用数据库本身的sql 就用sql ，[color=red]不能用sql 就尽量想办法用procedure [/color]， 实在不行才是calculate 步骤。