阿里大數據管理篇大總結

第 1 章 元數據

1.1 元數據概述

1.1.1 元數據定義

元數據打通了源數據、數據倉庫、數據應用，記錄了數據從產生到消費的全過程。元數據主要記錄數據倉庫中模型的定義、各層級間的映射關係、監控數據倉庫的數據狀態及 ETL 的任務運行狀態。

元數據按用途的不同分爲兩類：技術元數據（ Technical Metadata) 和業務元數據（Business Metadata ）

• 技術元數據：是存儲關於數據倉庫系統技術細節的數據，是用於開發和管理數據倉庫使用的數據。

  分佈式計算系統存儲元數據，如表、列、分區等信息。記錄了表的表名。分區信息、責任人信息、文件大小、表類型，生命週期，以及列的字段名、字段類型、字段備註、是否是 分區字段等信息。

  分佈式計算系統運行元數據，如 MaxCompute 上所有作業運行等 信息：類似於 Hive 的 Job 日誌，包括作業類型、實例名稱、輸入輸出、 SQL 、運行參數、執行時間、最細粒度的 FuxiInstance (MaxCompute 中 MR 執行的最小單元）執行信息等。

  數據開發平臺中數據同步、計算任務、任務調度等信息，包括數據同步的輸入輸出表和字段，以及同步任務本身的節點信息：計算任務主要有輸入輸出、任務本身的節點信息；任務調度主要有任務的依賴類型、依賴關係等，以及不同類型調度任務的運行日 志等。

  數據質量和運維相關元數據，如任務監控、運維報警、數據質量、故障等信息，包括任務監控運行日誌、告警配置及運行日誌、故障信息等。

• 業務元數據：從業務角度描述了數據倉庫中的數據，它提供了介於使用者和實際系統之間的語義層，使得不懂計算機技術的業務人員也能夠 “讀懂” 數據倉庫中的數據。

1.1.2 元數據價值

元數據有重要的應用價值，是數據管理、數據內容、數據應用的基礎；

• 在數據管理方面爲集團數據提供在計算、存儲、成本、質量、安全、模型等治理領域上的數據支持。

  例如在計算上可以利用元數據查找超長運行節點，對這些節點進行專項治理，保障基線產出時間。

• 在數據內容方面爲集團數據進行數據域、數據主題、業務屬性等的提取和分析提供數據素材。

  例如可以利用元數據構建知識圖譜，給數據打標籤，清楚地知道現在有哪些數據。

• 在數據應用方面打通產品及應用鏈路，保障產品 數據準確、及時產出。

  例如打通 MaxCompute 和應用數據，明確數據資產等級，更有效地保障產品數據。

1.1.3 統一元數據體系建設

元數據的質量直接影響到數據管理的準確性，如何把元數據建設好將起到至關重要的作用。元數據建設的目標是打通數據接入到加工，再到數據消費整個鏈路，規範元數據體系與模型，提供統一的元數據服務出口，保障元數據產出的穩定性和質量。

1.2 元數據應用

價值：數據驅動決策，數字化運營

• 通過數據驅動的方法，我們能夠判斷趨勢，從而展開有效行動，幫助自己發現問 題，推動創新或解決方案的產生

• 對於數據使用者，可以通過元數據讓其快速找到所需要的數據；

• 對於 ETL 工程師，可以通過元數據指導其進行模型設計、任務優化和任務下線等各種日常 ETL 工作；

• 對於運維工程師，可以通過元數據指導 其進行整個集羣的存儲、計算和系統優化等運維工作

1.2.1 Data Profile

核心思路：爲紛繁複雜的數據建立一個脈絡清晰的血緣圖譜。通過圖計算、標籤傳播算法等技術，系統化、自動化地對計算與存儲平臺上的數 據進行打標、整理、歸檔，實際承擔的是爲元數據 “畫像” 的任務，開發了四類標籤：

• 基礎標籤：針對數據的存儲情況、訪問情況、安全等級等進行打標籤。

• 數倉標籤：針對數據是增量還是全量、是否可再生、數據的生命週期來進行標籤化處理。

• 業務標籤：根據數據歸屬的主題域、產品線、業務類型爲數據打上不同的標籤。

• 潛在標籤：這類標籤主要是爲了說明數據潛在的應用場景，比如 社交、媒體、廣告、電商、金融等。

1.2.2 元數據門戶

• 元數據門戶致力打造一站式的數據管理平臺、高效的一體化數據市場

• “前臺”產品爲數據地圖，定位消費市場，實現檢索數據、理解數據等 “找數據” 需求

• “後臺” 產品爲數據管理，定位於一站式數據管理，實現成本管理、安全管理、質量管理等。

1.2.3 應用鏈路分析

通過應用鏈路分析，產出表級血緣、字段血緣和表的應用血緣。其中表級血緣主要有兩種計算方式：

• 一種是通過 MR 任務日誌進行解析；

• 一種是根據任務依賴進行解析。

常見的應用鏈路分析應用主要有影響分析、重要性分析、下線分析、鏈路分析、尋根溯源、故障排查等

1.2.4 數據建模

通過元數據驅動的數據倉庫模型建設，可以在一定程度上解決此問題，提高數據倉庫建模的數據化指導，提升建模效率。

• 表的基礎元數據，包括下游情況、查詢次數、關聯次數、聚合次數、產出時間等。

• 表的關聯關係元數，包括關聯表、關聯類型、關聯字段、關聯次數等。

• 表的字段的基礎元數據，包括字段名稱、字段註釋、查詢次數、關聯次數、聚合次數、過濾次數等。

• 其中查詢指 SQL 的 SELECT ，關聯指 SQL 的 JOIN ，聚合指 SQL 的 GROUP BY ，過濾指 SQL 的 WHERE。

星形模型設計中，使用元數據信息有：

• 基於下游使用中關聯次數大於某個閾值的表或查詢次數大於某個閾值的表等元數據信息，篩選用於數據模型建設的表。

• 基於表的字段元數據，如字段中的時間字段、字段在下游使用中的過濾次數等，選擇業務過程標識字段。

• 基於主從表的關聯關係、關聯次數，確定和主表關聯的從表。

• 基於主從表的字段使用情況，如字段的查詢次數、過濾次數、關聯次數、聚合次數等，確定哪些字段進入目標模型。

1.2.5 驅動 ETL 開發

第 2 章 計算管理

2.1 系統優化

2.1.1 HBO

（History-Based Optimizer，基於歷史的優化器）

在任務穩定的情況下，可以考慮基於任務的歷史執行情況進行資源評估，即採用 HBO

• 提高 CPU 利用率

• 提高內存利用率

• 提高 Instance 併發數

• 降低執行時長

針對 “大促” 這類數據量暴漲的場景， HBO 也增加了根據數據量動態調整 Instance 數的功能，主要依據 Map 的數據量增長情況進行調整。

2.1.2 CBO

基於代價的優化器，根據收集的統 計信息來計算每種執行方式的代價，進而選擇最優的執行方式。

引人了重新排序 Join（JoinReorder）和自動 MapJoin（AutoMapJoin ）優化規則等，同時基於 Volcano 模型的優 化器會盡最大的搜索寬度來獲取最優計劃

可以設置規則白名單（使用哪些優化規則）、黑名單（關閉哪些優化規則）

Optimizer 會提供謂詞下推（ PredicatePushDown ）優化，主要目的是儘量早地進行謂詞過濾，以減少後續操作的數據量，提高性能。但需要注意的是：

• UDF：對於 UDF 是否下推，優化器做了限制，不會任意下推這種帶有用戶意圖的函數，主要是因爲不同用戶書寫的函數含義不一樣，不可以一概而論。

• 不確定函數：對於不確定函數，優化器也不會任意下推，比如 sample 函數，如 果用戶將其寫在 where 子句中，同時語句存在 Join ，則優化器是不會下推到 TableScan 的

• 隱式類型轉換：書寫 SQL 語句時，應儘量避免 Join Key 存在隱式類型轉換。

2.2 任務優化

2.2.1 Map 傾斜

在 Map 端讀數據時，由於讀人數據的文件大小分佈不均勻，因此 會導致有些 MapInstance 讀取並且處理的數據特別多，而有些 Map Instance 處理的數據特別少，造成 Map 端長尾；

上游表文件的大小特別不均勻，並且小文件特別多，導致當前表 Map 端讀取的數據分佈不均勻，引起長尾，手段有二：

• 通過對 上游合併小文件 + 調節本節點的小文件 的參數來進行優化

• 通過 “distribute by rand(” 會將 Map 端分發後的數據重新按照隨 機值再進行一次分發

Map 端長尾的根本原因是由於讀入的文件塊的數據分佈不均勻，再 加上 UDF 函數性能、Join、聚合操作等，導致讀人數據量大的 Map lnstance 耗時較長。在開發過程中如果遇到 Map 端長尾的情況，首先考 慮如何讓 Map Instance 讀取的數據量足夠均勻，然後判斷是哪些操作導致 Map Instance 比較慢，最後考慮這些操作是否必須在 Map 端完成， 在其他階段是否會做得更好。

2.2.2 Join 傾斜

因爲數據傾斜導致長尾的現象比較普遍，嚴重影響任務的執行時 間，尤其是在 “雙 l l” 等大型活動期間，長尾程度比平時更嚴重。比 如某些大型店鋪的 PV 遠遠超過一般店鋪的 PV，當用瀏覽日誌數據和 賣家維表關聯時，會按照賣家 ID 進行分發

• MapJoin 方案：Join 傾斜時，如果某路輸入比較小，則可以採用 MapJoin 避免傾斜；但是 MapJoin 的使用有限制，必須是 Join 中的從表比較小纔可用

• Join 因爲空值導致長尾：將空值處理成隨機值

• Join 因爲熱點值導致長尾：先將熱點 key 取出，對於主表數據用熱點 key 切分成熱點數據和非熱點數據兩部分分別處理，最後合併。

2.2.3 Reduce 傾斜

Reduce 端產生長尾的主要原因就是 key 的數據分佈不均勻

• 對同一個表按照維度對不同的列進行 Count Distinct 操作，造成 Map 端數據膨脹，從而使得下游的 Join 和 Reduce 出現鏈路上的長尾。

• Map 端直接做聚合時出現 key 值分佈不均勻，造成 Reduce 端長尾 對熱點 key 進行單獨處理，然後通過 “UnionAll” 合併

• 動態分區數過多時可能造成小文件過多，從而引起 Reduce 端長尾 把符合不同條件的數據放到不同的分區
  解決小文件過多參數：set odps.sql.reshuffle.dynamicpt=true;

• 多個 Distinct 同時出現在一段 SQL 代碼中時，數據會被分發多次， 不僅會造成數據膨脹 N 倍，還會把長尾現象放大 N 倍（常見） 提前 Group By，消除 Distinct，即分別把指標 GroupBy 到 “原始表的數據粒度”，然後再進行 Join 操作
  當出現的 Distinct 個數不多、表的數據量也不是很大、表的數據分佈較均勻時，不使用 Multi Distinct 的計算效果也是可以接受的

第 3 章 存儲和成本管理

3.1 數據壓縮

針對 3 份副本的壓縮方案：archive 壓縮方法，存儲比約爲 1:3 提高到 1:1.5

• 恢復數據塊的時間將要比原來的方式更長，讀的性能會有一 定的損失

• 應用在冷備數據與日誌 數據的壓縮存儲上。

3.2 數據重分佈

• 基於列存儲，每個表的數據 分佈不同，插人數據的順序不一樣，會導致壓縮效果有很大的差異，因 此通過修改表的數據重分佈，避免列熱點，將會節省一定的存儲空間。

• 主要通過修改 distributeby 和 sort by 字段的方法進行數據重分佈

• 一般會篩選出重分佈效果高於 15% 的表進行優化處理

3.3 存儲治理項優化

• 優化項有未管理表、空表、 最近 62 天未訪問表、數據無更新無任務表、數據無更新有任務表、開 發庫數據大於 100GB 且無訪問表、長週期表等

3.4 生命週期管理

生命週期管理的根本目的就是用最少的存儲成本來滿足最大的業務需求，使數據價值最大化。

3.4.1 生命週期管理策略

1. 週期性刪除策略

2. 徹底刪除策略

3. 永久保留策略

4. 極限存儲策略

5. 冷數據管理策略

6. 增量表 merge 全量表策略：交易增量數據，使用 訂單創建日期或者訂單結束日期作爲分區，同時將未完結訂單放在最大 分區中，對於存儲，一個訂單在表裏只保留一份；對於用戶使用，通過 分區條件就能查詢某一段時間的數據。

3.4.2 通用的生命週期管理矩陣

1. 歷史數據等級劃分

• PO ：非常重要的主題域數據和非常重要的應用數據，具有不可恢 復性，如交易、日誌、集團 KPI 數據、 IPO 關聯表。

• P1：重要的業務數據和重要的應用數據，具有不可恢復性，如重 要的業務產品數據。

• P2 ：重要的業務數據和重要的應用數據，具有可恢復性，如交易 線 ETL 產生的中間過程數據。

• P3：不重要的業務數據和不重要的應用數據，具有可恢復性，如 某些 SNS 產品報表。

3.5 數據成本計量

將數據成本定義爲存儲成本、計算成本和掃描成本三個部分，能夠很好地體現出數據在加工鏈路中的 上下游依賴關係

• 掃描成本：對上游數據表的掃描

• 存儲成本：計量數據表消耗的存儲資源

• 計算成本：計量數據計算過程中的 CPU 消耗

3.6 數據使用計費

• 根據 3.5，分爲計算付費、存儲付費和掃描付費

• 通過成本計量，可以比較合理地評估出數據加工鏈路中的成本，從成本的角度反映出在數據加工鏈路中是否存在加工複雜、鏈路過長、依賴不合理等問題，間接輔助數據模型優化，提升數據整合效率

• 通過數據使用計費，可以規範下游用戶的數據使用方法，提升數據使用效率， 從而爲業務提供優質的數據服務

第 4 章 數據質量

4.1 數據質量保障原則

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

1. 完整性

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

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

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

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

2. 準確性

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

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

3. 一致性

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

  一致：也就是指多個業務數據倉庫間的公共數據，必須在各個數據倉庫中保持一致；
  如，用戶 ID，從在線業務庫加工到數據倉庫，再到各個消費節點，必須都是同一種類型，長度也需要保持一致；
  所以，在阿里建設數據倉庫時，纔有了公共層的加工，以確保數據的一致性；

4. 及時性

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

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

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

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

4.2 數據質量方法概述

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

1. 消費場景知曉

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

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

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

• 過程：

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

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

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

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

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

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

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

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

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

3. 風險點監控

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

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

• 在線數據的風險點監控：

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

• 離線數據的風險點監控：

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

4. 質量衡量

• 對質量的衡量：

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

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

5. 質量配套工具

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

4.2.1 消費場景知曉

• 消費場景知曉的問題：

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

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

• 產出：

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

1. 數據資產等級定義

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

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

• 毀滅性質

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

• 全局性質

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

• 局部性質

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

• 一般性質

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

• 未知性質

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

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

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

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

2. 數據資產等級落地方法

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

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

數據流轉過程

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

• 通過同步工具輸出到數據產品中進行消費；

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

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

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

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

總結：

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

4.2.2 數據加工過程卡點校驗

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

1. 在線業務系統卡點校驗（數據產出環節）

• 在線系統數據加工過程卡點校驗，主要指在在線系統的數據生產過程中進行的卡點校驗；

• 目的：保障與離線數據的一致性；

• 背景 / 問題：在線業務複雜多變，總是在不斷變更，每一次變更都會帶來數據的變化，因此需要做到兩點：
  1、數據倉庫需要適應着多變的業務發展，及時做到數據的準確性；
  2、需要高效的將在線業務的變更通知到離線數據倉庫；阿里解決上述兩個問題的方法：工具和人工雙管齊下：既要在工具上自動捕捉每一次業務的變化，同時也要求開發人員在意識上自動進行業務變更通知；

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 測試：

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

• 真實環境的運行測試：

使用真實數據進行測試；

• 節點變更或數據重刷新前的變更通知

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

4.2.3 風險點監控

風險點監控：主要指針對數據在日常運行過程中容易出現的風險進行監控，並設置報警機制；
主要包括在線數據和離線數據運行風險點監控；

目的：保障數據的準確性；

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 天運行的平均時間來推算的；雖然有誤判的可能性，但是總體還是非常準確的，可以接受；

• 自定義監控

自定義監控是摩薩德比較輕量級的監控功能，用戶可以根據自己的需求進行配置，主要包括：

1. 出錯告警：可根據應用、業務、任務三個監控對象進行出錯告警配置，監控對象出錯即告警給到人 / Owner / 值班表；

2. 完成告警：可根據應用、業務、任務三個監控對象進行完成情況告警配置，監控對象完成即告警給到人 / Owner / 值班表；

3. 未完成告警：可根據應用、業務、任務三個監控對象進行未完成情況告警配置，監控對象未完成即告警給到人 / Owner / 值班表；

4. 週期性告警：針對某個週期的小時任務，如果在某個時間未完成，即告警給到人 / Owner / 值班表；

5. 超時告警：根據任務運行時長進行超時告警配置，任務運行超過指定時間即告警給到人 / Owner / 值班表；

• 摩薩德甘特圖的服務

針對業務的運行情況，摩薩德會提供一天關鍵路徑，即完成業務的最慢任務鏈路圖；因爲每個業務上游可能有成千上萬個任務，所以這條關鍵路徑對於業務鏈路優化來說非常重要；

4.2.4 質量衡量

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

• 數據質量起夜率

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

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

• 數據質量事件

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

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

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

1. 用來跟進數據質量問題的處理過程；

2. 用來歸納分析數據質量原因；

3. 根據數據質量原因來查缺補漏，既要找到數據出現問題的原因，也要針對類似問題給出後續預防方案；

• 數據質量故障體系

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

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

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

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

1. 故障定義

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

2. 故障等級

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

3. 故障處理

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

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

4. 故障 Review

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

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/XbLewTlzY7k709QP2Z2neg