什麼是數據漂移？ 數據漂移是 ODS 數據的一個頑疾，通常指 ODS 表的同一個業務日期數據中包含前一天或後一天凌晨附近的數據或者丟失當天的變更數據。 實際場景 公司主營互聯網金融業務，因此有了一張數據量龐大的申請人信息記錄表。這張表裡的時間欄位非常多，因為整個業務場景涉及到好幾段流程： 客戶提交申 ...
什麼是數據漂移？
數據漂移是 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 重傳，很好地解決了數據更新與數據漂移的問題。雖然我認為統一的放款時間做時間切分會更合理，對財務計算更更友好。
