極光筆記丨數據質量建設實踐

作者:極光數據架構師—曠東林

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任務的依賴血緣關係,能進一步評估數據質量問題的影響範圍,根據影響範圍給與不同的告警等級,根據影響的業務線提前通知相關業務人員和開發人員做好相關的協調工作。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章