數(shù)據(jù)漂移的處理
- 通常我們把從源系統(tǒng)同步進人數(shù)據(jù)倉庫的第一層數(shù)據(jù)稱為 ODS stag ing 層數(shù)據(jù)郭计，阿里巴巴統(tǒng)稱為 ODS 。數(shù)據(jù)漂移是 ODS 數(shù)據(jù)的一個 頑疾践险，通常是指 ODS 表的同一個業(yè)務日期數(shù)據(jù)中包含前一天或后凌晨附近的數(shù)據(jù)或者丟失當天的變更數(shù)據(jù)。
- 由于 ODS 需要承接面向歷史的細節(jié)數(shù)據(jù)查詢需求，這就需要物理落地到數(shù)據(jù)倉庫的 ODS 表按時間段來切分進行分區(qū)存儲 伪货，通常的做法是按某些時間戳字段來切分，而實際上往往由于時間戳字段的準確性問題導致發(fā)生數(shù)據(jù)漂移钾怔。
通常碱呼，時間戳字段分為四類：
數(shù)據(jù)庫表中用來標識數(shù)據(jù)記錄更新時間的時間戳字段（假設這類字段叫 modified time ）。
數(shù)據(jù)庫日志中用來標識數(shù)據(jù)記錄更新時間的時間戳字段·（假設這類宇段叫 log_time）宗侦。
數(shù)據(jù)庫表中用來記錄具體業(yè)務過程發(fā)生時間的時間戳字段 （假設這類字段叫 proc_time）愚臀。
標識數(shù)據(jù)記錄被抽取到時間的時間戳字段（假設這類字段extract time）。
理論上矾利，這幾個時間應該是 致的姑裂，但是在實際生產(chǎn)中，這幾個時間往往會出現(xiàn)差異梦皮，可能的原因有以下幾點
由于數(shù)據(jù)抽取是需要時間的炭分， extract_ti me 往往會晚于前三個時間。
- 前臺業(yè)務系統(tǒng)手工訂正數(shù)據(jù)時未更新 modified_time由于網(wǎng)絡或者系統(tǒng)壓力問題剑肯， log_time 或者 modified_time 會晚proc time
通常的做法是根據(jù)其中的某 個字段來切分 ODS 表捧毛，這就導致產(chǎn)生數(shù)據(jù)漂移。下面我們來具體看下數(shù)據(jù)漂移的幾種場景。
根據(jù) extract_ti me 來獲取數(shù)據(jù)呀忧。這種情況數(shù)據(jù)漂移的問題最明顯.根據(jù) modified_time 限制师痕。在實際生產(chǎn)中這種情況最常見，但是往往會發(fā)生不更新 modified time 而導致的數(shù)據(jù)遺漏而账，或者凌晨時間產(chǎn)生的數(shù)據(jù)記錄漂移到后天胰坟。 - 根據(jù) log_time 限制。由于網(wǎng)絡或者系統(tǒng)壓力問題泞辐， log time 會晚proc_time 笔横，從而導致凌晨時間產(chǎn)生的數(shù)據(jù)記錄漂移到后一天。例如咐吼，在淘寶“雙 l l ”大促期間凌晨時間產(chǎn)生的數(shù)據(jù)量非常大吹缔，用戶支付需要調(diào)用多個接口，從而導致 log time 晚于實際的支付時間锯茄。
- 根據(jù) proc_time 限制厢塘。僅僅根據(jù) proc_time 限制，我們所獲取的ODS 表只是包含一個業(yè)務過程所產(chǎn)生的記 肌幽，會遺漏很多其他過程的變化記錄晚碾，這違背了 ODS 和業(yè)務系統(tǒng)保持 致的設計原則處理方法主要有以下兩種：
( l ）多獲取后 天的數(shù)據(jù)既然很難解決數(shù)據(jù)漂移的問題，那么就在 ODS 每個時間分區(qū)中向
前喂急、向后多冗余 些數(shù)據(jù)格嘁，保障數(shù)據(jù)只會多不會少，而具體的數(shù)據(jù)切分讓下游根據(jù)自身不同的業(yè)務場景用不同的業(yè)務時間 proc time 來限制但是這種方式會有一些數(shù)據(jù)誤差煮岁，例如 個訂單是當天支付的讥蔽，但是第二天凌晨申請退款關閉了該訂單涣易，那么這條記錄的訂單狀態(tài)會被更新画机，下游在統(tǒng)計支付訂單狀態(tài)時會出現(xiàn)錯誤。
(2 ）通過多個時間戳字段限制時間來獲取相對準確的數(shù)據(jù)首先根據(jù) log_time 分別冗余前一天最后 15 分鐘的數(shù)據(jù)和后一天凌晨開始 15 分鐘的數(shù)據(jù)新症，并用 modified time 過濾非當天數(shù)據(jù)步氏，
確保數(shù)據(jù)不會因為系統(tǒng)問題而遺漏。然后根據(jù) log_time 獲取后一天 15 分鐘的數(shù)據(jù) 針對此數(shù)據(jù)徒爹，按
照主鍵根據(jù) log_time 做升序排列去重荚醒。因為我們需要獲取的是最接近當天記錄變化的數(shù)據(jù)（數(shù)據(jù)庫日志將保留所有變化的數(shù)據(jù)，但是落地到 DS 表的是根據(jù)主鍵去重獲取最后狀態(tài)變化的數(shù)據(jù)）隆嗅。
最后將前兩步的結果數(shù)據(jù)做全外連接界阁，通過限制業(yè)務時間proc_time 來獲取我們所需要的數(shù)據(jù)。下面來看處理淘寶交易訂單的數(shù)據(jù)漂移的實際案例胖喳。我們在處理“雙 ”交易訂單時發(fā)現(xiàn)泡躯，有 大批在11 月11日23:59:59 左右支付的交易訂單漂移到了 12 。主要原因是用戶下單支付后系統(tǒng)需要調(diào)用支付寶的接口而有所延遲，從而導致這些訂單最終生成的時間跨天了较剃。即 modified time log_time 都晚于 proc_time如果訂單只有一個支付業(yè)務過程咕别，則可以用支付時間來限制就能獲取到正確的數(shù)據(jù)。但是往往實際訂單有多個業(yè)務過程 下單写穴、支付惰拱、成
功，每個業(yè)務過程都有相應的時間戳字段啊送，并不只有支付數(shù)據(jù)會漂移偿短。如果直接通過多獲取后 天的數(shù)據(jù)，然后限制這些時間馋没，則可以獲取到相關數(shù)據(jù)翔冀，但是后 天的數(shù)據(jù)可能已經(jīng)更新多次，我們直接獲取到的那條記錄已經(jīng)是更新多次后的狀態(tài)披泪，數(shù)據(jù)的準確性存在 定的問題纤子。因此，我們可以根據(jù)實際情況獲取后 15 分鐘的數(shù)據(jù)款票，并限制個業(yè)務過程的時間戳字段（下單控硼、支付、成功）都是“雙11 ”當天的艾少，然后對這些數(shù)據(jù)按照訂單的 modified time 升序排列卡乾，獲取每個訂單首次數(shù)據(jù)變更的那條記錄。此外缚够，我們可以根據(jù) log_time 分別冗余前 天最后 15 分鐘的數(shù)據(jù)和后 天凌晨開始 15 分鐘的數(shù)據(jù)幔妨，并用 modified time 過濾非當天數(shù)據(jù)，針對每個訂單按照 log time 進行降序排列 谍椅，取每個訂單當天最后一次數(shù)據(jù)變更的那條記錄误堡。最后將兩份數(shù)據(jù)根據(jù)訂單做全外連接，將漂移數(shù)據(jù)回補到當天數(shù)據(jù)中雏吭。
