2023年第4期
總第18期
目錄
contents
03
02
01
04
數據質量
監控
五個原則
下的數據
質量建設
之道
數據質量
那點事
阿里數據
質量管理
方法總結
數據質量那點事
1、數據質量基本概念
數據質量管理（Data Quality Management），是指對數據從計劃、獲取、存儲、共享、維護、應用、消亡生命周期的每個階段里可能引發的各類數據質量問題，進行識別、度量、監控、預警等一系列管理活動，并通過改善和提高組織的管理水平使得數據質量獲得進一步提高
數據質量管理不是一時的數據治理手段，而是循環的管理過程。其終極目標是通過可靠的數據，提升數據在使用中的價值，并最終為企業贏得經濟效益
2、影響因素
數據問題的來源可能產生于從數據源頭到數據存儲介質的各個環節。在數據采集階段，數據的真實性、準確性、完整性、時效性都會影響數據質量。除此之外，數據的加工、存儲過程都有可能涉及對原始數據的修改，從而引發數據的質量問題。所以，技術、流程、管理等多方面的因素都有可能會影響到數據質量。
在企業中，隨著企業業務的增長，數據也是一個增量積累的過程。隨著數據類型、數據來源的不斷豐富以及數據數量的快速增長，企業在數據管理工作和數據流程中面臨越來越多的數據質量問題。而且數據質量的管理并沒有被企業重視起來，其根本原因還是ROI并沒有那么明顯。
? ? ? 數據質量管理相對來說成本比較高。因為它涉及到企業數據標準的制定、規范的落地、生命周期的管理等多個環節。從收益上來說，數據質量的效益和結果并不是十分明顯，大部分企業不會把數據質量作為KPI。在企業的不同系統中，業務領域的關鍵指標不一致，數據無法共享導致出現數據孤島，大量數據無法關聯，并且有明顯的數據冗余等問題，還有數據的維護需要投入大量的人員、時間、軟硬件成本。所以數據的質量管理往往被會邊緣化甚至趨向于無。
在此附上數據的生命周期圖，包括各環節的數據流轉和數據處理。
- 完整性
數據完整性問題包含數據條目不完整，數據屬性不完整等
- 一致性
多源數據的數據模型不一致，如命名不一致，數據編碼不一致，含義不一致，生命周期不一致等
- 準確性
準確性也叫可靠性，不可靠的數據可能會導致嚴重的問題，會造成有缺陷的方法和糟糕的決策
- 唯一性
用于識別和度量重復數據，冗余數據，重復數據是導致業務無法協同， 流程無法追溯的重要因素，也是數據治理需要解 決的最基本的數據問題
- 關聯性
數據關聯性問題是指存在數據關聯的數據關系缺失或錯誤，例如：函數關系、相關系數、主外鍵關系、索引關系等。存在數據關聯性問題，會直接影響數據分析的結果，進而影響管理決策。
- 真實性
? ? ? ?數據必須真實準確的反映客觀的實體存在或真實的業務，真 實可靠的 原始統 計數據是企業統計工作的靈魂，是一切管理工作的基礎，是經 營 者進行正確 經營決策必不可少的第一手 資料。
- 及時性
數據的及時性(In-time)是指能否在需要的時候獲到數據，數據的及時性與企業的數據處理速度及效率有直接的關系，是影響業務處理和管理效率的關鍵指標。
「驅動力」
文章轉自：大數據私房菜
原文鏈接：//mp.weixin.qq.com/s/Hq7XlJmigoQFMs4PCcFpgw
3、評估維度
- 邏輯檢查
不同表字段之間可能會有邏輯關聯，需要稽核
- 離群值檢查
部分數據可能會偏離其他數據，比如同一個商品金額大家都是100元，而有一條數據是1W
- 自定義規則
由需求方自定義相關規則
- 波動稽核
與上周環比稽核波動情況
- 強弱規則
每個規則的權重應該是不一樣的，需要配置優先級，這對后續的告警方 式是有幫助的
我們最終的目的是希望做到頁面可配置
4、實施流程
事前定義質量規則
- 梳理表，字段等信息
- 確定資產等級
- 制定檢驗規則
事中監控數據質量
- 在數據抽取過程中，可以對數據進行數據量稽核及唯一性，非空性稽核
- etl過程對臟數據進行清洗，保證數據質量
- 指標計算過程中，可以對指標進行波動值稽核，保證指標變化在合理范圍內
以上如果有異常都需要郵件短信報警，對應負責人根據優先級判斷是不是需要及時處理
事后分析和問題跟蹤
每周定時跑一次程序，對全局數據進行質量稽核控制，如唯一性，非空性等
對于程序跑出來的數據：
數據質量概覽在數據質量管理系統查詢
數據質量明細數據在數據質量管理系統查詢
根據異常數據統計出來的各種數據質量報表也可以在數據質量管理系統查詢，包括表覆蓋率，歷史趨勢，綜合分析，排名分析等(質量報告支持導出為word，pdf，excel)
對異常進行評估、嚴重程度、影響范圍、問題分類等
重大問題告警
- 警告：郵件短信通知
- 數據整改：問題跟蹤處理，故障review，一周內處理完成
5、總結
數據質量管理貫穿數據生命周期的全過程，覆蓋質量評估、數據監控、數據探查、數據清洗、數據診斷等方面。數據源在不斷增多，數據量在不斷加大，新需求推動的新技術也不斷誕生，這些都對大數據下的數據質量管理帶來了困難和挑戰。因此，數據質量管理要形成完善的體系，建立持續改進的流程和良性機制，持續監控各系統數據質量波動情況及數據質量規則分析，適時升級數據質量監控的手段和方法，確保持續掌握系統數據質量狀況，最終達到數據質量的平穩狀態，為業務系統提供良好的數據保障。?
「驅動力」
五個原則下的
數據質量建設之道
文章轉自： EAWorld
原文鏈接：//mp.weixin.qq.com/s/JCPiiEkt7PBv5pftvE5RHQ
1.業務操作部門在數據錄入過程可能輸入錯誤的數據。這決定了數據源的質量。
2.在數據抽取、加載工程中導致數據記錄丟失、數據重復等問題。
3.在數據加工、轉換過程中，由于數據加工、轉換的代碼魯棒性和穩定性不夠，導致的數據加工結果出現的錯誤。
4.數據計算匯總過程中，導致的數據的錯誤。
5.分析展現工具將加工好的數據展現給數據分析人員、管理決策人員出現的錯誤。
在某種意義上講，分析者所做出的決策的正確性來源于企業信息源的質量、數據倉庫本身的質量、數據集市的質量以及數據倉庫各過程的質量。在數據應用過程中5步中有4步是技術或管理造成的，只有1步會是錄入環節導致。而恰好是這一步是數據中臺無法管理和解決的業務系統的數據。因此從根本上解決數據質量問題，從源頭解決是最有效的途徑，在輔助數據中臺從技術和管理上加強測試、規范和監控，那么數據質量問題的解決就水到渠成了。
【3、數據質量建設的五個原則】
總結古人治理黃河水患，主要有兩種策略，一種是“疏通”，上策遷移民眾和中策分流黃河水患，都是具體體現；另一種是“圍堵”，加高增厚堤防，抑制河水爛漫。
治理數據質量的問題可以應用下古人的智慧和考量。采用規劃頂層設計，制定統一數據架構、數據標準，設計數據質量的管理機制，建立相應的組織架構和管理制度，采用分類處理的方式持續提升數據質量，這是數據質量管理“疏”的方式。而單純依賴技術手段，通過增加ETL數據清洗處理邏輯的復雜度，使用數據質量工具來發現ETL數據處理中的問題屬于“堵”的方式，只能解決表面的問題，不是根本的解決方法。事實上這種方式也在好多企業中使用，其根本目的在于提高ETL處理的準確度，做法無可厚非，畢竟找別人的問題之前，先要保證自身是沒有問題的。
按照多個行業實施數據質量管理項目的經驗，數據質量管理應該是采用“疏”和“堵”相結合的方式，通過這種方式解決數據質量問題有5個原則。
1、全程監控原則：
全程監控是針對數據生命周期全過程中各環節進行數據質量監控，從數據的定義、錄入、獲取、計算、使用的全過程進行質量監控。數據定義階段，對數據模型、字典枚舉值進行監控，判斷是否遵循了統一的標準。數據錄入階段對輸入的合法性進行校驗等，數據獲取階段對數據記錄數、數據一致性進行檢核等。明確各部門在數據全生命周期中的責任，全方位保證數據質量。
2、閉環管理原則：
從問題定義、問題發現、問題整改、問題跟蹤、效果評估5個方面建立問題處理的閉環機制。從業務、技術兩個維度出發做問題定義，由工具自動發現問題，明確問題責任人，通過郵件、短信等方式進行通知，將問題及時通知到責任人，跟蹤問題整改進度，建立相應的質量問題評估KPI，保證數據質量問題管理閉環。
「驅動力」
在數字化轉型的背景下，數據是一把雙刃劍，它能給企業帶來業務價值的同時也是組織最大的風險來源。糟糕的數據質量常常意味著糟糕的業務決策，將直接導致數據統計分析不準確、監管業務難、高層領導難以決策等問題。
「目錄」
【1、數據質量問題產生來源】01 數據質量問題產生來源02 數據質量問題域及分類03 數據質量建設的五個原則04 數據質量關鍵技術及流程05 數據質量管理實踐
數據集成融合就和古人筑堤壩一樣，古人筑堤壩是為約束河水，讓自然資源為我所用，發揮自然資源的價值；今人做數據集成融合，建數據中臺，是為了挖掘數據價值，發揮數據資源的價值，讓數據資源為企業的業務創新發揮價值。
大數據時代數據集成融合的需求不僅要融合企業內部數據，也要融合外部（互聯網等）數據。如果沒有對數據質量問題建立相應的管理策略和技術工具，那么數據質量問題的危害會更加嚴重。據IBM統計，數據分析員每天有30%的時間浪費在了辨別數據是否是“壞數據”上。
【2、數據質量問題域及分類】
數據質量問題從大的方面可以劃分為技術、業務和管理問題域。技術問題域包括數據校驗不夠、默認值使用不當等問題，通常是由于系統建設和數據處理導致的。業務問題域細分為信息問題域和流程問題域，業務上存在多渠道數據創建、不合理的數據變更流程的問題。管理問題域包括數據責任人不明確、沒有獎懲制度，缺少培訓等。
企業數據分為創建、加載、匯總、分析到展現5個步驟，很顯然，步任何一步出錯都會導致整個結論分析失真：
3、全員參與原則：
數據質量提升涉及到組織多個部門，包括不僅限于數據提供方、數據消費方、數據質量管理員等。尤其在數據質量問題定義和整改階段需要多方人員的參與才能達到效果。在數據質量問題定義階段，需要數據責任人、業務專家、數據使用人員對數據問題校驗規則達成一致，共同制定數據檢核范圍、數據問題條件等。問題整改階段，要由數據責任方、數據質量管理員和技術人員，共同定位問題原因并進行整改。
4、借助工具，自動檢核：
數據質量工具保證問題發現的效率。在數據使用過程中深入分析已發現的數據質量問題的成因，及時由IT部門將其轉化為技術規則落地到系統中，通過技術手段自動檢核數據質量問題，提升數據質量檢核效率。數據質量工具在采集到的數據模型元數據的基礎上，通過配置自動生成檢核規則的腳本，并通過設置數據質量檢核任務的運行周期，定時檢核數據質量問題，并將數據質量問題數據保存到系統中，便于用戶進行查看和定位問題。
5、提升意識、主動管理：
數據質量管理工作需要提升全員數據質量意識，形成組織數據治理的文化氛圍。數據使用方發現數據質量問題后，及時主動的進行問題的上報，避免數據問題對業務造成影響。數據責任人接到問題通知后，應主動配合數據管理部門進行問題整改。數據管理部門應該從事前預防數據問題出發，制定企業數據標準并加強宣貫，減少因為缺少統一的標準、規范導致數據質量問題。
【4、數據質量關鍵技術及流程】
在“五個原則”的指導下開展數據質量建設工作，從平臺層面需要制定數據質量管理的功能架構。
基于全棧式信創能力，普元數據質量平臺包括了規則定義、任務管理、調度執行、生成檢核結果、形成質量分析報告、問題處理、沉淀知識庫、質量監控，涵蓋了數據質量問題的發現、整改、反饋的整個流程。
「驅動力」
通過對不同業務規則的收集、分類和抽象，我們定義了這幾個質量維度：完整性、有效性、正確性、唯一性、及時性、合理性。
基于以上幾個質量維度，總結了業務場景中常用的檢核規則，提供模版式的檢核規則配置方式，便于使用者快速配置。這些檢核規則包括：空值檢查、值域檢查、有效性檢查、規范檢查、及時性檢查、重復數據檢查、完整性檢查，當然，我們也保留了原先的自定義SQL的配置方式。
新的數據質量平臺中，提供了業務化的檢核規則配置方式，提供了常用的檢核類型，滿足實際場景使用需要。
業務化的檢核規則配置步驟有：基本信息、規則配置、結果配置、告警配置。其中，規則配置根據檢核規則類型不同，具體的配置會有所不同。
那么，如何從技術實現和管理流程方面，保障企業數據質量的穩步提升？
檢核腳本生成和調度執行
檢核規則采用業務化配置和模版導入方式輸入檢核規則，通過系統內置SQL引擎，實現檢核腳本的自動生成，從而降低業務規則轉化為技術實現的成本，提高業務規則的實現效率。
數據質量平臺的調度模塊則按照檢核任務的執行頻度設置，周期性或定時執行檢核任務。
規范管理流程
在數據使用過程中，深入分析已發現的數據質量問題的成因，及時由IT部門將其轉化為技術規則落地到平臺中，通過技術手段自動檢核數據質量問題，提升數據質量檢核效率。
數據質量平臺在采集到的數據模型元數據的基礎上，通過配置自動生成檢核規則的腳本，并通過設置數據質量檢核任務的運行周期，定時檢核數據質量問題，并將數據質量問題數據保存到平臺中，便于用戶進行查看和定位問題。
同時，根據數據的檢核結果，平臺自動形成檢核指標、檢核規則的分析結果，生成質量趨勢的分析報告。
由此，形成從問題定義、發現、分析，到問題的處理和跟蹤，再到數據質量評估和統計分析的管理流程。
「驅動力」
【5 數據質量管理實踐】
為實現數據質量的切實落地，推進數據質量問題的有效解決，某一線城市大數據中心的數據質量工作開展，按照發現問題、分析問題、提出方案、解決問題等幾步來進行。
- 第一步：設置數據質量規則。即針對不同的數據對象，配置相應的數據質量指標，不限于：數據唯一性、數據準確性、數據完整性、數據一致性、數據關聯性、數據及時性等。
- 第二步：分析數據質量問題產生的原因。可能是技術層面數據模型設計的質量問題，也可能是業務層面系統相互獨立導致數據無法對接或者是業務端進行數據錄入時未按照規范進行錄入。
- 第三步：選擇解決辦法。技術上可以通過ETL工具按照數據標準規范進行數據清洗和標準；業務上可以對業務系統進行升級改造和數據補錄。
- 第四步：質量檢測，監督檢查。設置數據檢查任務對存量數據進行檢查，形成數據質量問題清單并出具數據質量問題報告。通過定期對系統開展全面的數據質量狀況評估，從問題率、解決率、解決時效等方面建立評價指標進行整改評估，根據整改優化結果。
形成有效的閉環管理
在形成規范流程的基礎上，從業務、技術兩個維度出發做問題定義，由工具自動發現問題，明確問題責任人，通過郵件等方式進行通知，將問題及時通知到責任人，跟蹤問題整改進度，建立相應的質量問題評估KPI，保證數據質量問題管理閉環。
通過建立數據質量閉環管理機制、明確各部門關于數據質量提升工作的分工職責并強化執行；同時基于數據管理工具，持續改進管理流程，支撐企業級數據質量管理，確保企業級數據質量穩步提升。
數據質量監控
隨著大數據時代的帶來，數據的應用也日趨繁茂，越來越多的應用和服務都基于數據而建立，數據的重要性不言而喻。而且，數據質量是數據分析和數據挖掘結論有效性和準確性的基礎，也是這一切的數據驅動決策的前提！如何保障數據質量，確保數據可用性是每一位數據人都不可忽略的重要環節。
數據質量，主要從四個方面進行評估，即完整性、準確性、一致性和及時性，本文將會結合業務流程和數據處理流程，對這個四個方面進行詳細的分析和講解。
數據，最終是要服務于業務價值的，因此，本文不會單純講解理論，而是會從數據質量監控這一數據的應用為出發點，為大家分享居士對數據質量的思考。通過本文，你將獲得如下幾方面的知識點：
- 數據質量核心關注的要點
- 從數據計算鏈條理解，每一個環節會出現哪些數據質量問題
- 從業務邏輯理解，數據質量監控能帶來的幫助
- 實現數據質量監控系統時要關注的點
- 數據質量監控面臨的一些難點和解決思路
四大關注點
本節，先簡單地聊一下數據質量需要關注的四個點：即完整性、準確性、一致性和及時性。這四個關注點，會在我們的數據處理流程的各個環節有所體現。
一、完整性
完整性是指數據的記錄和信息是否完整，是否存在缺失的情況。數據的缺失主要包括記錄的缺失和記錄中某個字段信息的缺失，兩者都會造成統計結果不準確，所以說完整性是數據質量最基礎的保障。
簡單來講，如果要做監控，需要考慮兩個方面：一是，數據條數是否少了，二是，某些字段的取值是否缺失。完整性的監控，多出現在日志級別的監控上，一般會在數據接入的時候來做數據完整性校驗。
二、準確性
準確性是指數據中記錄的信息和數據是否準確，是否存在異常或者錯誤的信息。
直觀來講就是看數據是否上準確的。一般準確性的監控多集中在對業務結果數據的監控，比如每日的活躍、收入等數據是否正常。
三、一致性
一致性是指同一指標在不同地方的結果是否一致。
數據不一致的情況，多出現在數據系統達到一定的復雜度后，同一指標會在多處進行計算，由于計算口徑或者開發人員的不同，容易造成同一指標出現的不同的結果。
四、及時性
在確保數據的完整性、準確性和一致性后，接下來就要保障數據能夠及時產出，這樣才能體現數據的價值。
及時性很容易理解，主要就是數據計算出來的速度是否夠快，這點在數據質量監控中可以體現在監控結果數據數據是否在指定時間點前計算完成。
0x02 數據處理各環節的數據質量
數據質量監控之所以難做，是因為在數據的各個環節都會出現數據質量的問題。因此，本節將以一個典型的數據處理鏈條為例，為大家分享在每個階段容易出現哪些數據質量問題。
如下圖，為了舉例說明，我畫了一個簡單的數據處理流程（在實際中的情況會比該情況復雜很多），我將數據處理分為 3 個階段：數據接入、中間數據清洗、結果數據計算。
「驅動力」
文章轉自：CSDN，作者木東居士
原文鏈接：//blog.csdn.net/wowotuo/article/details/89424624
數據接入
如上圖所示，數據接入環節最容易出現的是數據完整性的問題，這里要特別注意的是數據量是否陡增和陡降。
陡增意味著可能會出現大量數據重復上報或者異常數據侵入等情況，陡降意味著可能出現數據丟失的情況。
另一方面，也要檢查不同字段的的取值是否有丟失，比如地址和設備字段是否出現大量空值等異常。
數據清洗
在這里，我將數據清洗的范圍局限在數據倉庫的中間表清洗上，這一部分一般也是我們的數據倉庫要建設的核心部分，業務到了一定程度，數據中間層的建設必不可少！
在這一環節，最容易出現的是數據一致性和數據準確性的問題。數據中間層保障來數據是從統一出口而出，讓數據一起對或者一起錯。但是很難保證數據準確性的問題，因此在數據清洗階段需要盡量保障數據的準確性。
數據結果
結果數據，主要是強調對外提供數據的過程，一般是從中間表中計算或直接取得的可展示數據。這里是業務方和老板最容易感知的到的地方，因此在這環節，主要關注的是數據準確性和數據及時性。
整體來講，數據的完整性、準確性、一致性和及時性在數據處理的各個階段都需要關注，但是可以先抓住的核心的問題來解決。
業務流程各環節的數據質量
聊完數據處理，我們繼續聊一下業務流程。數據最終的價值是要服務于業務的，因此數據質量最好也是能從解決業務問題出發，因此，本節從典型的業務場景來講解數據質量該怎么做。
首先，居士認為，既然做監控肯定是要考慮使用方的，而我們的數據質量監控平臺一個很重要的作用是希望讓老板、產品和運營這些使用方對我們的數據放心，那么他們的關注點是什么？居士認為，是業務指標！
那么，這個業務指標可以從兩個角度來考慮：
- 單個指標的數值異常，比如說數據是否達到來某個臨界值？是否有陡增和陡降？
- 整個業務鏈條的數據是否有異常，比如從曝光到注冊的轉化是否有異常？
如下圖，是一個 App 的用戶行為漏斗分析，其實也就是從獲取用戶到轉化的簡單鏈路。
那么針對該鏈路，我們數據質量監控要做的事，除了告訴使用方某一個節點的值有問題，也需要告訴他們整個鏈條哪里出了問題，哪里的轉化低了。
「驅動力」
如何實現數據質量監控
前面分享了數據質量關注的點，以及從技術和業務角度會如何關注數據質量，本節將簡單地分享一下如何實現數據質量監控。這里將分兩個角度：宏觀的設計思路和技術實現思路。
一、設計思路
數據質量監控的設計要分為四個模塊：數據、規則、告警和反饋。
- 數據：主要是需要被數據質量監控到的數據，數據可能存放在不同的存儲引擎中，比如Hive、PG、ES等。
- 規則：是指如何設計發現異常的規則，一般而言主要是數值的異常和環比等異常監控方式。也會有一些通過算法來發掘異常數據的方法。
- 告警：告警是指出發告警的動作，這里可以通過微信消息、電話、短信或者是微信小程序的方式來觸發告警內容。
- 反饋：這里需要特別注意，反饋是指對告警內容的反饋，比如說收到的告警的內容，那么負責人要來回應這個告警消息是否是真的異常，是否需要忽略該異常，是否已經處理了該異常。有了反饋的機制，整個數據質量監控才容易形成閉環。更能體現業務價值。
二、技術方案
關于技術方案，這里不多描述細節，因為不同的公司和團隊情況對實現方案的考慮是不同的，簡單做的話，可以寫一些定時腳本即可，復雜的話可以做成一個分布式的系統。這里也可以參考居士17年寫的一部分內容No.22 漫談數據質量監控。
本篇只簡單說明幾個技術實現中需要關注的點：
- 最開始可以先關注核心要監控的內容，比如說準確性，那么就對核心的一些指標做監控即可，不用開始就做很大的系統。
- 監控平臺盡量不要做太復雜的規則邏輯，盡量只對結果數據進行監控。比如要監控日志量是否波動過大，那么把該計算流程前置，先計算好結果表，最后監控平臺只監控結果表是否異常即可。
- 多數據源，多數據源的監控有兩種方式可以處理：針對每個數據源定制實現一部分計算邏輯，也可以通過額外的任務將多數據源中的數據結果通過任務寫入一個數據源中，再該數據源進行監控，這樣可以減少數據監控平臺的開發邏輯。具體的優缺點可以自行衡量。
- 實時數據的監控，實時和離線數據監控的主要區別在于掃描周期的不同，因此在設計的時候可以先以離線數據為主，但是盡量預留好實時監控的設計。
- 在設計之初，盡量預留好算法監控的設計，這是一個很大的加分項，具體的結合方式也可以和第二點建議接近，比如算法異常數據放到一張結果表中，再在上面配置簡單的告警規則即可。
一些困難
在做數據質量監控的時候難免會遇到一些困難點，亦或是被老板挑戰的地方，下面列舉幾個問題和解決的思路，供大家參考：
問題一：假設你的結果表要經過多層的中間表計算，你怎么保證每個環節都是正確的，且最終結果是正確的？
思路：從兩個點考慮：
- 每一層代碼有 Code Review，保證代碼邏輯正常。
- 單獨一條計算流，對關鍵指標從原始數據直接計算結果，和日常的結果表做對比，發現不同則告警。這種方式也可以理解為是結果數據和源數據的對賬。
問題二：告警信息太多了，太容易被忽略怎么辦？
思路：主要是思路是提高告警的準確率，避免無用的告警，有三個思路：
- 多使用機器學習算法的方式來發現異常點，比如：異常森林。
- 加入反饋機制，如果業務負責人認為該告警是正常的，就打上正常的tag，后續告警規則根據反饋進行優化。
- 加入屏蔽功能，屏蔽不感興趣的告警。
「驅動力」
…… …… …… …… …… …… ……
阿里數據質量管理方法總結
一、數據質量保障原則
如何評估數據質量的好壞，業界有不同的標準，阿里主要從4個方面進行評估：完整性、準確性、一致性、及時性；
1.完整性
數據完整性是數據最基礎的保障；
- 完整性：指數據的記錄和信息是否完整，是否存在缺失的情況；
- 數據缺失：主要包括記錄的缺失和記錄中某個字段信息的缺失；
記錄的丟失：如，交易中每天只發訂單數都在 100 萬筆左右，如果某天支付訂單突然下降到 1 萬筆，很可能是記錄丟失了；
記錄中字段的丟失：如，訂單的商品 ID、賣家 ID 都是必然存在的，這些字段的空值個數肯定是 0，一旦大于 0 就違背了完整性約束；
2. 準確性
- 準確性：指數據匯總記錄的信息和數據是否準確，是否存在異常或者錯誤的信息；
準確：數據表中記錄的信息與業務過程中真實發生的事實要一致；如何判斷是否準確：卡點監控 —— 制定相應規則，根據根校驗數據，符合規則的數據則認為是準確的；
如，一筆訂單如果出現確認收貨金額為負值，或者下單時間在公司成立之前，或者訂單沒有買家信息等，這些必然是有問題的；
3. 一致性
- 一致性：一般體現在跨度很大的數據倉庫體系中，如阿里的數據倉庫，內部有很多業務數據倉庫分支，對于同一份數據，必須保證一致性；
一致：也就是指多個業務數據倉庫間的公共數據，必須在各個數據倉庫中保持一致；
如，用戶 ID，從在線業務庫加工到數據倉庫，再到各個消費節點，必須都是同一種類型，長度也需要保持一致；
- 所以，在阿里建設數據倉庫時，才有了公共層的加工，以確保數據的一致性；
4. 及時性
- 及時性：指數據要能及時產出；
主要體現在數據應用上，要及時產出給到需求方；
- 一般決策支持分析師希望當天就能看到前一天的數據，而不是等三五天才能看到某一個數據分析結果；否則就已失去了數據及時性的價值；
如，阿里 “雙 11” 的交易大屏數據，就要做到秒級；
二、數據質量方法概述
阿里的數據質量建設體系：
「驅動力」
文章轉自：大數據夢想家，作者夢想家Alex
原文鏈接：//mp.weixin.qq.com/s/yQFDMYZJXeUBUjmbM4S3tQ
…… …… …… …… …… …… ……
1. 消費場景知曉
- 功能：分析解決消費場景知曉的問題；
- 方法：通過數據資產等級和基于元數據的應用鏈路，來分析解決消費場景知曉的問題；確定數據資產等級：根據應用的影響程度，確定數據資產的等級；
- 過程：根據數據鏈路血緣，將資產等級上推至各數據生產加工的各個環節，確定鏈路上所有涉及數據的資產等級，以及在各個加工環節上根據資產等級的不同所采取不同的處理方式；
2. 數據生產加工各個環節卡點校驗
主要對兩部分的數據卡點校驗：在線系統和離線系統數據生產加工各個環節的卡點校驗；
- 在線系統：OLTP（On - Line Transaction Processing，聯機事務處理）系統；
在線系統生產加工各環節卡點校驗：
1）根據資產等級的不同，當對應的業務系統變更時，決定是否將變更通知下游；
2）對于高資產等級的業務，當出現新業務數據時，是否納入統計中，需要卡掉審批；
- 離線系統：OLAP（On - Line Analytical Processing，聯機分析處理）系統；
離線系統生產加工各環節卡點校驗：
主要包括：代碼開發、測試、發布、歷史或錯誤數據回刷等環節的卡點校驗；代碼開發階段、發布前的測試階段
針對數據資產等級的不同，對校驗的要求有所不同；
3. 風險點監控
風險點監控：主要針對在數據運行過程中可能出現的數據質量和時效等問題進行監控；
主要對兩個方面進行風險點監控：
- 在線數據的風險點監控：
主要針對在線系統日常運行產出的數據進行業務規則的校驗；
主要使用 “實時業務檢測平臺 BCP（Biz Check Platform）”；
- 離線數據的風險點監控：
主要是針對離線系統日常運行產出的數據，進行數據質量監控和時效性監控；
DQC：監控數據質量；
摩薩德：監控數據時效性；
4. 質量衡量
- 對質量的衡量：
事前的衡量：如 DQC 覆蓋率；事后的衡量：跟進質量問題，確定質量問題原因、責任人、解決情況等，并用于數據質量的復盤，避免類似事件再次發生；根據質量問題對不同等級資產的影響程度，確定其是屬于低影響的事件還是具有較大影響的故障；
- 質量分：綜合事前和事后的衡量數據進行打分；
5. 質量配套工具
- 針對數據質量的各個方面，都有相關的工具進行保證，以提高效能；
01 消費場景知曉
- 消費場景知曉的問題：
數據研發工程師難以確認幾百 PB 的數據是否都是重要的？是否都要進行保障？是否有一些數據已經過期了？是否所有需要都要精確的進行質量保障？
- 解決方案：數據資產等級方案；
- 產出：
根據數據產品和應用的影響程度，給數據產品和應用劃分資產等級，并打標處理；
根據數據鏈路血緣，將資產等級上推至各數據生產加工的各個環節，確定鏈路上所有涉及數據的資產等級，打標處理；（等級標簽與對應的數據產品 / 應用一致）
1. 數據資產等級定義
背景：針對阿里龐大的數據倉庫，數據的規模已經達到 EB 級，對于這么大的數據量，如果一概而論勢必會造成精力無法集中、保障無法精確；
五個數據等級，不同性質的重要性一次降低：
「驅動力」
…… …… …… …… …… …… ……
- 毀滅性質
即，數據一旦出錯，將會引起重大資產損失，面臨重大受益損失，造成重大公共風險；
- 全局性質
即，數據直接或間接用于集團業務和效果的評估、重要平臺的運維、對外數據產品的透露、影響用戶在阿里系網站的行為等；
- 局部性質
即，數據直接或間接用于內部一般數據產品或者運營 / 產品報告，如果出現問題會給事業部或業務線造成影響，或者造成工作效率損失；
- 一般性質
即，數據主要用于小二的日常數據分析，出現問題幾乎不會帶來影響或者影響很小；
- 未知性質
即，數據主要用于小二的日常數據分析，出現問題幾乎不會帶來影響或者影響很小；
- 未知性質
不能明確說出數據的應用場景，則標注為未知；
對于不同的數據資產等級，使用英文 Asset 進行標記：
毀滅性質：A1 等級；
全局性質：A2 等級；
局部性質：A3 等級；
一般性質：A4 等級；
未知性質：A5 等級；
重要程度：A1 > A2 > A3 > A4 > A5；
如果一份數據出現在多個應用場景中，遵循就高原則；
數據資產等級落地方法
需要解決的問題：對于如此龐大的數據量，如何給每一份數據都打上一個等級標簽？
數據資產等級落地的方法 / 步驟：
數據流轉過程
- 數據從業務系統中產生，經過同步工具進入數據倉庫系統中，在數據倉庫中進行一般意義上的清洗、加工、整合、算法、模型等一系列運算；
- 通過同步工具輸出到數據產品中進行消費；
數據從業務系統到數據倉庫再到數據產品，都是以表的形式體現的，流轉過程如下圖：
「驅動力」
同步到數據倉庫（對應到阿里就是 MaxCompute 平臺）中的都是業務數據庫的原始表，主要用于承載業務需求，往往不能直接用于數據產品；（一般是 ODS 層的全量數據）
在數據產品中使用的都是經過數據倉庫加工后的產出表；（根據需求 / 報表進行加工）
劃分數據資產等級
根據數據流轉過程，建立元數據，記錄數據表與數據產品或者應用的對應關系；
根據影響程度，給數據產品和應用劃分數據資產等級；
打標：依托元數據的上下游血緣，將整個消費鏈路打上某一類數據資產標簽（也就是對消費鏈路數據打標）；
鏈路：指數據從業務系統到數據產品的流轉過程；
總結：
通過上述步驟，就完成了數據資產等級的確認，給不同的數據定義了不同的重要程度，需要用到元數據的支撐；
02 數據加工過程卡點校驗
目的：保障數據準確性、保障與離線數據的一致性；
1）在線業務系統卡點校驗（數據產出環節）
- 在線系統數據加工過程卡點校驗，主要指在在線系統的數據生產過程中進行的卡點校驗；
- 目的：保障與離線數據的一致性；
- 背景 / 問題：在線業務復雜多變，總是在不斷變更，每一次變更都會帶來數據的變化，因此需要做到兩點：
- 數據倉庫需要適應著多變的業務發展，及時做到數據的準確性；
…… …… …… …… …… …… ……
- 需要高效的將在線業務的變更通知到離線數據倉庫；阿里解決上述兩個問題的方法：工具和人工雙管齊下：既要在工具上自動捕捉每一次業務的變化，同時也要求開發人員在意識上自動進行業務變更通知；
2）工具
發布平臺：發送重大變更的通知；
通知內容：變更原因、變更邏輯、變更測試報告、變更時間等；
數據庫平臺：發送庫表變更通知；
通知內容：變更原因、變更邏輯、變更測試報告、變更時間等；
3）發布內容
功能：在業務進行重大變更時，訂閱發布過程，然后給到離線開發人員，使其知曉此次變更的內容；
注：業務系統繁忙，日常發布變更數不勝數，并不是每一次業務變更都只會是離線業務，那樣會造成不必要的浪費，而且影響在線業務迭代的效率；
訂閱內容：針對全集團重要的高等級數據資產，整理出哪些變化會影響數據的加工，則訂閱這些內容；
如，財報，這個自然是 A1 等級的資產，如果業務系統的改造會影響財報的計算，如約定好的計算口徑被業務系統發布變更修改了，那么務必要告知離線業務，作為離線開發人員也必須主動關注這類發布變更信息；
卡點：發布平臺集成了通知功能，針對重要的場景發布會進行卡點，確認通知后才能完成發布；
4）數據庫表的變化感知
無論是隨著業務發展而做的數據庫擴容還是表的 DDL 變化，都需要通知到離線開發人員；
DDL（(Data Definition Language）：數據庫模式定義語言；用于描述數據庫中要存儲的現實世界實體的語言。
DDL 數據庫模式定義語言是 SQL 語言（結構化查詢語言）的組成部分；
例：CREATE DATABASE（創建數據庫）、CREATE TABLE（創建表）；
DML（Data Manipulation Language）：數據操縱語言命令；使用戶能夠查詢數據庫以及操作已有數據庫中的數據。
例：insert、delete、update、select 等都是 DML ；
「驅動力」
背景 / 問題：數據倉庫在進行數據抽取時，采用的是 DataX 工具，可能限制了某個數據庫表，如果發生數據庫擴容或者遷移，DataX 工具是感知不到的，結果可能會導致數據抽取錯漏，影響一系列的下游應用；
解決方法：通過數據庫平臺發送庫表變更通知；
5）開發人員
數據資產等級的上下游打通，同樣也要將這個過程給到在線開發人員，使其知曉哪些是重要的核心數據資產，哪些暫時還只是作為內部分析數據使用；
要提高在線開發人員的意識，通過培訓，將離線數據的訴求、離線數據的加工過程、數據產品的應用方式，告訴在線業務開發人員，使其意識到數據的重要性，了解數據的價值，同時也告知出錯后果，使在線開發人員在完成業務目標時，也要注重數據的目標，做到業務端和數據端一致；
6）離線系統卡點校驗（數據離線加工環節）
背景 / 問題：數據從在線業務系統到數據倉庫再到數據產品的過程中，需要在數據倉庫這一層完成數據的清洗、加工；正是有了數據的加工，才有了數據倉庫模型和數據倉庫代碼的建設；如何保障數據加工過程中的質量，是離線數據倉庫保障數據質量的一個重要環節；
目的：保障數據加工過程中的質量（主要指數據的準確性）；
另外，需要在兩個環節進行卡點校驗：
7）代碼提交時的卡點校驗
背景 / 原因：數據研發人員素質不同，代碼能力也有差異，代碼質量難以得到高效保障；
解決方法：開發代碼掃描工具 SQLSCAN，針對每一次提交上線的代碼進行掃描，將風險點提取出來；
卡點方式：使用代碼掃描工具 SQLSCAN，掃描代碼提取風險點；
8）任務發布上線時的卡點校驗
為了保障線上數據的準確性，每一次變更都需要線下完成測試后在發布到線上環境中，線上測試通過后才算發布成功；
卡點方式：分別對任務（指變更的業務）發布上線前和上線后進行測試；
9）發布上線前的測試：主要包括 Code Review 和回歸測試；
- Code Review：是一種通過復查代碼提高代碼質量的過程；
- 回歸測試：指修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤；
…… …… …… …… …… …… ……
回歸測試的目的：
保障新邏輯的正確；保證不影響非此次變更的邏輯；
注：對于資產等級較高的任務變更發布，采用強阻塞的形式，必須通過在彼岸完成回歸測試之后才允許發布；
10）發布上線后的測試：在線上做 Dry Run 測試或者真實環境運行測試；
- Dry Run 測試：
不執行代碼，僅運行執行計劃，避免線上和線下環境不一致導致語法錯誤；
- 真實環境的運行測試：
使用真實數據進行測試；
- 節點變更或數據重刷新前的變更通知
通知內容：變更原因、變更邏輯、變更測試報告、變更時間等；
過程：
使用通知中心，將變更原因、變更邏輯、變更測試報告、變更時間等自動通知下游，下游對此次變更沒有異議后，再按照約定時間執行發布變更，將變更對下游的影響降低至最低；
03 風險點監控
風險點監控：主要指針對數據在日常運行過程中容易出現的風險進行監控，并設置報警機制；
主要包括在線數據和離線數據運行風險點監控；
目的：保障數據的準確性；
1）在線數據風險點監控
- 目的：減少了在線業務系統產生的臟數據，為數據準確性把第一道關；
另外，減少用戶錯誤信息的投訴，也減少了離線數據錯誤的回滾；
- BCP：阿里的實時業務檢測平臺；
- 思路 / 監控過程：在每一個業務系統中，當完成業務過程進行數據落庫時，BCP 訂閱一份相同的數據，根據提前設定好的業務規則，在 BCP 系統中進行邏輯校驗，當校驗不通過時，以報警的形式披露出來，給到規則訂閱人，以完成數據的校對；
- BCP 的校驗過程：
「驅動力」
獲取數據源：用戶在 BCP 平臺訂閱數據源，獲取需要校驗的數據源；
編寫規則：針對所訂閱的數據源進行規則的編寫，即校驗的邏輯；
- 規則 / 邏輯：是至關重要的，是校驗的核心，只有通過了這些規則，才認定該條記錄是對的；
如，針對 “訂單拍下時間” 進行校驗；邏輯：訂單的拍下時間肯定不會大于當天的時間，也不會小于淘寶創立的時間；
配置告警：針對不同的規則配置不同的告警形式；
注：由于 BCP 的配置和運行成本較高，主要根據數據資產等級進行監控；
- 離線數據風險點監控
離線數據風險點監控主要包括對數據準確性和數據產出的及時性進行監控；
- 數據準確性監控
數據準確性是數據質量的關鍵，因此數據準確成為數據質量的重中之重，是所有離線系統加工時的第一保障要素；
方法：通過 DQC 進行數據準確性監控；
DQC（Data Quality Center，數據質量中心）：主要關注數據質量，通過配置數據質量校驗規則，自動在數據處理任務過程中進行數據質量方面的監控；
注：監控數據質量并報警，其本身不對數據產出進行處理，需要報警接收人判斷并決定如何處理；
監控方式：通過配置數據質量檢驗規則，自動在數據處理任務過程中進行監控；
監控規則：
強規則：會阻斷任務的執行；
將任務置為失敗狀態，其下游任務將不會被執行；
弱規則：只告警而不會阻斷任務的執行；
常見的 DQC 監控規則：主鍵監控、表數據量及波動監控、重要字段的非空監控、重要枚舉字段的離散值監控、指標值波動監控、業務規則監控等；
規則配置：依賴數據資產等級確定監控規則；
DQC 檢查其實也是運行 SQL 任務，只是這個任務是嵌套在主任務中的，一旦檢查點太多自然就會影響整體的性能；因此還是依賴數據資產等級來確定規則的配置情況；
注：不同的業務會有業務規則的約束，這些規則來源于數據產品或者說消費的業務需求，有消費節點進行配置，然后上推到離線系統的起點進行監控，做到規則影響最小化；
…… …… …… …… …… …… ……
數據及時性
在確保數據準確性的基礎上，需要進一步讓數據能夠及時的提供服務；否則數據的價值將大幅度降低，甚至沒有價值；
阿里的大部分離線任務：
一般以天為時間間隔，稱為 “天任務”，對于天任務，數據產品或者數據決策報表一般都要求在每天 9:00 甚至更早的時間產出；
為了確保前一天的數據完整，天任務是從零點開始運行的，由于計算加工的任務都是在夜里運行的，而要確保每天的數據能夠按時產出，需要進行一系列的報警和優先級設置，使得重要的任務優先且正確的產出；
重要的任務：資產等級較高的業務；
任務優先級
對于 Map 任務和 Reduce 任務，調度是一個樹形結構（RelNode 樹），當配置了葉子節點（RelNode 節點）的優先級后，這個優先級會傳遞到所有上游節點，所以優先級的設置都是給到葉子節點，而葉子節點往往就是服務業務的消費節點；
設置優先級：首先確定業務的資產等級，等級高的業務所對應的消費節點自然配置高優先級，一般業務則對應低優先級，確保高等級業務準時產出；
任務報警
任務報警和優先級類似，也是通過葉子節點傳遞；
任務在運行過程中難免會出錯，因此要確保任務能夠高效、平穩地執行，需要有一個監控報警系統，對于高優先級的任務，一旦發現任務出錯或者可能出現產出延遲，就要報警給到任務和業務 Owner；
摩薩德：阿里自主開發的監控報警系統；
摩薩德
摩薩德：離線任務的監控報警系統；是數據運維不可或缺的保障工具；
根據離線任務的運行情況實時決策是否告警、何時告警、告警方式、告警給誰等；
兩個主要功能：強保障監控、自定義告警；
強保障監控
強保障監控是摩薩德的核心功能，是僅僅圍繞運維目標即業務保障而設計的，只要在業務的預警時間受到威脅，摩薩德就一定會告警出來給到相關人員；
「驅動力」
強保障監控主要包括：
監控范圍：設置強保障業務的任務及其上游所有的任務都會被監控；
監控的異常：任務出錯、任務變慢、預警業務延遲；
告警對象：默認是任務 Owner，也可以設置值班表到某一個人；
何時告警：根據業務設置的預警時間判斷何時告警；
業務延遲預警和出錯報警，都是根據 “產出預警時間“ 來判斷的；
產出預警時間：摩薩德根據當前業務上所有任務最近 7 天運行的平均時間來推算當前業務所用的大概時間，來作為產出預警時間；
告警方式：根據業務的重要緊急程度，支持電話、短信、旺旺、郵件告警；
例：生意參謀業務（預警業務延遲）
資產等級及需求：定義的資產等級是 A2，要求早上 9:00 產出數據給到上架；
設置：給生意參謀業務定義一個強保障監控，業務產出時間是 9:00，業務預警時間是 7:00；
這里的預警時間是指，一旦摩薩德監控到當前業務的產出時間超出預警時間時，就會打電話給值班人員進行預警；
如，摩薩德推測生意參謀的產出時間要到 7:30，那么電話告警就出來了，由值班人員來判斷如何加速產出；產出時間推算（預警判斷，也就是產出延遲判斷）：摩薩德是根據當前業務上所有任務最近 7 天運行的平均時間來推算的；雖然有誤判的可能性，但是總體還是非常準確的，可以接受；
- 自定義監控
自定義監控是摩薩德比較輕量級的監控功能，用戶可以根據自己的需求進行配置，主要包括：
- 出錯告警：可根據應用、業務、任務三個監控對象進行出錯告警配置，監控對象出錯即告警給到人 / Owner / 值班表；
- 完成告警：可根據應用、業務、任務三個監控對象進行完成情況告警配置，監控對象完成即告警給到人 / Owner / 值班表；
- 未完成告警：可根據應用、業務、任務三個監控對象進行未完成情況告警配置，監控對象未完成即告警給到人 / Owner / 值班表；
- 周期性告警：針對某個周期的小時任務，如果在某個時間未完成，即告警給到人 / Owner / 值班表；
- 超時告警：根據任務運行時長進行超時告警配置，任務運行超過指定時間即告警給到人 / Owner / 值班表；
…… …… …… …… …… …… ……
- 摩薩德甘特圖的服務
針對業務的運行情況，摩薩德會提供一天關鍵路徑，即完成業務的最慢任務鏈路圖；因為每個業務上游可能有成千上萬個任務，所以這條關鍵路徑對于業務鏈路優化來說非常重要；
04 質量衡量
保障數據倉庫的數據質量，有很多方案，評價這些方案的優劣，需要一套度量指標：
- 數據質量起夜率
一般數據倉庫的作業任務都是在夜晚進行，一旦出現問題就需要值班人員起夜進行處理；
起夜率：用每個月的起夜次數，作為衡量數據質量建設完善度的一個指標；
- 數據質量事件
數據質量事件：記錄每一次數據質量的問題；
針對每一個數據質量問題，都記錄一個數據質量事件：
功能：既用來衡量數據本身的質量，也用來衡量數據鏈路上下游的質量，是數據質量的一個重要度量指標；
- 用來跟進數據質量問題的處理過程；
- 用來歸納分析數據質量原因；
- 根據數據質量原因來查缺補漏，既要找到數據出現問題的原因，也要針對類似問題給出后續預防方案；
- 數據質量故障體系
對于嚴重的數據質量事件，將升級為故障；
故障：指問題造成的影響比較嚴重，已經給公司帶來資產損失或者公關風險；
背景：數據從采集到最后的消費，整個鏈路要經過幾十個系統，任何一個環節出現問題，都會影響數據的產出，因此需要一種機制，能夠將各團隊綁在一起，目標一致，形成合力，故障體系在這個背景下應運而生；
故障體系中，一旦出現故障，就會通過故障體系，要求相關團隊在第一時間跟進解決問題，消除影響；
「驅動力」
1）故障定義
首先識別出重要的業務數據，并注冊到系統中，填寫相關的業務情況，如技術負責人、業務負責人、數據應用場景、延遲或錯誤帶來的影響、是否會發生資產損失等，完成后，會將這部分數據的任務掛到平臺基線上，一旦延遲或錯誤，即自動生成故障單，形成故障；
2）故障等級
故障發生后，會根據一定的標準判斷故障等級，如故障時長、客戶投訴量、資金損失等，將故障按 P1~ P4 定級，各團隊會有故障分的概念，到年底會根據故障分情況來判斷本年度的運維效果；
3）故障處理
故障發生后，需要快速地識別故障原因，并迅速解決，消除影響；
在處理故障的過程中，會盡量將故障的處理進度通知到相關方，盡可能減少對業務的影響；
4）故障 Review
故障 Review：即分析故障的原因、處理過程的復盤、形成后續解決的 Action，并且都會以文字的形式詳細記錄，對故障的責任進行歸屬，一般會責任到人；
注：對故障責任的判定，不是為了懲罰個人，而是通過對故障的復盤形成解決方案，避免問題再次發生；
電話：1580-136-5057
郵箱：kai.zhao@yeepay.com
地址：朝外大街甲6號萬通中心D座25層
增值電信業務經營許可證：陜B2-20210327 |