一、資料質量保障原則
如何評估資料質量的好壞，業界有不同的標準，阿里主要從 4 個方面進行評估：完整性、準確性、一致性、及時性；
 
1、完整性
資料完整性是資料最基礎的保障；
完整性：指資料的記錄和資訊是否完整，是否存在缺失的情況；
資料缺失：主要包括記錄的缺失和記錄中某個欄位資訊的缺失；
記錄的丟失：如，交易中每天只發訂單數都在 100 萬筆左右，如果某天支付訂單突然下降到 1 萬筆，很可能是記錄丟失了；
記錄中欄位的丟失：如，訂單的商品 ID、賣家 ID 都是必然存在的，這些欄位的空值個數肯定是 0，一旦大於 0 就違背了完整性約束；
 
2、準確性
準確性：指資料彙總記錄的資訊和資料是否準確，是否存在異常或者錯誤的資訊；
準確：資料表中記錄的資訊與業務過程中真實發生的事實要一致；
如何判斷是否準確：卡點監控 —— 制定相應規則，根據根校驗資料，符合規則的資料則認為是準確的；
如，一筆訂單如果出現確認收貨金額為負值，或者下單時間在公司成立之前，或者訂單沒有買家資訊等，這些必然是有問題的；
 
3、一致性
一致性：一般體現在跨度很大的資料倉庫體系中，如阿里的資料倉庫，內部有很多業務資料倉庫分支，對於同一份資料，必須保證一致性；
一致：也就是指多個業務資料倉庫間的公共資料，必須在各個資料倉庫中保持一致；
如，使用者 ID，從線上業務庫加工到資料倉庫，再到各個消費節點，必須都是同一種類型，長度也需要保持一致；
所以，在阿里建設資料倉庫時，才有了公共層的加工，以確保資料的一致性；
 
4、及時性
及時性：指資料要能及時產出；
主要體現在資料應用上，要及時產出給到需求方；
一般決策支援分析師希望當天就能看到前一天的資料，而不是等三五天才能看到某一個數據分析結果；否則就已失去了資料及時性的價值；
如，阿里 “雙 11” 的交易大屏資料，就要做到秒級；
 
 
二、資料質量方法概述

阿里的資料質量建設體系：

消費場景知曉

功能：分析解決消費場景知曉的問題；
方法：通過資料資產等級和基於元資料的應用鏈路，來分析解決消費場景知曉的問題；
確定資料資產等級：根據應用的影響程度，確定資料資產的等級；
過程：
根據資料鏈路血緣，將資產等級上推至各資料生產加工的各個環節，確定鏈路上所有涉及資料的資產等級，以及在各個加工環節上根據資產等級的不同所採取不同的處理方式；

資料生產加工各個環節卡點校驗

主要對兩部分的資料卡點校驗：線上系統和離線系統資料生產加工各個環節的卡點校驗；
線上系統：OLTP（On - Line Transaction Processing，聯機事務處理）系統；
線上系統生產加工各環節卡點校驗：
根據資產等級的不同，當對應的業務系統變更時，決定是否將變更通知下游；
對於高資產等級的業務，當出現新業務資料時，是否納入統計中，需要卡掉審批；
離線系統：OLAP（On - Line Analytical Processing，聯機分析處理）系統；
離線系統生產加工各環節卡點校驗：
主要包括：程式碼開發、測試、釋出、歷史或錯誤資料回刷等環節的卡點校驗；
程式碼開發階段、釋出前的測試階段
針對資料資產等級的不同，對校驗的要求有所不同；

風險點監控

風險點監控：主要針對在資料執行過程中可能出現的資料質量和時效等問題進行監控；
主要對兩個方面進行風險點監控：
線上資料的風險點監控：
主要針對線上系統日常執行產出的資料進行業務規則的校驗；
主要使用 “實時業務檢測平臺 BCP（Biz Check Platform）”；
離線資料的風險點監控：
主要是針對離線系統日常執行產出的資料，進行資料質量監控和時效性監控；
DQC：監控資料質量；
摩薩德：監控資料時效性；

質量衡量

對質量的衡量：
事前的衡量：如 DQC 覆蓋率；
事後的衡量：
跟進質量問題，確定質量問題原因、責任人、解決情況等，並用於資料質量的覆盤，避免類似事件再次發生；
根據質量問題對不同等級資產的影響程度，確定其是屬於低影響的事件還是具有較大影響的故障；
質量分：綜合事前和事後的衡量資料進行打分；

質量配套工具

針對資料質量的各個方面，都有相關的工具進行保證，以提高效能；
 
　2/1）消費場景知曉
消費場景知曉的問題：
資料研發工程師難以確認幾百 PB 的資料是否都是重要的？是否都要進行保障？是否有一些資料已經過期了？是否所有需要都要精確的進行質量保障？
解決方案：資料資產等級方案；

產出：

根據資料產品和應用的影響程度，給資料產品和應用劃分資產等級，並打標處理；
根據資料鏈路血緣，將資產等級上推至各資料生產加工的各個環節，確定鏈路上所有涉及資料的資產等級，情打標處理；（等級標籤與對應的資料產品 / 應用一致）

資料資產等級定義

背景：針對阿里龐大的資料倉庫，資料的規模已經達到 EB 級，對於這麼大的資料量，如果一概而論勢必會造成精力無法集中、保障無法精確；

五個資料等級，不同性質的重要性一次降低：

毀滅性質
即，資料一旦出錯，將會引起重大資產損失，面臨重大受益損失，造成重大公共風險；
全域性性質
即，資料直接或間接用於集團業務和效果的評估、重要平臺的運維、對外資料產品的透露、影響使用者在阿里系網站的行為等；
區域性性質
即，資料直接或間接用於內部一般資料產品或者運營 / 產品報告，如果出現問題會給事業部或業務線造成影響，或者造成工作效率損失；
一般性質
即，資料主要用於小二的日常資料分析，出現問題幾乎不會帶來影響或者影響很小；
未知性質
不能明確說出資料的應用場景，則標註為未知；

對於不同的資料資產等級，使用英文 Asset 進行標記：

毀滅性質：A1 等級；
全域性性質：A2 等級；
區域性性質：A3 等級；
一般性質：A4 等級；
未知性質：A5 等級；

重要程度：A1 > A2 > A3 > A4 > A5；

如果一份資料出現在多個應用場景中，遵循就高原則；

資料資產等級落地方法

需要解決的問題：對於如此龐大的資料量，如何給每一份資料都打上一個等級標籤？
資料資產等級落地的方法 / 步驟：

資料流轉過程

資料從業務系統中產生，經過同步工具進入資料倉庫系統中，在資料倉庫中進行一般意義上的清洗、加工、整合、演算法、模型等一系列運算；
通過同步工具輸出到資料產品中進行消費；
資料從業務系統到資料倉庫再到資料產品，都是以表的形式體現的，流轉過程如下圖：

同步到資料倉庫（對應到阿里就是 MaxCompute 平臺）中的都是業務資料庫的原始表，主要用於承載業務需求，往往不能直接用於資料產品；（一般是 ODS 層的全量資料）
在資料產品中使用的都是經過資料倉庫加工後的產出表；（根據需求 / 報表進行加工）

劃分資料資產等級

根據資料流轉過程，建立元資料，記錄資料表與資料產品或者應用的對應關係；
根據影響程度，給資料產品和應用劃分資料資產等級；
打標：依託元資料的上下游血緣，將整個消費鏈路打上某一類資料資產標籤（也就是對消費鏈路資料打標）；
鏈路：指資料從業務系統到資料產品的流轉過程；

例項介紹資料資產等級打標過程

例，以阿里 “生意參謀” 產品為例，介紹資料資產等級打標過程；
生意參謀：一款為商家提供服務的資料類產品，完全依託資料，為商家進行決策支援；
每天零點開始同步，計算前一天的資料，8:00 給到商家，提供服務；
產品的每一個頁面的每個一模組基本都是通過資料表輸出展現的，不同模組資料的重要等級決定了相關表的重要等級，決定了這個匯出表的重要等級；
如，生意參謀為 A2 等級的業務，那麼對應這個匯出表的資產等級就是 A2，所有加工這個表的上游鏈路上的所有表都將會打上 A2 資產等級的標籤；同時會標註為生意參謀產品使用；
如下圖：
生意參謀打上了 A2 的標記；
直接服務於生意參謀的表Table1、Table2、Table3 進行 A2 - 生意參謀標記；
根據血緣上溯，這 3 個表的上游都將打上 A2 的標記，一直標記到前臺業務系統，將血緣貫通；

總結：

通過上述步驟，就完成了資料資產等級的確認，給不同的資料定義了不同的重要程度，需要用到元資料的支撐；
 
　2/2）資料加工過程卡點校驗
目的：保障資料準確性、保障與離線資料的一致性；

線上業務系統卡點校驗（資料產出環節）

線上系統資料加工過程卡點校驗，主要指在線上系統的資料生產過程中進行的卡點校驗；
目的：保障與離線資料的一致性；
背景 / 問題：線上業務複雜多變，總是在不斷變更，每一次變更都會帶來資料的變化，因此需要做到兩點：
資料倉庫需要適應著多變的業務發展，及時做到資料的準確性；
需要高效的將線上業務的變更通知到離線資料倉庫；

阿里解決上述兩個問題的方法：

工具和人工雙管齊下：既要在工具上自動捕捉每一次業務的變化，同時也要求開發人員在意識上自動進行業務變更通知；

工具

釋出平臺：傳送重大變更的通知；
通知內容：變更原因、變更邏輯、變更測試報告、變更時間等；
資料庫平臺：傳送庫表變更通知；
通知內容：變更原因、變更邏輯、變更測試報告、變更時間等；

釋出平臺

功能：在業務進行重大變更時，訂閱釋出過程，然後給到離線開發人員，使其知曉此次變更的內容；
注：業務系統繁忙，日常釋出變更數不勝數，並不是每一次業務變更都要只會離線業務，那樣會造成不必要的浪費，而且影響線上業務迭代的效率；
訂閱內容：針對全集團重要的高等級資料資產，整理出哪些變化會影響資料的加工，則訂閱這些內容；
如，財報，這個自然是 A1 等級的資產，如果業務系統的改造會影響財報的計算，如約定好的計算口徑被業務系統釋出變更修改了，那麼務必要告知離線業務，作為離線開發人員也必須主動關注這類釋出變更資訊；
卡點：釋出平臺集成了通知功能，針對重要的場景釋出會進行卡點，確認通知後才能完成釋出；

資料庫表的變化感知

無論是隨著業務發展而做的資料庫擴容還是表的 DDL 變化，都需要通知到離線開發人員；

DDL（(Data Definition Language）：資料庫模式定義語言；用於描述資料庫中要儲存的現實世界實體的語言。

DDL 資料庫模式定義語言是 SQL 語言（結構化查詢語言）的組成部分；
例：CREATE DATABASE（建立資料庫）、CREATE TABLE（建立表）；

DML（Data Manipulation Language）：資料操縱語言命令；使使用者能夠查詢資料庫以及操作已有資料庫中的資料。

例： insert、delete、update、select  等都是 DML ；
背景 / 問題：資料倉庫在進行資料抽取時，採用的是 DataX 工具，可能限制了某個資料庫表，如果發生資料庫擴容或者遷移，DataX 工具是感知不到的，結果可能會導致資料抽取錯漏，影響一系列的下游應用；
解決方法：通過資料庫平臺傳送庫表變更通知；

開發人員

資料資產等級的上下游打通，同樣也要將這個過程給到線上開發人員，使其知曉哪些是重要的核心資料資產，哪些暫時還只是作為內部分析資料使用；
要提高線上開發人員的意識，通過培訓，將離線資料的訴求、離線資料的加工過程、資料產品的應用方式，告訴線上業務開發人員，使其意識到資料的重要性，瞭解資料的價值，同時也告知出錯後果，使線上開發人員在完成業務目標時，也要注重資料的目標，做到業務端和資料端一致；

離線系統卡點校驗（資料離線加工環節）

背景 / 問題：資料從線上業務系統到資料倉庫再到資料產品的過程中，需要在資料倉庫這一層完成資料的清洗、加工；正是有了資料的加工，才有了資料倉庫模型和資料倉庫程式碼的建設；如何保障資料加工過程中的質量，是離線資料倉庫保障資料質量的一個重要環節；
目的：保障資料加工過程中的質量（主要指資料的準確性）；

在兩個環節進行卡點校驗：

程式碼提交時的卡點校驗

背景 / 原因：資料研發人員素質不同，程式碼能力也有差異，程式碼質量難以得到高效保障；
解決方法：開發程式碼掃描工具 SQLSCAN，針對每一次提交上線的程式碼進行掃描，將風險點提取出來；
卡點方式：使用程式碼掃描工具 SQLSCAN，掃描程式碼提取風險點；

任務釋出上線時的卡點校驗

為了保障線上資料的準確性，每一次變更都需要線下完成測試後在釋出到線上環境中，線上測試通過後才算釋出成功；
卡點方式：分別對任務（指變更的業務）釋出上線前和上線後進行測試；
釋出上線前的測試：主要包括 Code Review 和迴歸測試；
Code Review：是一種通過複查程式碼提高程式碼質量的過程；
迴歸測試：指修改了舊程式碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤；
迴歸測試的目的：
保障新邏輯的正確；
保證不影響非此次變更的邏輯；
注：對於資產等級較高的任務變更釋出，採用強阻塞的形式，必須通過在彼岸完成迴歸測試之後才允許釋出；
釋出上線後的測試：在線上做 Dry Run 測試或者真是環境執行測試；
Dry Run 測試：
不執行程式碼，僅執行執行計劃，避免線上和線下環境不一致導致語法錯誤；
真實環境的執行測試：
使用真實資料進行測試；

節點變更或資料重重新整理前的變更通知

通知內容：變更原因、變更邏輯、變更測試報告、變更時間等；
過程：
使用通知中心，將變更原因、變更邏輯、變更測試報告、變更時間等自動通知下游，下游對此次變更沒有異議後，再按照約定時間執行釋出變更，將變更對下游的影響降低至最低；
 
　2/3）風險點監控
風險點監控：主要指標對資料在日常執行過程中容易出現的風險進行監控，並設定報警機制；
主要包括線上資料和離線資料執行風險點監控；
目的：保障資料的準確性；

線上資料風險點監控

目的：減少了線上業務系統產生的髒資料，為資料準確性把第一道關；
另外，減少使用者錯誤資訊的投訴，也減少了離線資料錯誤的回滾；
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 / 值班表；

摩薩德甘特圖的服務

針對業務的執行情況，摩薩德會提供一天關鍵路徑，即完成業務的最慢任務鏈路圖；因為每個業務上游可能有成千上萬個任務，所以這條關鍵路徑對於業務鏈路優化來說非常重要；
 
　2/4）質量衡量
保障資料倉庫的資料質量，有很多方案，評價這些方案的優劣，需要一套度量指標：

資料質量起夜率

一般資料倉庫的作業任務都是在夜晚進行，一旦出現問題就需要值班人員起夜進行處理；
起夜率：用每個月的起夜次數，作為衡量資料質量建設完善度的一個指標；

資料質量事件

資料質量事件：記錄每一次資料質量的問題；
針對每一個數據質量問題，都記錄一個數據質量事件：
功能：既用來衡量資料本身的質量，也用來衡量資料鏈路上下游的質量，是資料質量的一個重要度量指標；
用來跟進資料質量問題的處理過程；
用來歸納分析資料質量原因；
根據資料質量原因來查缺補漏，既要找到資料出現問題的原因，也要針對類似問題給出後續預防方案；

資料質量故障體系

對於嚴重的資料質量事件，將升級為故障；
故障：指問題造成的影響比較嚴重，已經給公司帶來資產損失或者公關風險；
背景：資料從採集到最後的消費，整個鏈路要經過幾十個系統，任何一個環節出現問題，都會影響資料的產出，因此需要一種機制，能夠將各團隊綁在一起，目標一致，形成合力，故障體系在這個背景下應運而生；
故障體系中，一旦出現故障，就會通過故障體系，要求相關團隊在第一時間跟進解決問題，消除影響；
故障定義
首先識別出重要的業務資料，並註冊到系統中，填寫相關的業務情況，如技術負責人、業務負責人、資料應用場景、延遲或錯誤帶來的影響、是否會發生資產損失等，完成後，會將這部分資料的任務掛到平臺基線上，一旦延遲或錯誤，即自動生成故障單，形成故障；
故障等級
故障發生後，會根據一定的標準判斷故障等級，如故障時長、客戶投訴量、資金損失等，將故障按 P1~ P4 定級，各團隊會有故障分的概念，到年底會根據故障分情況來判斷本年度的運維效果；
故障處理
故障發生後，需要快速的識別故障原因，並迅速解決，消除影響；
在處理故障的過程中，會盡量將故障的處理進度通知到相關方，儘可能減少對業務的影響；
故障 Review
故障 Review：即分析故障的原因、處理過程的覆盤、形成後續解決的 Action，並且都會以文字的形式詳細記錄，對故障的責任進行歸屬，一般會責任到人；
注：對故障責任的判定，不是為了懲罰個人，而是通過對故障的覆盤形成解決方案，避免問題再次發生；