什么是資料漂移？
資料漂移是 ODS 資料的一個頑疾，通常指 ODS 表的同一個業務日期資料中包含前一天或后一天凌晨附近的資料或者丟失當天的變更資料，
實際場景
公司主營互聯網金融業務，因此有了一張資料量龐大的申請人資訊記錄表，這張表里的時間欄位非常多，因為整個業務場景涉及到好幾段流程：
客戶提交申請貸款請求 → 我們接受申請貸款請求 → 進入決策引擎 → 決策引擎呼叫第三方資料系統 →決策引擎回傳結果報告 → 匹配發送記錄和回傳報告 → 反饋給客戶發送結果
可見每一段子流程（子域）里都會有相應的時間欄位， 選擇使用客戶的提交申請時間來做磁區欄位，也是為了貼近客戶的實際體驗，即某一天的申請記錄明細就應該是那一天客戶提交給我們的所有申請資訊，實際上并給如此，主要有兩種場景導致了異樣的發生：
1、通道延遲
我們接受到客戶的申請貸款的請求后，到提交給核心信貸系統以及決策引擎系統這段時間理論上是很快的，秒級回應，但某些時候因為網路波動或者服務器故障，會導致申請積壓，卡在某一環節，如果正好卡在落庫之前，這時客戶在 T 天提交貸款申請請求，積壓解決后申請記錄落庫實際發生在 T+1 天，導致 T+1 天凌晨做ETL 資料同步時這批申請資訊記錄獲取不到，最終資料平臺丟失了一部分資料，
2、特殊業務場景
有一類特殊的業務場景叫”先提后審“，客戶提交一種特殊的申請貸款請求后，需要客服審核內容，審批通過后才可實際發送，如果客戶在客服下班時間段提交了這種申請貸款請求，那么實際要到第二天客服上班后才會實際被提交，落庫也發生在客服審批之后，同上一種情況，也會發生丟失資料的情況，
解決方案
1、延遲重傳
某些公司采用了很粗暴的解決方案，T+1 天允許 T 這天的資料存在資料漂移的現象，但是在 T+7 天，對 T天資料進行重傳，恢復這些丟失資料，保證最終狀態的資料是完整的，這種方式跟公司業務也是跟契合的，因為申請貸款的狀態會在 7 天內做更新（因為決策引擎系統回傳的狀態報告也會有幾天的延遲，約定 7 天內不回傳報告計為未知狀態不再更新），這種方式本意是用作資料更新的，結果順帶緩解了資料漂移，（不算解決是因為 T+1 天到 T+7 天，資料仍然有丟失，不完美）
2、更合理的時間切分欄位
既然按照申請貸款時間戳切分，會出現資料漂移，那么就考慮換一個業務場景的時間戳，在申請貸款這個業務場景下，選擇放款時間作為時間切分欄位，放款一旦發生，就不會變化；放款作為核心關鍵功能，除非巨大故障也極少發生延遲現象，（當然真的發生了后期再補資料，因不可抗拒因素產生的問題是無解的，只要做到可補救即可），如果系統有一個統一的放款服務，這個欄位的一致性也是有保證的，
但公司沒有采用這種切分方式，我的理解是有兩個原因：
1）存在月結客戶，并不是所有客戶的業務都是先申請再放款的，一些特殊業務大客戶是先放款再申請的，
針對這些客戶，并不存在真正的放款操作，
2）目前放款服務是散落在系統的各個地方的，并沒有統一管理起來，導致放款這個操作本就不具備業務邏輯上的統一性，
針對問題 1），其實是有解的，對月結客戶仍然可以走一遍放款流程，記錄下一個“偽放款時間”，甚至真放款也無不可，無非額度扣成負數，當然公司目前沒有這么操作，針對月結客戶，額度是直接鎖死的，月結客戶的還款計劃依賴月度的離線計算腳本，這樣的操作同時帶來了資料不統一的問題，在線客戶的賬單來自交易記錄（放款，系統操作），而月結客戶的賬單來自申請記錄統計（離線統計，腳本計算），因為這種資料源的不統一，公司的核心賬務計算一直不如意，實在是一個遺憾，
針對問題 2），公司的線上申請貸款業務發展了*年，這么多年里新增了許許多多的業務模塊、功能、乃至針對大客戶的特權特殊服務，放款操作并不統一，甚至存在一小部分客戶是非系統操作，而是由計算腳本放款的，不統一的放款服務也帶來了一定的混亂局面，實為另一個遺憾，所幸這個問題以及在推進解決中，公司已經在規劃一個放款整體的服務，作為各業務線的中臺應用，解決這個歷史頑疾，
當然放款時間作為切分欄位，針對申請貸款業務來說是很合適的，可惜并不是所有業務場景下都能找得到這樣的業務時間，很多公司的情況有很多許多業務功能，使用單一的業務時間會遺漏很多其他程序的變化記錄，
比如很常見的電商業務，就有下單、支付、退款、售后等程序，并不適合以某一單一業務時間做切分欄位，
3、前后冗余
既然取一天的資料會有資料漂移現象且發生在凌晨，那么自然而然就有一種方式：我們多向前一天要一部分資料，也向后一天多要一部分資料，根據經驗，一般是15 分鐘，保證資料只多不少，切分時按照需要的業務時間再過濾，這樣可以解決那些因為延遲造成的資料漂移，
但同時也帶來了問題：
如果多獲取了 T+1 天的一些更新變化，會導致 T 天的最終狀態沒有被保留，最終存盤在 T 天的資料實際是T+1 天凌晨的狀態，這對下游的相關統計會造成一些誤差，另外，上邊提到的特殊業務場景也并沒有解決，
4、多時間欄位共同限制
這一部分的感受不是很深刻，按照一些文章的說法：
根據日志時間冗余前后資料，然后用修改時間過濾非當天資料，這一步幾乎和之前描述一樣，保證系統原因的遺漏不發生；
根據日志時間冗余后一天資料的部分，按照主鍵以日志時間升序取第一條，為了獲取最接近 T 天狀態的資料；
將 1，2 步驟的資料做全外連接，限制業務時間來獲取 T 天資料，
相對而言，貸款申請業務是一種比較單一、簡單的業務場景，而簡單的業務場景，解決方案自然也比較簡單粗暴，目前**某些公司采用的 T+7 重傳，很好地解決了資料更新與資料漂移的問題，雖然我認為統一的放款時間做時間切分會更合理，對財務計算更更友好，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/545992.html
標籤：大數據