作者：極光資料架構師—曠東林

01 摘要

本文提出了一種大資料質量體系建設的方法，能對資料處理過程中的ETL任務進行資料質量監控，並根據監控結果進行必要的告警或任務中止。監控任務的開啟可以增量進行，對存在的ETL任務不需要做任何修改，監控任務的開啟或關閉也不影響原有的ETL任務的依賴關係。

02 背景

隨著極光各個業務線的業績發展越來越依賴資料中心所提供的資料分析能力。

資料中心資料平臺上執行的ETL任務也越來越多，處理邏輯也越來越發複雜ETL任務的依賴鏈也越來越長，這些ETL任務往往還是由不同團隊的不同業務人員開發的，業務人員的開發水準參差不齊，不同團隊之間的溝通也可能不暢，造成ETL任務的資料質量問題頻發，更嚴重的是，出了質量問題後，因為任務的依賴鏈很長，造成排查資料質量問題困難重重，需上下游一層一層的排查，需不同團隊的開發人員協調排查，極大的降低了資料產出效率。

另外，因為沒有統一的資料質量監管措施，往往是業務發現數據報表有問題後反饋給開發人員，開發人員才被動的去查詢問題，修復錯誤，缺乏發現問題的主動性。

最後，因為沒有統一的資料質量監管措施，往往只會在資料質量問題已經擴散開來以後才會被感知到，造成大量計算資源的浪費和修補過程的耗時。

為了徹底扭轉這種局面，一個強大的資料質量監控系統是非常必要的。本文就結合極光的實際情況設計了一套資料質量監控系統，比較完美的解決了上述的問題。

03 設計方案

極光的資料質量監控平臺非常依賴於ETL任務的排程平臺提供的底層功能，其整體架構如圖3-1所示

圖3-1資料質量監控專案後臺架構

資料質量服務後臺負責的事務主要由：

1、負責接收前端的配置資訊並存入後臺資料庫；

2、接受質量檢查過程中上報的指標採集，指標評估，任務告警制動等的質量檢查過程的跟蹤日誌;

3、從排程系統獲取排程任務列表及其與質量檢查有關的任務配置資訊;

圖中的排程節點本質上就是排程系統啟動的一個排程程序，在正常的排程過程中，排程程序根據配置的任務型別執行相應程式碼，比如，如果執行的任務是一個hive指令碼，則排程程序會通過hive的客戶端提交hive指令碼給hive服務端來執行該指令碼，這裡為執行hive指令碼所需要的hive客戶端程式碼被統一抽象成一個SideCarProxy元件，提供統一的介面，不同型別的ETL任務通過不同的SideCarProxy實現來提交和執行不同型別的ETL任務，比如Spark任務的SideCarProxy實現就會提供提交spark任務的功能，Spark型別的ETL任務只需負責具體業務邏輯的實現。

為了支援ETL任務開啟資料質量檢查功能，我們擴充套件了SideCarProxy的功能，在保持與原來介面相容的基礎上擴充套件了三種介面，分別是資料質量指標採集介面，資料質量指標評估介面，資料質量檢查動作介面和資料質量告警配置介面。這些質量檢查介面根據其觸發檢查的時間點不同可以進一步分為前置檢查，中置檢查和後置檢查。

前置檢查是在ETL任務執行前觸發的質量檢查工作，一般用於檢查ETL任務的輸入資料是否滿足要求；中置檢查時在ETL任務執行期間監控任務執行情況的一種檢查機制，常常用於任務啟動時間，執行時長，完成時間等指標的檢查；後置檢查是在ETL任務執行完成後觸發的質量檢查工作，一般用於檢查ETL任務的輸出資料是否滿足要求。

3.1 資料質量指標採集介面

資料質量的檢查依賴資料質量檢查指標的定義，這種指標的定義完全由業務根據自身的需要定義。為了提供系統的使用便利性，系統內建了一些常用的資料質量檢查指標，比如任務的啟動時延，執行時長，完成時延。對於業務特定的指標，系統支援通過sparksql的方式來自定義業務特有的資料質量採集指標，如截圖3-2所示

圖3-2 質量檢查的預定義指標和自定義指標

3.2 資料質量指標

利用資料質量指標採集介面，可以實現從資料的時效性，完整性，一致性，統計特徵等各個角度來實現資料質量的監控，下面通過示例的方式來說明怎麼實現這些指標的監控。

3.2.1 時效性指標監控

時效性指標目前主要是通過任務的啟動時延和結束時延來實現，啟動時延監控ETL任務配置的啟動時間與任務實際的啟動時間之間的延遲；結束時延監控ETL任務配置的啟動時間與任務實際的完成時間之間延遲；這兩個指標監控系統已經原生支援，開發人員只需開啟這兩個監控項即可

3.2.2完整性指標監控

完整性指標一般監控目標表的資料是否完整，最簡單的檢測方式就是統計目標表指定分割槽的記錄數，這種檢測目前可以通過系統的自定義指標介面來實現，其實現的SQL邏輯如下表所示

表3-1 完整性指標採集的SQL實現

SQL中的變數會自動被任務排程時所引用的具體變數值替換，每次ETL任務執行時該指標都會被檢測一次，其檢測值在經過評估規則的評估後根據告警規則實現告警動作。後續規劃把一些大家常用的完整性指標實現為系統原生支援，提高大家使用的便利性。

3.2.3 一致性指標監控

一致性指標的監控和完整性指標的實現方式完全相同，目前的實現還需要使用者編寫SQL指令碼來實現，後續也規劃把常用的一致性指標實現為系統原生支援的方式。

3.2.4資料統計特徵監控

這類指標是完全依賴ETL任務本身的業務邏輯的，本質上是一類資料的業務質量的檢測，目前該類指標的監控都需要業務自己通過SQL的方式來表達指標採集邏輯，系統只會提供這些指標的儲存和管理功能。下面以監控任務的資料傾斜程度為例來說明這類監控指標的實現，假定資料傾斜以資料分佈偏離均勻分佈的程度來衡量，則其傾斜指標可以定義為(公式來源於資訊理論的交叉熵)

表3-2 資料統計特徵指標採集的SQL實現

獲取這個傾斜率後根據評估規則中配置的閾值即可檢測資料傾斜的程度是否在合理的範圍內，並做相應的告警。

3.3 資料質量指標評估介面

資料質量指標評估介面用於評估採集到的資料指標是否符合資料質量要求，其介面主要接受兩個引數，分別是評估規則和閾值範圍。評估規則決定了採集到的指標值經過怎樣的計算才能轉換成評估值，閾值範圍決定了評估值的合理範圍，評估值一旦超出閾值範圍，就視為資料質量不合格。

根據業務的需要，可以選擇不同的評估規則，為了提高系統的使用便利性，系統內建了透傳，同比，環比三個評估規則，業務也可以根據業務的需要通過sparksql自定義評估規則。

圖3-3 質量檢查的評估規則與告警設定

3.4資料質量檢查動作介面

資料質量檢查動作介面配置資料質量檢查不合格時所採取的措施，目前支援忽略，告警和阻塞三種動作。忽悠表示不做任何操作，檢查任務和ETL任務正常執行；告警表示根據配置的告警模板通過釘釘，簡訊或電話的方式發出告警訊息，但檢查任務和ETL任務都正常繼續執行不受影響；阻塞表示根據配置的告警模板通過釘釘，簡訊或電話的方式發出告警訊息，同時該ETL任務及其質量檢查任務都終止，ETL任務視為執行失敗，依賴該任務的後續任務不能繼續執行，此時，需要人工干預修復資料並通過資料質量檢查後該任務才視為執行成功。

3.5資料質量告警配置介面

資料質量告警配置介面主要配置告警的接收人，接受渠道和其他一些與告警有關的一些高階設定

04 總結

資料質量監控專案為業務資料質量的監控提供了一個統一的平臺，使得業務資料的質量保障工作從被動通知提升到了主動發現的水準，併為業務本身參與資料質量保障工作提供的參與手段。

同時，為了進一步提高資料質量的保障工作，資料質量監控專案也在不斷給增強和完善，後續規劃改善的幾個方面主要有：

1、持續提供更多的預定義採集指標，預定義評估指標

2、支援更多的自定義指標的實現方式，比如支援通過python實現自定義指標

3、通過利用ETL任務的依賴血緣關係，能進一步評估資料質量問題的影響範圍，根據影響範圍給與不同的告警等級，根據影響的業務線提前通知相關業務人員和開發人員做好相關的協調工作。