關于數據漂移問題和解決

數據漂移問題出現(xiàn)的背景

我們通常構建數倉的ODS層時,會考慮按照某個時間戳將數據切分后分區(qū)存儲。
ODS表中常出現(xiàn)的時間戳分為四個類型:

  1. 源表中標識數據記錄更新的時間戳字段,modified_time。
  2. 源表中標識源庫日志記錄更新的時間戳字段,log_time。
  3. 源表中記錄具體業(yè)務過程發(fā)生的時間戳字段,proc_time。
  4. 標識數據從源表抽取到數倉的時間戳字段,extract_time。

理想情況下,上述幾類時間戳記錄的時間一致,這樣無論使用哪個時間戳作為ODS表分區(qū)的依據,同一調度周期內的業(yè)務發(fā)生時間都位于同一個分區(qū),不存在數據漂移。
但是,生產上通常會出現(xiàn)如下問題,這個問題可能導致這幾類時間不一致:

  1. 數據抽取需要時間,所以extract_time往往晚于其他三個時間。
  2. 前臺業(yè)務系統(tǒng)手工修改數據時,并沒有同步更新modified_time。
  3. 由于應用系統(tǒng)的壓力,導致modified_time和log_time晚于proc_time。

這樣,我們在ODS中使用各種時間戳切分數據時會面臨各種問題:
為了便于分析,我們假設統(tǒng)計周期是天,即ODS表每天數據存到一個分區(qū)。

1. 如果根據extract_time切分數據。

由于extract_time往往晚于proc_time,導致proc_time發(fā)生在某天末尾的少部分記錄對應的extract_time會在第二天開頭,這時如果按extract_time會導致當天proc_time對應的記錄存在當天和第二天兩個分區(qū)中。

2. 如果根據modified_time切分數據。

可能某業(yè)務過程開始發(fā)生在11:59:59,而業(yè)務過程結束,在數據庫生成數據的時間在第二天,也就是說proc_time在11:59:59的記錄,對應的modified_time記錄的時間在第二天。這時如果按照modified_time分區(qū),會導致proc_time在11:59:59的記錄存在第二天的分區(qū)內。

3. 根據log_time切分數據。

由于log_time是由應用系統(tǒng)日志程序記錄的,當生成環(huán)境發(fā)生網絡或者系統(tǒng)壓力時,log_time會晚于proc_time。這時如果按照log_time分區(qū),會發(fā)生和上述一樣的問題。

4. 如果直接根據proc_time切分數據。

如果該事實表只記錄了一個業(yè)務過程,是可行的。
但是如果事實表記錄了多個業(yè)務過程,只用某一個業(yè)務過程的proc_time做為分區(qū)時間,那么當天分區(qū)必定會遺漏其他業(yè)務過程的數據。

如何處理數據漂移

最常用的處理方法是在ODS表每個時間分區(qū)中向前、后多冗余一些數據,保障數據只多不少,具體應用的時候可以讓下游的表根據自身業(yè)務需要用不同的proc_time去做篩選處理。
當然這種方式對累積快照事實表是有一些統(tǒng)計風險的,例如一個訂單是當天支付的,但是第二天凌晨申請退款關閉了,那么當這個訂單離線同步到ODS時,記錄該訂單的記錄只會保留最終的訂單狀態(tài)。那么統(tǒng)計當天訂單數量時會出現(xiàn)錯誤。

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

友情鏈接更多精彩內容