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