下面是試驗的主要步驟：
在上一篇文章中LZ已經介紹了，實驗的環境和實驗目的。
在本篇文章中主要介紹側重於對Kettle ETL的相應使用方法，
在這里LZ需要說明一下，LZ成為了避免涉及索引和表連接等操作，
在數據庫mysql中重新創建一個不帶有索引和外鍵約束的 customers數據庫表。
但數據集合不變。
所以在后文中國使用,mysql.customers來代替前篇文章中的test.customers。
下面的截圖是使用Spoon工具來整體對這個流程的描述：
（圖）
首先需要使用Kettle來建立兩個對數據庫數據源的連接：
如圖所示： 其中我們所使用的：classicmodels.customers(數據庫名.表名)
這張表對應的數據源連接名稱是： MysqlConn1 創建數據源連接MysqlConn1如下圖所示：
而需要與classicmodels.customers做數據同步的表mysql.customers(數據庫名.表名) 這個對應的連接是：
MysqlConn2。 在Spoon中創建MysqlConn2的截圖如下所示：
在創建數據庫連接之后，需要在相應的transformation中 拽入表輸入這一個step。
因為是關於不同數據庫中的數據表做數據同步，
所以數據流的流動方向是，
從mysql.customers表中出來，
一一與classicmodels.customers表中的每個記錄進行比較等等操作。
而它們來自於不同的數據源的兩張表， 所以需要兩個表輸入（step），
每一個step對應的是kettle源碼中的 不同的類，而你從工具欄中將相應的step拖到工作區間的時候，
實質上是完成了，對類對象的實例化操作。
為了方便記憶，把classicmodels.customers對應的那個表輸入命名為 classicmodels.customers；
而把mysql.customers對應的那個表輸入step重新命名為mysql.customers(這里命名是隨意的，是為了方便記憶，
當然讀者還可以根據個人的習慣，比如順便標志出哪一個是 舊數據源，哪一個是新數據源，等等)
具體的操作如下圖所示：
在這里僅選取針對於classicmodels.customers這一個表輸出進行講述（二者的設置過程是一樣的）：
在這里需要注意的是，首先應該從下拉菜單中選取與之對應的數據源連接，
然后千萬不能忘到此僅僅完成的是對數據庫的選取，
接下來需要點擊“獲取SQL查詢語句”
一次來選取這個數據源主要是針對數據庫的那個表進行抽取數據的。
然后呢，從核心對象工具欄中選擇出來，合並記錄的Step，
將其拖拽到對應的工作區域，並將倆個表輸入step與之相連接
（hop指的是用於連接兩個step的矢量連線）。
接下來就是根據實驗要求對合並記錄進行相應的設定，具體的操作請看截圖：
在這里面需要說明的是， 彈出窗口的第一個選項： 舊數據源應該是需要被同步的，就是里面的數據比較陳舊， 需要根據新數據源中的數據進行調整。
而新數據源，在實際的應用中指的是每天或是定期獲取的最新數據所對應的數據源。
舊數據源通常是根據新數據源進行相應的增、刪、改等一系列操作的。
對於所測試的數據，我是這樣想的， 首先應該自己先想好，測試的情況應該大致分為幾種情況。
然后根據相應的情況來自己來寫一些少量的幾條簡單的數據集合。
進行測試， 待到得到想要的結果之后，這個時候基本上你的step設計已經完成了， 這樣再在這個transformation上面來跑比較大的數據集的話就比較能考到結果了。
跑大的數據集
一個是可以找到一些你自己之前沒有考慮到的情況，
二就是可以可以很容易看出來到底數據是在哪一個step的上面 耗費的時間比較長，
可以針對耗時比較長的step作相應的優化處理。
進行step替換或是其他的一些腳本什么的（抱歉，這里LZ暫時也不沒有親自試驗驗證）預先處理的方法。
其實提高同步數據效率它的主旨就是減少需要處理的數據，
所以在進行同步數據處理之前，
可以調用一些分支step來過濾或是刪除一些重復的數據等等。
具體情況是需要具體的分析的。
這里需要說明一下的就是：Kettle中的合並記錄這一個Step是這樣的：
源庫是不提供保存增刪改信息的，
而Kettle會提供一種用於 對比輸入的新舊兩個數據源，
通過關鍵字進行逐個比較每條記錄。
會根據具體的比對的出一下的四種返回值， 而且這四個返回值的類型是String字符串類型， 是的，沒錯，因為Kettle就是使用Java實現的，
所以一些變量直接與Java中的數據類型是直接對應的。
1、"identical":它對應的是關鍵字在新舊數據源中， 都是一致的，並且該關鍵字所在的記錄的各個字段的域值相同的話，
則對舊數據源所對應的數據表不做任何處理。
2."changed":關鍵字在新舊數據源中都是存在的，但是關鍵字所對應的 記錄的域值是不相同的，
這是要將舊數據源依照新數據源做更新操作。
3."new": 舊數據源所對應的數據表中沒有與新數據源表中出現的關鍵字匹配的話，
則將該新數據源關鍵字對應的記錄插入到舊數據源對應的數據表中。
4."deleted": 在舊數據源數據表中的關鍵字與新數據源表中的所有關鍵字都是不匹配的。
這種情況就需要把舊數據源中的該關鍵字對應的那條記錄從舊數據源表中刪除。
所需要進行匹配的關鍵字段是新舊記錄源的主鍵所在字段， 而所要進行修改和更新的字段是舊數據庫中的所有字段。
為了確保程序的正常進行， 可以先針對合並記錄這個step先快速啟動一下，
下圖是啟動合並記錄之后，相應的返回值截圖：
由於記錄有點長，所以只截取了對應的changed、deleted、identical、 這四個所對應的字段。
剛剛好和設想的是一致的。（也就是說與LZ設計的數據表中的數據值，詳情請看前一篇實驗環境搭建，其實說不上是設計，就是簡單修改幾個數吧...呵呵）
而就像上面所講述的一樣，合並記錄在執行之后返回{identical,changed,deleted,new}這四種String的值。
而后續的synchronize after merge 這個step會根據接收到的 這四種不同的String做出相應的對舊數據源的{增、刪除、更新、或是不動} 這四種操作。
既然這一步得到了與設想一直的結果， 那么繼續向下使能合並記錄到同步數據之間的hop吧~
正如想象的一樣， 數據被成功的從新數據源對應的classicmodel.customers中 同步到舊數據源對應的mysql.customers數據表中。
下圖是整體的運行時間截圖：
你看，mysql.customers對應寫的是10條LZ改寫的數據。
而classicmodel.customers對應的是我們從第三方下載的數據集合進行簡化之后，
所得到的的數據集中的記錄數目。
接下來將要實驗的是，針對有索引和外鍵還有各種約束進行數據同步中所需要采用的方法。
其實，數據庫中的數據表在實際的情況下，真的是各種關聯，並且是牽一發而動全身的。
所以，還是繼續學習吧，加油啦，米娜~