Posted on 2008-01-28 19:20
shenxiangl 閱讀(4363)
評論(6) 編輯 收藏 所屬分類:
ETL
ETL高級教程
在昨天的帖子里面，我介紹了一些ETL初級的東西，不知道大家是否已經(jīng)掌握，我現(xiàn)在介紹一些Kettle應(yīng)用中，比較有幫助的一些地方。
1，Kettle跨平臺使用。
例如：在AIX下（AIX是IBM商用UNIX操作系統(tǒng)，此處在LINUX/UNIX同樣適用），運行Kettle的相關(guān)步驟如下：
1）進入到Kettle部署的路徑
2）執(zhí)行 chmod *.sh，將所有shell文件添加可執(zhí)行權(quán)限
3）在Kettle路徑下，如果要執(zhí)行transformation，就運行./pan.sh -file=?.ktr -debug=debug -log=log.log
其中。-file說明你要運行的transformation文件所在的路徑；-debug說明日志輸出的級別；-log說明日志輸出的路徑
4）同理，對于job的執(zhí)行，請將./pan.sh更換成./kitchen.sh，其他部分說明不變。
2，Kettle環(huán)境變量使用。
在transformation中，Core Objects-->Job-->Set Variables，可疑設(shè)置環(huán)境變量，對于絕對路徑和相對路徑的轉(zhuǎn)換很有幫助，Kettle的跨平臺很大程度依靠他的
3，其它功能的使用。
其它功能包括DB存儲過程調(diào)用，流查詢，值映射，聚合記錄等，各位自行摸索，有問題可以和我聯(lián)系：）
4，Kettle定時功能。
在Job下的start模塊，有一個定時功能，可以每日，每周等方式進行定時，對于周期性的ETL，很有幫助。
5,Kettle經(jīng)驗之日志。
Kettle對于日志的處理，存在一個BUG，看過上一篇的人或許已經(jīng)看到了我的留言，Kettle對于日志處理有一個BUG，當日志多于49M（不是50M，也不是49M），Kettle就會自動停止，這一點我在源碼里面也沒有找到對應(yīng)的設(shè)置和約束，原因還找不到，因為是日志沒有寫，所以原因也不好跟蹤還不知道具體原因。
6，Kettle之效率提升。
Kettle作為一款ETL工具，肯定無法避免遇到效率問題，當很大的數(shù)據(jù)源輸入的時候，就會遇到效率的問題。對此有幾個解決辦法：
1）數(shù)據(jù)庫端創(chuàng)建索引。對需要進行查詢的數(shù)據(jù)庫端字段，創(chuàng)建索引，可以在很大程度上提升查詢的效率，最多的時候，我不創(chuàng)建索引，一秒鐘平均查詢4條記錄，創(chuàng)建索引之后，一秒鐘查詢1300條記錄。
2）數(shù)據(jù)庫查詢和流查詢注意使用環(huán)境。因為數(shù)據(jù)庫查詢?yōu)閿?shù)據(jù)輸入端輸入一條記錄，就對目標表進行一次查詢，而流查詢則是將目標表讀取到內(nèi)存中，數(shù)據(jù)輸入端輸入數(shù)據(jù)時，對內(nèi)從進行查詢，所以，當輸入端為大數(shù)據(jù)量，而被查詢表數(shù)據(jù)量較小（幾百條記錄），則可以使用流查詢，畢竟將目標表讀到內(nèi)存中，查詢的速度會有非常大的提升（內(nèi)存的讀寫速度是硬盤的幾百倍，再加上數(shù)據(jù)庫自身條件的制約，速度影響會更大）。同理，對于目標表是大數(shù)據(jù)量，還是建議使用數(shù)據(jù)庫查詢，不然的話，一下子幾百M的內(nèi)存被干進去了，還是很恐怖的。
3）謹慎使用javascript腳本，因為javascript本身效率就不高，當你使用js的時候，就要考慮你每一條記錄，就要執(zhí)行一次js所需要的時間了。
4）數(shù)據(jù)庫commit次數(shù)，一條記錄和一百條記錄commit對效率的影響肯定是不一樣的。
5）表輸入的sql語句的寫法。有些人喜歡在表輸入的時候，將所有關(guān)聯(lián)都寫進去，要么from N多個表，要么in來in去，這樣，就要面對我在2）里面說道的問題，需要注意。
6）注意日志輸出，例如選擇數(shù)據(jù)庫更新方式，而且日志級別是debug，那么后臺就會拼命的輸出日志，會在很大程度上影響速度，此處一定要注意。
7，常見的調(diào)試BUG。
Kettle提供了很多調(diào)試的解決辦法，但是對于常見的調(diào)試BUG還是能避免就避免。
1）路徑問題。我最常遇到的問題就是在windows下調(diào)試成功，但是部署到UNIX下出問題，忘記將windows下路徑變成unix下，經(jīng)常會出現(xiàn)問題。
2）輸出端，數(shù)據(jù)庫插入更新選擇不對。輸出端，提供了三種數(shù)據(jù)庫輸出的辦法，數(shù)據(jù)庫輸出，插入/更新，更新，對于這三種，各有利弊，如果你知道數(shù)據(jù)庫輸出，完全是插入，如果有重復數(shù)據(jù)，則會報錯；插入更新和更新，因為更新數(shù)據(jù)時，后臺輸出很多日志，會導致效率很低。
總體來說，Kettle還是一個很不錯的ETL工具，在開源軟件里面并不多見，以后有Kettle相關(guān)的問題，大家可疑相互探討。