摘自阿里大數據之路
什么是數據漂移
通常我們把從源系統同步進入數倉的第一層數據稱為 ODS或者staging層數據，接入層 。
數據漂移是接入層數據的一個頑疾。
數據漂移定義：接入層ODS表同一個業務日期數據中包含前一天或者后一天凌晨附近的數據或者丟失當天的變更數據。
數據漂移出現的原因
通常落地數倉的ODS表會按時間切分做分區存儲，實際上往往由於時間戳字段的准確性問題導致發生數據漂移。通常有四類時間戳：
modified_time:數據庫記錄某條數據更新的時間。
log_time:數據庫日志記錄某條數據更新的時間。
proc_time:具體業務過程發生時間。
extract_time:數據記錄被抽取時間。
理論上這四個時間是一致的，但由於以下原因會出現數據漂移：
1）同一條記錄的數據抽取時間extract_time明顯是晚於另外三個時間的，如果用這個字段切分，ODS某個分區中的數據會包含前一天末尾的數據，並丟失當天末尾的數據。
2）如果用數據庫記錄的更新時間modified_time，前台業務系統手工訂正數據時可能會遺忘同步更新該時間，導致該抽取的數據被遺漏掉。
3）另外，由於網絡或者系統壓力問題，log_time或者modified_time可能會晚於proc_time，導致數據漂移。
4）如果我們直接使用proc_time時間進行切分，這種情況僅僅對包含一個業務過程的ODS表有效果，如果該表每條記錄需要存儲多個業務過程，則用proc_time切分會丟失其他發生在當天的業務過程記錄。
處理數據漂移的方式
1.多獲取后一天的數據
既然很難解決數據漂移的問題，那么就在ODS每個時間分區中向前、向后多冗余一些數據，保證數據只會多不會少，而具體的數據切分讓下游根據自身不同的業務場景用不同的業務時間proc_time來限制。但是這種方式會有一些數據誤差，例如一個訂單是當天支付的，但是第二天凌晨申請退款關閉了該訂單，那么這條記錄的訂單狀態會被更新，下游在統計支付訂單狀態時會出現錯誤。
2.通過多個時間戳字段限制時間來獲取相對准確的數據
1) 首先根據log-time分別冗余前一天最后15分鍾的數據和后一天凌晨開始15分鍾數據，並用modified_time過濾非當天數據，確保數據不會因為系統問題而被遺漏
2) 然后根據log_time獲取后一天15分鍾的數據；針對此數據按照主鍵根據log_time做升序排列去重，因為我們要獲取的是最接近當天記錄變化的數據（數據庫日志將保留所有變化的數據，但是落地到ODS表的是根據主鍵去重獲取的最后狀態的數據）
3) 最后將前兩步結果數據做全外連接，通過限制業務時間proc_time來獲取我們所需要的數據.