之前看到的一篇文章kettle實現資料實時增量同步，這位大佬提出了時間戳增量回滾同步的一種方式，我是根據這篇文章之上進行探索的。
但是遇到了一些問題，這裡進行一下記錄：
只能同步往前 day這段時間內的刪除操作，因為回滾了一段時間 day，作者也宣告了這點；
也只能同步往前 day這段時間內的刪除操作，為什麼呢？因為我們如果真的考慮以操作時間作為時間戳，那麼在上次更新過後，即time_stamp這個時間之後，源表裡更新了某條資料，這條資料原來的時間戳在time_stamp-day之前，那麼從源表裡的這條記錄同時也將自己的時間戳send_time更新為當前時間，那麼對比記錄這步之後，這條記錄就歸為了new，即成為了多出來的資料，而這條資料在目標表裡是有記錄的，但是new跟著的操作時間上是表輸出，那麼就會造成主鍵重複但是卻執行了插入這條資料的操作，雖然在作者的這個例子裡面沒有錯誤，但是我認為他其實是進行了替換，mysql是這樣，但是oracle估計就不一定會正確。而且對於主鍵重複插入這點，不同資料庫不同的設定會有不同的結果，但是一般情況下這是不該發生的事情，會報錯而導致job停止。
作者提出的這些其實本來在他回滾的時間段內是沒有錯誤的，可能也是其業務需求剛好可以滿足，但是對於我們自己需求，可能就無法滿足。
而如果去掉了回滾這一步，對比記錄的結果flagid就只有new，而不會有changed和deleted這兩種結果。所以兩表抽取資料進行比對似乎就失去了意義，與直接從源表資料進行時間戳的擷取，而後面直接對目標表後面接「插入更新」似乎沒有多大的區別，甚至效率更低。
對於2，這一點我覺得只有用「插入更新」是最安全的，但是作者也提出說，「插入更新」會比較慢。所以對於這一點我也沒有進行過驗證，只是提出這樣的想法。這裡做一下記錄。
補充內容：關於資料抽取和同步。
在一些複雜的場景下，使用kettle進行同步。兩個表的結構可能是完全不一致的，甚至某些字段根本沒有，比如我們為了同步目標表，需要對源資料庫裡的表進行多表關聯，資料格式轉換decode，date_form等等，但是源表裡的業務表的主鍵甚至和目標表的主鍵是不一致的，這種情況下，若同步所有欄位則自己生產的目標表的主鍵有可能和別人真實目標表裡的主鍵衝突，若目標表的主鍵是自動生成的uuid等，則可以在獲取比對資料之前就過濾掉目標表的主鍵讓其自動生產。同時需要考慮查詢的組合欄位同可以確定**資料和目標表的一行資料，即至少同時可以成為兩表的主鍵。
當然理解業務場景是是最主要的。
在實際使用的時候，發現了一些問題，在大量資料時，發現同步結果總是不對，然後想要使用全量更新時又報"違反唯一約束性條件"的錯誤，然後用預覽的方式發現在"合併記錄"步驟出現了問題，其中一條資料明明兩個表都有一模一樣的資料卻顯示的是new，在網上搜尋合併記錄相關的內容發現了這位大佬的記錄kettle合併記錄 問題解決即資料量較大時，這個合併記錄的結果可能出現在目標表和源表有相同記錄的情況下，這條記錄先出現乙個new，再出現乙個deleted,這也解釋了為什麼想要在進行一次全量更新時會報"違反唯一性約束條件"的錯，同時這位大佬也給出了解決辦法，即將目標表和源表資料都按照合併記錄裡的關鍵字進行排序，在我這裡嘗試之後發現可行。不知道這算不算是乙個bug,可能是因為合併記錄這樣的操作，在資料量較大時不可能一次性進行比較，而是批量的執行比如先比較1000條，這樣如果沒有按照合併記錄的關鍵字進行乙個排序的話，可能就會出現這樣的問題，關鍵在於避免，也就是讓deleted先出現，new後出現，這樣防止因為主鍵唯一約束性忽略了之後又刪除最後發現資料量不對，又或者直接報錯違反唯一性約束導致任務中斷。而排序之後，就能確保是deleted先出現，而new是後出現的。不知道自己理解的是否正確。
:date:2021-06-18
今天發現遇到了一些問題。
同事說有部分內容需要重新同步一下，但是他執行之前只修改了源表中的時間戳字段，改為立即執行，執行的時候報了違反唯一性條件約束。
**其原因發現，這條資料的上次同步時間是15天之前的，也就是說在目標表中時間戳還是15天之前的，所以執行的時候，如果說將源表的時間戳修改為了今天，（正常是每天晚上12點更新）然後就會導致取出的資料中，源表多出來了這一條而目標表取不到，就需要出入目標表，同時目標表這條資料已經存在了，就會出現重複插入，違反唯一性約束條件。
然後我們將改為20天，重新執行了一編就好了.
這次之所以需要重新同步的原因在於需要修改源表中的一條資料，需要同步到目標表中去。
因此考慮到為了方便，以後就將變數一直改為20天
同事提出，考慮到具體的業務是對消費者評價結果表的同步，對於評價結果為差評的資料，需要在15天內進行回訪，如果回訪後修改為好評則需要將差評改為好評。而差評資料量本身較少。也就是說，可能需要修改的資料有確切的標誌位可以區分，而且屬於少部分資料。基於此，考慮將好評和差評分開來獲取，好評資料就取上次執行完之後的資料，差評資料取上次執行完時間節點再減去天之後的資料，然後二者union之後再按照id排序。其他的步驟不變。
這樣就可以盡可能的縮短同步時間，提高效率的同時也保證了實現了差評資料改為好評後也能被同步過去。
所以說結合具體業務很重要。
kettle 增量更新
後面的乙個問號就是表示它需要接受乙個引數，你在這個table input 下面需要指定replace variable in script 選項和execute for each row 為選中狀態，這樣，kettle就會迴圈執行這個sql 執行的次數為前面引數步驟傳入的資料集的大小。kettle執...
kettle教程 增量更新
以下操作都在5.0.1版本下進行開發，其餘版本可以進行自動比對 在平時工作當中，會遇到這種情況，而且很常見。比如 增量抽取 每隔2個小時抽取截至到上次抽取時間的記錄 一 操作前提 存在3張表，源表 t student 同步日誌表 t tbrz 插入表 t target student 表結構如下圖所...
BW增量更新的理解（時間戳）
在bw中，存在兩種資料抽取方式，完全更新與增量更新，完全更新是每次把截至到某個時間的資料全部抽取，增量抽取則只抽取上次和本次抽取之間更新的資料，很顯然，增量抽取能夠提高系統效率，根據sap幫 助的說法，增量更新又分為時間戳和增量佇列兩種方法，其中財務資料的抽取為時間戳增量法，後勤資料的抽取為增強佇列...