1，Kettle跨平臺(tái)使用。
    例如：在AIX下（AIX是IBM商用UNIX操作系統(tǒng)，此處在LINUX/UNIX同樣適用），運(yùn)行Kettle的相關(guān)步驟如下：
    1）進(jìn)入到Kettle部署的路徑
    2）執(zhí)行 chmod *.sh，將所有shell文件添加可執(zhí)行權(quán)限
    3）在Kettle路徑下，如果要執(zhí)行transformation，就運(yùn)行./pan.sh -file=?.ktr -debug=debug -log=log.log
    其中。-file說(shuō)明你要運(yùn)行的transformation文件所在的路徑；-debug說(shuō)明日志輸出的級(jí)別；-log說(shuō)明日志輸出的路徑
    4）同理，對(duì)于job的執(zhí)行，請(qǐng)將./pan.sh更換成./kitchen.sh，其他部分說(shuō)明不變。

2，Kettle環(huán)境變量使用。
    在transformation中，Core Objects-->Job-->Set Variables，可疑設(shè)置環(huán)境變量，對(duì)于絕對(duì)路徑和相對(duì)路徑的轉(zhuǎn)換很有幫助，Kettle的跨平臺(tái)很大程度依靠他的

3，其它功能的使用。
    其它功能包括DB存儲(chǔ)過(guò)程調(diào)用，流查詢，值映射，聚合記錄等，各位自行摸索，有問(wèn)題可以和我聯(lián)系：）

4，Kettle定時(shí)功能。
    在Job下的start模塊，有一個(gè)定時(shí)功能，可以每日，每周等方式進(jìn)行定時(shí)，對(duì)于周期性的ETL，很有幫助。

5,Kettle經(jīng)驗(yàn)之日志。
    Kettle對(duì)于日志的處理，存在一個(gè)BUG，看過(guò)上一篇的人或許已經(jīng)看到了我的留言，Kettle對(duì)于日志處理有一個(gè)BUG，
    當(dāng)日志多于49M（不是50M，也不是49M），Kettle就會(huì)自動(dòng)停止，這一點(diǎn)我在源碼里面也沒(méi)有找到對(duì)應(yīng)的設(shè)置和約束，
    原因還找不到，因?yàn)槭侨罩緵](méi)有寫(xiě)，所以原因也不好跟蹤還不知道具體原因。

6，Kettle之效率提升。
    Kettle作為一款ETL工具，肯定無(wú)法避免遇到效率問(wèn)題，當(dāng)很大的數(shù)據(jù)源輸入的時(shí)候，就會(huì)遇到效率的問(wèn)題。對(duì)此有幾個(gè)解決辦法：
    1）數(shù)據(jù)庫(kù)端創(chuàng)建索引。對(duì)需要進(jìn)行查詢的數(shù)據(jù)庫(kù)端字段，創(chuàng)建索引，可以在很大程度上提升查詢的效率，最多的時(shí)候，我不創(chuàng)建索引，
 一秒鐘平均查詢4條記錄，創(chuàng)建索引之后，一秒鐘查詢1300條記錄。
    2）數(shù)據(jù)庫(kù)查詢和流查詢注意使用環(huán)境。因?yàn)閿?shù)據(jù)庫(kù)查詢?yōu)閿?shù)據(jù)輸入端輸入一條記錄，就對(duì)目標(biāo)表進(jìn)行一次查詢，而流查詢則是將目標(biāo)表讀取到內(nèi)存中，數(shù)據(jù)輸入端輸入數(shù)據(jù)時(shí)，對(duì)內(nèi)從進(jìn)行查詢，所以，當(dāng)輸入端為大數(shù)據(jù)量，而被查詢表數(shù)據(jù)量較?。◣装贄l記錄），則可以使用流查詢，畢竟將目標(biāo)表讀到內(nèi)存中，查詢的速度會(huì)有非常大的提升（內(nèi)存的讀寫(xiě)速度是硬盤(pán)的幾百倍，再加上數(shù)據(jù)庫(kù)自身?xiàng)l件的制約，速度影響會(huì)更大）。同理，對(duì)于目標(biāo)表是大數(shù)據(jù)量，還是建議使用數(shù)據(jù)庫(kù)查詢，不然的話，一下子幾百M(fèi)的內(nèi)存被干進(jìn)去了，還是很恐怖的。
    3）謹(jǐn)慎使用javascript腳本，因?yàn)閖avascript本身效率就不高，當(dāng)你使用js的時(shí)候，就要考慮你每一條記錄，就要執(zhí)行一次js所需要的時(shí)間了。
    4）數(shù)據(jù)庫(kù)commit次數(shù)，一條記錄和一百條記錄commit對(duì)效率的影響肯定是不一樣的。
    5）表輸入的sql語(yǔ)句的寫(xiě)法。有些人喜歡在表輸入的時(shí)候，將所有關(guān)聯(lián)都寫(xiě)進(jìn)去，要么from N多個(gè)表，要么in來(lái)in去，這樣，就要面對(duì)我在2）里面說(shuō)道的問(wèn)題，需要注意。
    6）注意日志輸出，例如選擇數(shù)據(jù)庫(kù)更新方式，而且日志級(jí)別是debug，那么后臺(tái)就會(huì)拼命的輸出日志，會(huì)在很大程度上影響速度，此處一定要注意。

7，常見(jiàn)的調(diào)試BUG。
    Kettle提供了很多調(diào)試的解決辦法，但是對(duì)于常見(jiàn)的調(diào)試BUG還是能避免就避免。
    1）路徑問(wèn)題。我最常遇到的問(wèn)題就是在windows下調(diào)試成功，但是部署到UNIX下出問(wèn)題，忘記將windows下路徑變成unix下，經(jīng)常會(huì)出現(xiàn)問(wèn)題。
    2）輸出端，數(shù)據(jù)庫(kù)插入更新選擇不對(duì)。輸出端，提供了三種數(shù)據(jù)庫(kù)輸出的辦法，數(shù)據(jù)庫(kù)輸出，插入/更新，更新，對(duì)于這三種，各有利弊，如果你知道數(shù)據(jù)庫(kù)輸出，完全是插入，如果有重復(fù)數(shù)據(jù)，則會(huì)報(bào)錯(cuò)；插入更新和更新，因?yàn)楦聰?shù)據(jù)時(shí)，后臺(tái)輸出很多日志，會(huì)導(dǎo)致效率很低。
   

    總體來(lái)說(shuō)，Kettle還是一個(gè)很不錯(cuò)的ETL工具，在開(kāi)源軟件里面并不多見(jiàn)，以后有Kettle相關(guān)的問(wèn)題，大家可疑相互探討。