接觸了Kettle也有一段時間了声畏，挖個坑總結一下。
Kettle的使用和總結榨咐，是基于Pentaho解決方案介却。這本書雖然網(wǎng)上認為是進階書籍，但在實際的使用過程中块茁，發(fā)現(xiàn)也是入門的絕好方式齿坷。書中對Kettle有了很完善的使用方法，介紹了大多數(shù)的使用方案数焊。整體的流程可以結合實例進行參考永淌，通過該書入門Kettle是一種不錯的方式。
具體的Kettle安裝佩耳，使用網(wǎng)上也有很多遂蛀。源碼的分析在網(wǎng)上也是有的（其實我還沒有到看源碼的地步）。就我個人的理解而言干厚，Kettle對大多數(shù)的數(shù)據(jù)庫操作進行了封裝李滴，在使用中可以方便的調用，減少寫代碼時候的對照蛮瞄。p.s.手寫過移庫的操作就知道所坯，有些庫的字段命名感人，對照起來還麻煩挂捅。
在數(shù)據(jù)遷移的過程中芹助，整體的流程是 連接 →表名、字段名獲取→數(shù)據(jù)讀取并進入緩沖池→數(shù)據(jù)的輸出。在連接時状土，調用了驅動无蜂；字段名、表名獲取調用了sql語句蒙谓；在Kettle緩沖區(qū)中斥季，可以設置批量操作、彼乌、事務泻肯、分區(qū)\集群，并發(fā)等慰照；輸出同輸入。在這些部分中琉朽，很明顯的可以發(fā)現(xiàn)毒租，Kettle減少了我們對底層的操作，讓開發(fā)者可以集中注意力于數(shù)據(jù)的遷移箱叁，數(shù)據(jù)的清洗等過程墅垮。在使用的過程中，方便耕漱。但具體的實踐過程中算色，也有其他的問題。
以下是我在使用時遇到的問題螟够。
1.增量更新問題
增量更新有4種方法灾梦，當時選取的是根據(jù)時間戳進行增量更新。在SQL Server 2008 R2中妓笙，時間的類型是DateTime若河，在表輸入的過程中，發(fā)生的問題是寞宫，這個DateTime類型和Kettle的當日的類型是匹配不上的萧福，DateTime會顯示為詭異的0.0000000020170307這種形式（乘以較大數(shù)輸出發(fā)現(xiàn)的），但Kettle的日期形式是timestamp類型的辈赋，兩者匹配不上ｖ耆獭！钥屈！當時的心情是崩潰的悟民，先是寫死了一個固定的日期設定，發(fā)現(xiàn)在實際生產(chǎn)中不現(xiàn)實焕蹄，遂棄用逾雄。再是自己手動增加一個timestamp類型匹配，然后被領導否了，拒絕在生產(chǎn)庫上加奇怪的字段鸦泳。最后的解決方案是在SQL語句中過濾银锻，用了DateDiff函數(shù)判斷是否在更新時間內產(chǎn)生新數(shù)據(jù)，從而獲得結果做鹰。
2.定時問題
Kettle中自帶定時击纬，在job中的start中，但是钾麸。更振。。不好用啊饭尝。肯腕。。只要你設置了重復啟動這個選項钥平，你的job基本上是跑不動的实撒，所以。涉瘾。知态。心塞塞啊。最后沒辦法寫了批處理文件來調用立叛，但是時間間隔這東西负敏，貌似也只能控制在一定范圍內了。秘蛇。其做。此外，這里提供Tips彤叉。在配置java環(huán)境時庶柿，可以將kettle的文件目錄添加到Path中，這樣調用Kitchen時會減少很多的操作秽浇。
3.端口占用
當時浮庐，歷經(jīng)了入門的蛋疼階段，總算磨出了第一個增量更新柬焕，雖然很簡陋审残，但是本機上還是跑的很歡了。于是領導給了一臺測試機跑了跑斑举，然而第二天就跑掛了23333搅轿。被批了一頓，查了查問題富玷，端口占用多了璧坟。增量嘛既穆，5秒一次嘛，高并發(fā)嘛雀鹃，短連接嘛幻工，這些東西聚在一起，出現(xiàn)的問題是科科黎茎，端口占用多了囊颅。Kettle的轉換是每個轉換都是線程啊，當時還作死改了并發(fā)數(shù)傅瞻，每個轉換就占用了2踢代，30個端口，要增量的庫一多嗅骄，BOOM胳挎。解決：連接池，事務溺森。在連接池中設置連接數(shù)串远，會顯著的減少端口數(shù)，使用唯一的連接這個選項可以將轉換進行事務操作儿惫，減少因為奇怪的問題導致數(shù)據(jù)庫的污染。
4.mysql中文的操作和大數(shù)據(jù)的插入
mysql的jdbc伸但。肾请。。不作評價更胖。铛铁。。移動到庫里是却妨？饵逐？？這種的彪标，需要在連接選項時設置parameterEncoding utf8倍权。本來在本地是正常的，一到生產(chǎn)上就蛋疼捞烟，事實證明薄声，備份很重要，多試錯也很重要题画。還有就是大數(shù)據(jù)插入問題默辨，當你調用jdbc時，會驚訝的發(fā)現(xiàn)mysql的jdbc驅動為什么插入庫這么慢苍息？缩幸？壹置？這時，你就需要去加幾個字段了表谊，有三個字段需要修改钞护，
useServerPrepStmts=false
rewriteBatchedStatements=true
useCompression=true
改了后，有飛一樣的感覺铃肯。
總結
Kettle這貨患亿，在遷移的時候還是很好用的。但是很底層的事情押逼，需要你自己去解決步藕。當然，現(xiàn)在的開源軟件也是很成熟的挑格。但是咙冗，貌似厲害的開源都被收購了（mysql，sun）漂彤，所以入坑要謹慎雾消，畢竟公司省的就是你的勞動力錢，否則為啥放著現(xiàn)成的BI軟件不用挫望，找你從頭開始學立润。最近也有很多待解決的問題，比如性能問題媳板，Kettle這貨一開起來就是70的cpu使用率桑腮，在批處理的調用下，如果你開了其它東西蛉幸，性能會慢很多破讨，當然，貌似這個值是固定的奕纫，只要你cpu夠好提陶，數(shù)值還是很低的。還有匹层，在增量時隙笆，在雜項中選擇將日志記錄到數(shù)據(jù)庫，會時不時顯示有錯誤又固，但是在Kitchen執(zhí)行的過程中仲器，寫入的error日志中卻找不到。很詭異的問題仰冠。乏冀。。
