看完了實踐一與實踐二、我們大致對otter有了一個簡單認識。
那麼，我們有個大膽的想法，能否直接用otter來充當etl工具呢？我們從數據庫多個業務表中選取數據，然後同步到一張累計事實表中
說幹就幹：
一、需求梳理：
1.接口層接收到上游單據時，需要在目標表新建一條訂單記錄
2..接口層接收到訂單，流入wms系統後，需要對目標表相應的記錄做更新，且在生命週期裏每個節點都做更新（'組波、揀選、二分、打包、發運'）
3.業務系統的數據瘦身不能影響到雲平臺的數據統計
二、故事拆分
1.新建接口層映射關係，out_order表映射到雲上的t_order表，out_order表的insert和update操作會轉義成對t_order表的操作
2.新建wms層映射關係，t_pick_order、t_pick_order_detail_sub、t_pick_wave_detail、t_pick_list、t_pick_task、t_pick_divide_task_order、t_box等表，insert及update操作全部轉義成對t_order表的update操作
3.用warehouse_id來區分各個倉庫的數據
三、t_order表設計
四、配置多表同步到單張表
按照我們在實踐一和實踐二中的步驟，將涉及到的表映射關係搭建起來。如下圖：
這裏要着重講兩點：
1.如何保證在強業務時序下的數據同步？假設t_pick_order表的數據先行update，t_order表的數據後insert，那肯定會丟掉了pick_order表數據
這裏我們分兩步處理：a、我們依賴於權重值的設置，權重值最高的同步映射，最後處理，反則反之。
b、在配置pipeline的時候，我們可以調整並行度的值，otter同步快的一個關鍵的點就是利用並行度的滑動窗口設計，使得同一時間內多個tcp連接執行數據處理。
我們將並行度調整到1，則可以理解成爲串行同步。
2.如何將wms表的sql強轉爲update？
通過查看otter源碼發現,otter對insert、update操作的輸出結果爲insert on duplicate key update。
換句話說就是，如果你設計的目標表，與你的源表結構相差很大的時候，且有強業務邏輯的話，請避開otter的insert on duplicate key update，原因有兩個，第一個是insert on duplicate key update只會從結果集中選擇一條來更新，第二個是如果主鍵沒設計好，會生成大量的髒數據。
那麼，如何把insert、update操作強轉成only update呢？以下幾點都注意到的話，就很簡單：
a.自定義代碼中，將EventType改爲UPDATE("U"),
b.保持keyList和columnList中沒有重複的字段名，舉例：如果keyList中有字段pick_order_id且columnList也存在此字段，otter在處理數據時就會報錯找不到字段映射關係
c.keyList中的所有列，isKey字段必須爲true
d.一定要oldKeyList，oldKeyList的size必須和keyList的size一致，且字段名也一致。如果沒有oldKeyList，會走insert on duplicate key update。
下面貼一段強轉的代碼僅供參考：
完成