轉載鏈接：
https://paxinla.github.io/posts/2020/04/qian-tan-shu-ju-piao-yi.html
https://www.twblogs.net/a/5d4518ebbd9eee541c2fee9c/?lang=zh-cn
什么是數(shù)據(jù)漂移
數(shù)據(jù)漂移(Data Drift)，指的是將進入數(shù)據(jù)倉庫的數(shù)據(jù)尿孔，偏離標準俊柔、正常或預期的情況纳猫。它三種表現(xiàn)形式:
Structural Drift 婆咸，指的是數(shù)據(jù)源的數(shù)據(jù)結構發(fā)生了改變，比如字段增減芜辕、字段數(shù)據(jù)類型變更等尚骄。
Semantic Drift ，源于(歷史)數(shù)據(jù)的改變侵续，比如過了一段時間后倔丈，才發(fā)現(xiàn)已入倉庫的歷史數(shù)據(jù)有錯誤等。
Infrastructure Drift 状蜗，源于系統(tǒng)依賴的軟件或平臺發(fā)生變化后需五，與變化前不兼容。
數(shù)據(jù)漂移的后果主要有3個1:
Garbage in, garbage out.
Trust takes a lifetime to build and only a moment to lose.
The biggest expense is opportunity cost.
傳統(tǒng)的 ETL 過程是脆弱且不透明的轧坎，這意味著它對 structural drift 和 semantic drift 是敏感的宏邮。也就是說發(fā)生了“數(shù)據(jù)漂移”就是發(fā)生了異常狀況。
如何處理數(shù)據(jù)漂移
國內面試一般提及“數(shù)據(jù)漂移”時缸血，通常指的是 semantic drift 蜜氨，特別是指 ETL 過程中的在預期的計算周期里不是剛好包含了所有預期的數(shù)據(jù)的情況。比如 ODS 里某個T+1表的同一個業(yè)務日期數(shù)據(jù)中包含前一天或者后一天凌晨附近的數(shù)據(jù)或者丟失當天的變更數(shù)據(jù)捎泻。這時就丟失了當天的變更數(shù)據(jù)飒炎，或者說“上一天”(D)的數(shù)據(jù)漂移到了“下一天”(D+1)。
傳統(tǒng)的 ETL 過程大多是周期性調度的笆豁。典型的 ETL 調度將一系列相互之間有數(shù)據(jù)依賴關系的 ETL 任務郎汪，組織為一個 DAG 赤赊，整個 DAG 依據(jù)事先設定的調度周期或觸發(fā)條件啟動本輪的執(zhí)行。
場景一: 因積壓造成數(shù)據(jù)“遲到”
假設煞赢，在D日發(fā)生的新數(shù)據(jù)抛计，因網(wǎng)絡故障/服務器處理能力等原因積壓，在 ETL 過程運行時照筑，尚未完全落到數(shù)據(jù)源上爷辱。待積壓解決后，部分D日的數(shù)據(jù)就被當成了D+1日的數(shù)據(jù)朦肘。這種場景在那些7×24小時連續(xù)發(fā)生的業(yè)務過程上較為常見饭弓。
網(wǎng)上有的解決方案是延遲重傳。比如在D+4日對D日數(shù)據(jù)進行重傳或重放媒抠，就能恢復在D日 ETL 時丟失的數(shù)據(jù)弟断。這種做法，看起來能“修正”數(shù)據(jù)倉庫中的歷史數(shù)據(jù)趴生，以使其“最終狀態(tài)”是完整的阀趴。還有的方案是，既然知道了數(shù)據(jù)倉庫的數(shù)據(jù)有漂移的情況苍匆，也知道漂移經(jīng)常發(fā)生的時間長度刘急，那么在使用這些數(shù)據(jù)的時候，就放寬時間窗口浸踩，往前往后都“多要”一部分數(shù)據(jù)叔汁。這樣取到的數(shù)據(jù)就沒有“丟失”了，但是會有“多余”的數(shù)據(jù)检碗。
可是据块，除非數(shù)據(jù)倉庫的下游能接受在D+4日后才使用D日的數(shù)據(jù)。否則折剃，D日時已丟失數(shù)據(jù)造成的結果另假，包括當時進入倉庫的數(shù)據(jù)及依賴于它們的統(tǒng)計數(shù)據(jù)，都已經(jīng)對下游造成了影響怕犁。對這種場景边篮，我認為要么只能是對 ETL 任務的依賴條件判斷上，與源系統(tǒng)達成一致奏甫，能明確判斷每個周期里戈轿，預期的源數(shù)據(jù)是否全部就緒；要么就接受在D+1日才就緒的數(shù)據(jù)就屬于D+1的數(shù)據(jù)扶檐。其他的方法只能算是“修補”上了漂移的數(shù)據(jù)凶杖，并不算解決了漂移的問題胁艰。
場景二: 業(yè)務過程里的特例
在業(yè)務過程發(fā)生時款筑，因對部分特別客戶的優(yōu)待(比如大客戶付費時間不固定)或者人為因素不可控(比如某些必須依賴人工提交的D日數(shù)據(jù)智蝠，他就是要在D+1或D+2日提交)等，造成源數(shù)據(jù)就緒情況難以預測奈梳。
對這樣的特殊業(yè)務杈湾，通常也只能根據(jù)各個企業(yè)自己實際的業(yè)務情況，在數(shù)據(jù)倉庫用戶的可接受范圍內攘须，采取特事特辦的處理方法漆撞。
小結
如何處理遲到的數(shù)據(jù)，是 Kimball 的 ETL 子系統(tǒng)里的“遲到數(shù)據(jù)處理器”關注的情況于宙。
我的看法是浮驳，總的來說，數(shù)據(jù)發(fā)生了“漂移”捞魁，就可以認為是發(fā)生了異常至会。只能根據(jù)每個企業(yè)具體場景去事后修補數(shù)據(jù)，并沒有什么自動化的通用方法來處理“漂移”但是可重跑的任務和完整的歷史數(shù)據(jù)谱俭，還是對這個修補的過程有助益奉件。。最好還是盡量在設計 ETL 過程時昆著，能夠確定好各個數(shù)據(jù)源的數(shù)據(jù)就緒條件和判斷手段县貌，從根源上盡量避免數(shù)據(jù)漂移。
