1、背景

數據開發、數據倉庫工作和業務系統開發工作很大的一個不同是，業務系統功能開發一旦完成並通過測試，一般就可以比較穩定地長期運行，因為它的輸入是相對穩定的。但是數據倉庫開發加工的數據模型、數據指標和分析結論，卻很難保持穩定。因為輸入數據每天都在源源不斷產生，很難保證數據沒有大的波動，而輸入的不穩定，就可能會引發數據問題。另外，由於指標數量眾多，數據處理和加工分析的流程很長，中間環節出現紕漏也在所難免。當然，這裡說的數據問題，不一定是真有問題，但是出現大的波動，也總要排查一輪心裡才比較安心，才敢相信這是合理的波動。有時候數據出現問題並不一定真的存在問題，可能只是看起來有問題，實際上就是一種正常的模型抖動。數據問題排查到最後，一般有兩種原因，一種是存在bug或者流程異常，導致數據結果不對，修複相應bug，恢複數據即可；還有一種是，業務出現了問題，通過數據表現了出來。

2、常見數據問題

數據缺失

即缺少某個應該存在的數據，有以下這些情況

1、每天都在統計的指標，突然某天沒數據了。

案例：每日申請借款人數，突然有一天沒數據了。對比發現同一個業務系統的抽的數據都為空值，在經過列印數據源那塊日誌，發現採集異常，抽不到數。最後經由前端同事協助排查發現是合作方的 SDK 在一個 bug，導致我們數據上報時存在漏報的情況。

思路：1）先觀察下其他每日指標是否有問題，如果多個每日指標出現問題，那麼極有可能是數據源出了問題，優先排查數據源。2）如果其他每日指標沒有問題，極有可能就是統計程式出了問題，沒能正確計算出結果。

2、某個統計維度下，缺少了某個維度值的數據。

案例：各渠道申請借款人數，少了某個渠道的申請人數數據。經過檢查發現我們第三方的渠道某個APP 被臨時整改下架了，導致該渠道的相關指標發生變化。

思路：1）指標比對，同樣渠道的其他指標有沒有數據，如果也沒有那麼很可能是數據源出了問題（數據源列印日誌），如果有數據，那麼很可能代碼有問題，就去檢查代碼。2）如果是新做的指標，就檢查代碼邏輯。3）如果是之前做了很久的指標，最近出了問題，那麼極有可能是誰改動了相關邏輯，影響到了這個統計程式，要從最近的代碼改動入手去排查。也要考慮到數據倉庫相關的代碼邏輯改動。

3、多指標聯合的場景，缺少某個維度值的數據。

案例：各渠道的新增用戶數、日活、總用戶數的數據，缺少某個渠道的數據。

思路：極有可能是join時沒有考慮到某個渠道可能在某個指標上沒有數據，例如，缺失的渠道沒有新增用戶數，採用內連接的方式，就會導致這個渠道在最終結果里看不到。

數據偏高或偏低

數據偏高或偏低，都屬於數據表現出離群性，看上去有點不合理。（離群值(outlier)，也稱逸出值，是指在數據中有一個或幾個數值與其他數值相比差異較大。）但數據不一定真的有問題，要根據業務特點與實際場景分析，有可能就是某些突發事件，造成的業務以及數據模型抖動。例如，某天發現前一天申請借款人數下降了20%左右，一番排查後，發現前一天我們第三方的渠道某個APP被臨時整改下架，導致當天我們的申請借款人數產生了比較大的抖動，第二天就恢復正常了。

案例：之前發現公司新上線的 APP 應用，在推廣一段時間後，人均瀏覽時長逐步下降。最後增設版本維度，對比發現新版本的人均瀏覽時長明顯降的更厲害，最終確定是由於新版本不穩定，數據漏報，導致數據偏低。

思路

1、首先要排除數據源層面的問題，可以和上周、上個月的相同時間點的總體數據量做比對，也可以查看24時段分佈情況。同時排查數據收集系統和ETL程式有沒有異常日誌。

2、其次，可以採用對照比較的方法，將該數據和其他相近的數據做比較。例如，現在的問題是某個渠道的申請借款人數偏高，可以對比該渠道過來的用戶的曝光、點擊等行為的統計數據，另外還可以和相近事件(OCR識別等)的其他專題做比較。有了對照做參考，就容易確認是否存在異常。

3、再次，還有一種可能性是和版本升級有關，可以增加一個版本維度，對比各版本的數據是否存在某個版本明顯不正常的情況。

數據趨勢存在異常

指應該呈現規律性變化的數據，出現了不符合歷史規律的情況。這種問題一般很難排查。

首先要區分該數據是呈現強規律，還是弱規律。

如果是弱規律，那麼波動可能是正常的，只需要確認數據源和統計程式沒有問題就行了。

如果是強規律，則要分析數據是高了還是低了，頭腦風暴下可能的原因是什麼，然後逐個排查。一般容易出問題的點是，數據源的問題或者特殊事件的影響。

數據相互矛盾

指多個數據之間存在矛盾。常見的一種情況是，從報表系統查出來多個有關聯關係的指標，結果發現他們有矛盾。

案例：某一天發現各個渠道的人均線上時長的平均值，比總體的人均線上時長大很多。發現發現申請借款單量乘以平均申請貸款金額和申請貸款總金額差異很大。

思路：不同指標的統計口徑有差異，需要重新理清各指標讀取的數據源以及統計邏輯，找到矛盾點。

數據違背常識

指數據出現了常識性的錯誤。

案例：比如用戶的申請借款時長大於使用應用的時長，風控轉化率大於 100%等。

思路：這類問題通常都是統計邏輯的問題，應該重點排查程式的統計邏輯。也有可能是數據源存在問題，需要對數據追蹤溯源，排查是哪個環節導致了數據的丟失。

3、數據問題排查方式

在進行問題排查時，我們要抱著大膽懷疑，小心求證的態度。不要假設某個地方不會出問題。

排查數據源

在遇到數據問題時，最好首先保證數據源沒有問題。但是，並非每次都要去查一遍數據源，而是要有這方面的意識。

1、最好在數據採集和數據ETL過程中，多打一些日誌，並對程式和關鍵節點做監控，如有異常，要及時告警。這樣，每次排查問題前，可以先檢查下，是否有錯誤日誌或者告警信息。

2、有時即便沒有錯誤日誌或告警信息，也不代表數據源沒有問題，可能是數據程式中的某個bug，導致數據不正常。這時，需要首先縮小範圍，明確是數據源層面的問題後，再去排查相關的代碼邏輯。

3、也有可能是採集端版本更新引入的bug導致的，所以在排查時也要考慮到這個因素，請相關部門的同事協助排查。

多維分析

有些數據問題，排查方向一開始會覺得比較模糊，這時可以使用多維度分析的方式，使其逐步清晰。

例如，遇到日活下降的問題，數據偏低，可以對日活的時段、地域、版本、終端、渠道等維度進行分析，查看是否在某個緯度值上有明顯的降低，以進一步的去排查。舉個實際案例，之前發現公司新上線的APP應用，在推廣一段時間後，人均瀏覽時長逐步下降。我們通過上述各維度的分析，最後發現新版本的人均瀏覽時長明顯降的更厲害，所以猜測可能是版本問題，最後經由前端同事協助排查發現是合作方的SDK存在一個bug，導致我們數據上報時存在漏報的情況。

對照分析

對照分析的要點是找到一個參照系，從而確定是否有問題，以及問題的大致範圍。這種方法是要找一個相近的其他數據，來做一個對比。比如，時間上的相近（上周、上月），位置上的相近（臨近的廣告推薦位），類型上的相近（形態上相似），或者業務上的相近（相似的業務事件場景）等，有了參考之後，你更容易判斷數據的合理性。對照分析的核心要點是找到可以對比參考的內容，最好是可以找到多個可以對比的點，綜合分析，得出結論。

debug代碼邏輯

大部分的數據問題，最後查下來都是程式bug。但是，有時統計邏輯過於複雜，bug非常不好找。此時應該分段排查，可以考慮把中間結果存儲下來，或者抽取部分數據列印出來，然後分段逐個比對，不斷縮小範圍，最後定位到問題。

由近到遠由簡單到複雜

排查的過程，應該符合先考慮和異常數據關係最近的維度或指標，排查過後再考慮較遠的指標。執行排查時，也要先排查簡單的方案，再排查複雜的方案。這是因為，排查過程中，可能會發現新的疑點，幫你找到新的線索，所以要先做能儘快執行的方案。

4、數據排查的總結

排查數據問題，是數據倉庫工程師工作中很重要的一部分。而且同樣的數據問題可能會反覆出現。所以比較好的做法是，每次排查後都做總結，在一個公共頁面(WIKI)上，記錄下問題的現象、排查的過程、找到的原因、對應的解決方案。這樣不斷積累下來，後續排查問題的效率就會越來越高，並且可以讓自己以後避免再犯類似的錯誤，持續精進自己。
在進行總結時，要註意以下幾點：

1.問題描述要清晰，排查步驟要明確。描述清晰指要把問題發生的背景和現象都要寫清楚，這樣其他人才容易看明白。排查步驟要進行總結，不僅要寫最終找到問題原因的那個排查方向，而是把所有做了的，都按照順序記錄下來。下次再遇到類似問題，可能問題原因不是上次的原因，但是排查方向是可以參考的。

2.回顧排查過程，提出更好的思路。在排查完成後，要復盤下排查的過程，設計更好的排查思路，在下次遇到類似問題時，可以更快地找準排查方向。

3.要有交付意識。在記錄相關文檔時，要有交付的意識，即你寫的東西是為了讓別人能看懂，而不是寫給自己看，要從方便他人閱讀的角度去寫，尤其是有些業務背景知識或技術知識，不能預設大家都知道就不寫，應該關註的是邏輯鏈的完整性，如果缺少了某個知識，邏輯推斷會有點跳躍，就要把它也記錄下來。