一、 背景
現在資料倉儲層面的工作越來越多，開發人員也越來越多，如何保障資料準確性是一項非常重要的工作，，資料倉儲的很多應用資料直接呈現給使用者或者支撐企業分析決策的，容不得資料出現錯誤。隨著開展的業務越來越多，資料模型越來也多,我們管控的越晚就越容易出問題。儘管有資料倉儲建設規範，同樣在資料模型命名，資料邏輯開發，每個人都可能不一樣，而這些也容易導致資料模型準確性的問題。我們迫切需要制定一套資料的準確性驗證流程，讓大家都按規範流程來做，保障資料的準確性。
二、 資料指標管理
首先我們看下資料倉儲的資料流轉，要確認計算出的指標正確，就要保證資料來源的準確和邏輯的準確。
所以開發前需要確認需求理解的準確性。根據“需求模板”完善所開發的需求，遇到提出的模糊定義，需要和業務人員確認指標口徑的準確性。
需求模板主要包含業務分類、指標名稱、是否新增、統計週期、指標維度、業務口徑、技術口徑、資料來源表、需求提出人、需求提出日期、優先順序等：
開發資料指標過程分為四部分：看、查、管、控。
1. 看
首先我們要對開發出的指標結果資料進行檢視，是否有一些明顯的異常，比如某個資料值不在正常範圍內，如車速大於500KM/h，或者統計的總數過大，比如某城市人口1億人等。
2. 查
查，分為測試驗證和上線稽核。
測試核對方法如下：
-
總量核對，核對上下兩步的資料總條數，沒有過濾條件的話應該是一致的。
-
多維度統計，複雜的多維度指標拆分成單維度SQL統計，對每個指標分別進行核查。
-
多表關聯統計，拆分成中間表進行核對每一步驟的指標。
-
明細到指標統計，比如隨機找一臺車的明細和最後統計的指標進行核對。
-
新老統計對比，比如有些指標是遷移或者之前業務手工製作，可以開發後的新指標同老指標進行對比。
測試需要有專門的資料測試人員進行測試，輸出測試用例和測試報告。
上線稽核方法如下：
需要對上線的SQL程式碼進行稽核，主要從以下幾個方面：
-
對查詢表的where後面的條件、join關聯欄位、group by分組欄位等重點檢查邏輯，和需求理解結合稽核。
-
資料集命名、資料集欄位命名、任務名稱進行稽核，是否按照資料倉儲建設規範中的業務域、維度、原子指標、修飾型別、修飾詞、時間週期、派生指標等標準進行命名。
-
程式碼註釋稽核，每一步處理需要有註釋該步驟的作用，每個指標也要有註釋，where條件等也要新增註釋。
-
重要任務是否開啟簡訊告警，任務啟動時間等稽核。
-
任務上線的位置是否符合上線標準，比如上線的資料層級與業務層級等。
上線稽核需要稽核人員按照以上步驟進行稽核，對不合理的地方進行指正，稽核人員和開發人員共同保障程式碼質量。
3. 管
開發過程中，大家需要遵循一些流程規則，以確保指標的定義，開發的準確性。
-
需求上線時候需要在知識庫中完成所開發需求邏輯說明
-
複雜需求（比如專案指標），需要團隊至少兩人以上評審需求後開發。
-
提交上線申請的同事需要備註上需求邏輯說明。
-
稽核上線人員為“輪值”，稽核上線人員需要review開發人員的程式碼，需要和開發人員共同承擔程式碼質量
4. 控
指標開發完成後，需要對指標的波動情況進行監控，發現波動較大的進行核查，指標波動範圍需要具體業務具體制定，需要業務人員協助確認。常用的資料質量監控方法如下：
1、校驗每天的記錄數
分析師遇到的最常見資料異常是其報告的輸出突然降至0。
我們通常會發現最後的罪魁禍首是當天沒有將新記錄新增到相應的表中。
一種簡單的檢查方法是確保每天一個表中的新記錄數>0。
2、NULL和0值校驗
分析師常遇到的第二個問題是NULL或0值。我們要保證每天增量資料中的NULL或0值不能超過新增資料的99%。要檢查這一點，只需將一個迴圈指令碼設定為每天用NULL或0計數一個表中的新記錄數。如果看到記錄數急劇增加，則可能存在轉換錯誤或源業務系統就存在異常。
3、每天新增的記錄數波動範圍
某一天你發現資料量出現大幅增長或下降，而規則1和2都已校驗通過。這種波動可能是正常的，比如電商行業某天的大促活動，或者社交軟體的營銷活動。但是也可能這就是異常的，是因為從源系統抽取了重複的記錄。所以針對此種情況，我們也要制定資料質量規則，檢查這些波動何時發生，並主動進行診斷。比如自動執行的一個簡單的SQL過程，每天檢查COUNT個新記錄是否在7天跟蹤平均值的誤差範圍內。閾值和誤差範圍可能因公司和產品而異，經驗值一般是加減25％。當然，你可也可以直接和前一天的資料對比，增量不超過前一天的1倍。
4、重複記錄資料校驗
不管是電商系統或者是社交系統或者是物聯網裝置上報的資料，正常情況下都不會出現兩條完全一樣的記錄（包括ID，時間，值都一樣）。筆者曾遇到一個終端上報的兩條資料完全一樣的場景，導致我在做時間分段時候，劃分不正確。所以，對資料值唯一性校驗是有必要的。
5、資料時間校驗
一般我們業務系統的資料都是帶有時間戳的，這個時間戳肯定比當前的時間要小。但是由於採集資料裝置異常（業務系統異常），我們會碰到“未來時間”的資料，那如果我們以時間作為分割槽，後期可能就會出現異常的分析結果。當然，如果你的公司業務是跨國的，你需要考慮時差因素。
