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