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

標籤：大數據

上一篇：SQL性能分析

下一篇：基于datax抽取mysql資料到HDFS