一、數據質量保障原則

如何評估數據質量的好壞，業界有不同的標準，阿里主要從4個方面進行評估：完整性、準確性、一致性、及時性；

1. 完整性

數據完整性是數據最基礎的保障；

完整性：指數據的記錄和信息是否完整，是否存在缺失的情況；

數據缺失：主要包括記錄的缺失和記錄中某個字段信息的缺失；

記錄的丟失：如，交易中每天只發訂單數都在 100 萬筆左右，如果某天支付訂單突然下降到 1 萬筆，很可能是記錄丟失了；記錄中字段的丟失：如，訂單的商品 ID、賣家 ID 都是必然存在的，這些字段的空值個數肯定是 0，一旦大于 0 就違背了完整性約束；

2. 準確性

準確性：指數據匯總記錄的信息和數據是否準確，是否存在異常或者錯誤的信息；

準確：數據表中記錄的信息與業務過程中真實發生的事實要一致；如何判斷是否準確：卡點監控 —— 制定相應規則，根據根校驗數據，符合規則的數據則認為是準確的；如，一筆訂單如果出現確認收貨金額為負值，或者下單時間在公司成立之前，或者訂單沒有買家信息等，這些必然是有問題的；

3. 一致性

一致性：一般體現在跨度很大的數據倉庫體系中，如阿里的數據倉庫，內部有很多業務數據倉庫分支，對于同一份數據，必須保證一致性；

一致：也就是指多個業務數據倉庫間的公共數據，必須在各個數據倉庫中保持一致；

如，用戶 ID，從在線業務庫加工到數據倉庫，再到各個消費節點，必須都是同一種類型，長度也需要保持一致；

所以，在阿里建設數據倉庫時，才有了公共層的加工，以確保數據的一致性；

4. 及時性

及時性：指數據要能及時產出；

主要體現在數據應用上，要及時產出給到需求方；

一般決策支持分析師希望當天就能看到前一天的數據，而不是等三五天才能看到某一個數據分析結果；否則就已失去了數據及時性的價值；

如，阿里 “雙 11” 的交易大屏數據，就要做到秒級；

二、數據質量方法概述

阿里的數據質量建設體系：

消費場景知曉

功能：分析解決消費場景知曉的問題；

方法：通過數據資產等級和基于元數據的應用鏈路，來分析解決消費場景知曉的問題；

確定數據資產等級：根據應用的影響程度，確定數據資產的等級；

過程：

根據數據鏈路血緣，將資產等級上推至各數據生產加工的各個環節，確定鏈路上所有涉及數據的資產等級，以及在各個加工環節上根據資產等級的不同所采取不同的處理方式；

數據生產加工各個環節卡點校驗

主要對兩部分的數據卡點校驗：在線系統和離線系統數據生產加工各個環節的卡點校驗；

在線系統：OLTP（On - Line Transaction Processing，聯機事務處理）系統；

在線系統生產加工各環節卡點校驗：

1.根據資產等級的不同，當對應的業務系統變更時，決定是否將變更通知下游；2.對于高資產等級的業務，當出現新業務數據時，是否納入統計中，需要卡掉審批；

離線系統：OLAP（On - Line Analytical Processing，聯機分析處理）系統；

離線系統生產加工各環節卡點校驗：

主要包括：代碼開發、測試、發布、歷史或錯誤數據回刷等環節的卡點校驗；代碼開發階段、發布前的測試階段針對數據資產等級的不同，對校驗的要求有所不同；

風險點監控

風險點監控：主要針對在數據運行過程中可能出現的數據質量和時效等問題進行監控；

主要對兩個方面進行風險點監控：

在線數據的風險點監控：

主要針對在線系統日常運行產出的數據進行業務規則的校驗；主要使用 “實時業務檢測平臺 BCP（Biz Check Platform）”；

離線數據的風險點監控：

主要是針對離線系統日常運行產出的數據，進行數據質量監控和時效性監控；DQC：監控數據質量；摩薩德：監控數據時效性；

質量衡量

對質量的衡量：

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

質量分：綜合事前和事后的衡量數據進行打分；

質量配套工具 針對數據質量的各個方面，都有相關的工具進行保證，以提高效能；

??01? 消費場景知曉

消費場景知曉的問題：

數據研發工程師難以確認幾百 PB 的數據是否都是重要的？是否都要進行保障？是否有一些數據已經過期了？是否所有需要都要精確的進行質量保障？

解決方案：數據資產等級方案；

產出：

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

數據資產等級定義

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

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

毀滅性質

即，數據一旦出錯，將會引起重大資產損失，面臨重大受益損失，造成重大公共風險；

全局性質

即，數據直接或間接用于集團業務和效果的評估、重要平臺的運維、對外數據產品的透露、影響用戶在阿里系網站的行為等；

局部性質

即，數據直接或間接用于內部一般數據產品或者運營 / 產品報告，如果出現問題會給事業部或業務線造成影響，或者造成工作效率損失；

一般性質

即，數據主要用于小二的日常數據分析，出現問題幾乎不會帶來影響或者影響很小；

未知性質

不能明確說出數據的應用場景，則標注為未知；

對于不同的數據資產等級，使用英文 Asset 進行標記：

毀滅性質：A1 等級；全局性質：A2 等級；局部性質：A3 等級；一般性質：A4 等級；未知性質：A5 等級；重要程度：A1 > A2 > A3 > A4 > A5；

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

數據資產等級落地方法

需要解決的問題：對于如此龐大的數據量，如何給每一份數據都打上一個等級標簽？

數據資產等級落地的方法 / 步驟：

數據流轉過程

數據從業務系統中產生，經過同步工具進入數據倉庫系統中，在數據倉庫中進行一般意義上的清洗、加工、整合、算法、模型等一系列運算； 通過同步工具輸出到數據產品中進行消費；

數據從業務系統到數據倉庫再到數據產品，都是以表的形式體現的，流轉過程如下圖：

同步到數據倉庫（對應到阿里就是 MaxCompute 平臺）中的都是業務數據庫的原始表，主要用于承載業務需求，往往不能直接用于數據產品；（一般是 ODS 層的全量數據）

在數據產品中使用的都是經過數據倉庫加工后的產出表；（根據需求 / 報表進行加工）

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

總結：

通過上述步驟，就完成了數據資產等級的確認，給不同的數據定義了不同的重要程度，需要用到元數據的支撐；

02?? 數據加工過程卡點校驗

目的：保障數據準確性、保障與離線數據的一致性；

在線業務系統卡點校驗（數據產出環節） 在線系統數據加工過程卡點校驗，主要指在在線系統的數據生產過程中進行的卡點校驗； 目的：保障與離線數據的一致性； 背景 / 問題：在線業務復雜多變，總是在不斷變更，每一次變更都會帶來數據的變化，因此需要做到兩點：1、數據倉庫需要適應著多變的業務發展，及時做到數據的準確性；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 測試：

不執行代碼，僅運行執行計劃，避免線上和線下環境不一致導致語法錯誤；

真實環境的運行測試：

使用真實數據進行測試；

節點變更或數據重刷新前的變更通知 通知內容：變更原因、變更邏輯、變更測試報告、變更時間等；

過程：使用通知中心，將變更原因、變更邏輯、變更測試報告、變更時間等自動通知下游，下游對此次變更沒有異議后，再按照約定時間執行發布變更，將變更對下游的影響降低至最低；

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? 質量衡量

保障數據倉庫的數據質量，有很多方案，評價這些方案的優劣，需要一套度量指標：

數據質量起夜率

一般數據倉庫的作業任務都是在夜晚進行，一旦出現問題就需要值班人員起夜進行處理；

起夜率：用每個月的起夜次數，作為衡量數據質量建設完善度的一個指標；

數據質量事件

數據質量事件：記錄每一次數據質量的問題；

針對每一個數據質量問題，都記錄一個數據質量事件：

功能：既用來衡量數據本身的質量，也用來衡量數據鏈路上下游的質量，是數據質量的一個重要度量指標；

用來跟進數據質量問題的處理過程； 用來歸納分析數據質量原因； 根據數據質量原因來查缺補漏，既要找到數據出現問題的原因，也要針對類似問題給出后續預防方案； 數據質量故障體系

對于嚴重的數據質量事件，將升級為故障；

故障：指問題造成的影響比較嚴重，已經給公司帶來資產損失或者公關風險；

背景：數據從采集到最后的消費，整個鏈路要經過幾十個系統，任何一個環節出現問題，都會影響數據的產出，因此需要一種機制，能夠將各團隊綁在一起，目標一致，形成合力，故障體系在這個背景下應運而生；

故障體系中，一旦出現故障，就會通過故障體系，要求相關團隊在第一時間跟進解決問題，消除影響；

故障定義

首先識別出重要的業務數據，并注冊到系統中，填寫相關的業務情況，如技術負責人、業務負責人、數據應用場景、延遲或錯誤帶來的影響、是否會發生資產損失等，完成后，會將這部分數據的任務掛到平臺基線上，一旦延遲或錯誤，即自動生成故障單，形成故障；

故障等級

故障發生后，會根據一定的標準判斷故障等級，如故障時長、客戶投訴量、資金損失等，將故障按 P1~ P4 定級，各團隊會有故障分的概念，到年底會根據故障分情況來判斷本年度的運維效果；

故障處理

故障發生后，需要快速的識別故障原因，并迅速解決，消除影響；

在處理故障的過程中，會盡量將故障的處理進度通知到相關方，盡可能減少對業務的影響；

故障 Review

故障 Review：即分析故障的原因、處理過程的復盤、形成后續解決的 Action，并且都會以文字的形式詳細記錄，對故障的責任進行歸屬，一般會責任到人；

注：對故障責任的判定，不是為了懲罰個人，而是通過對故障的復盤形成解決方案，避免問題再次發生；