一、 背景
現在數據倉庫層面的工作越來越多，開發人員也越來越多，如何保障數據准確性是一項非常重要的工作，，數據倉庫的很多應用數據直接呈現給用戶或者支撐企業分析決策的，容不得數據出現錯誤。隨着開展的業務越來越多，數據模型越來也多,我們管控的越晚就越容易出問題。盡管有數據倉庫建設規范，同樣在數據模型命名，數據邏輯開發，每個人都可能不一樣，而這些也容易導致數據模型准確性的問題。我們迫切需要制定一套數據的准確性驗證流程，讓大家都按規范流程來做，保障數據的准確性。
二、 數據指標管理
首先我們看下數據倉庫的數據流轉，要確認計算出的指標正確，就要保證數據源的准確和邏輯的准確。
所以開發前需要確認需求理解的准確性。根據“需求模板”完善所開發的需求，遇到提出的模糊定義，需要和業務人員確認指標口徑的准確性。
需求模板主要包含業務分類、指標名稱、是否新增、統計周期、指標維度、業務口徑、技術口徑、數據源表、需求提出人、需求提出日期、優先級等：
開發數據指標過程分為四部分：看、查、管、控。
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、數據時間校驗
一般我們業務系統的數據都是帶有時間戳的，這個時間戳肯定比當前的時間要小。但是由於采集數據設備異常（業務系統異常），我們會碰到“未來時間”的數據，那如果我們以時間作為分區，后期可能就會出現異常的分析結果。當然，如果你的公司業務是跨國的，你需要考慮時差因素。
