Spark SQL 在極光的建設(shè)實踐
Locust性能測試工具的使用
數(shù)據(jù)質(zhì)量建設(shè)實踐
百億級數(shù)據(jù)的實時存取優(yōu)化與實踐
極光clickhouse千億級數(shù)據(jù)分析實踐之路
本文提出了一種大數(shù)據(jù)質(zhì)量體系建設(shè)的方法，能對數(shù)據(jù)處理過程中的ETL任務(wù)進(jìn)行數(shù)據(jù)質(zhì)量監(jiān)控，并根據(jù)監(jiān)控結(jié)果進(jìn)行必要的告警或任務(wù)中止。監(jiān)控任務(wù)的開啟可以增量進(jìn)行，對存在的ETL任務(wù)不需要做任何修改，監(jiān)控任務(wù)的開啟或關(guān)閉也不影響原有的ETL任務(wù)的依賴關(guān)系。
隨著極光各個業(yè)務(wù)線的業(yè)績發(fā)展越來越依賴數(shù)據(jù)中心所提供的數(shù)據(jù)分析能力。
數(shù)據(jù)中心數(shù)據(jù)平臺上運(yùn)行的ETL任務(wù)也越來越多，處理邏輯也越來越發(fā)復(fù)雜ETL任務(wù)的依賴鏈也越來越長，這些ETL任務(wù)往往還是由不同團(tuán)隊的不同業(yè)務(wù)人員開發(fā)的，業(yè)務(wù)人員的開發(fā)水準(zhǔn)參差不齊，不同團(tuán)隊之間的溝通也可能不暢，造成ETL任務(wù)的數(shù)據(jù)質(zhì)量問題頻發(fā)，更嚴(yán)重的是，出了質(zhì)量問題后，因為任務(wù)的依賴鏈很長，造成排查數(shù)據(jù)質(zhì)量問題困難重重，需上下游一層一層的排查，需不同團(tuán)隊的開發(fā)人員協(xié)調(diào)排查，極大的降低了數(shù)據(jù)產(chǎn)出效率。
另外，因為沒有統(tǒng)一的數(shù)據(jù)質(zhì)量監(jiān)管措施，往往是業(yè)務(wù)發(fā)現(xiàn)數(shù)據(jù)報表有問題后反饋給開發(fā)人員，開發(fā)人員才被動的去查找問題，修復(fù)錯誤，缺乏發(fā)現(xiàn)問題的主動性。
最后，因為沒有統(tǒng)一的數(shù)據(jù)質(zhì)量監(jiān)管措施，往往只會在數(shù)據(jù)質(zhì)量問題已經(jīng)擴(kuò)散開來以后才會被感知到，造成大量計算資源的浪費和修補(bǔ)過程的耗時。
為了徹底扭轉(zhuǎn)這種局面，一個強(qiáng)大的數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)是非常必要的。本文就結(jié)合極光的實際情況設(shè)計了一套數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)，比較完美的解決了上述的問題。
極光的數(shù)據(jù)質(zhì)量監(jiān)控平臺非常依賴于ETL任務(wù)的調(diào)度平臺提供的底層功能，其整體架構(gòu)如圖3-1所示
圖3-1數(shù)據(jù)質(zhì)量監(jiān)控項目后臺架構(gòu)
數(shù)據(jù)質(zhì)量服務(wù)后臺負(fù)責(zé)的事務(wù)主要由：
1. 負(fù)責(zé)接收前端的配置信息并存入后臺數(shù)據(jù)庫；
2. 接受質(zhì)量檢查過程中上報的指標(biāo)采集，指標(biāo)評估，任務(wù)告警制動等的質(zhì)量檢查過程的跟蹤日志;
3. 從調(diào)度系統(tǒng)獲取調(diào)度任務(wù)列表及其與質(zhì)量檢查有關(guān)的任務(wù)配置信息;
圖中的調(diào)度節(jié)點本質(zhì)上就是調(diào)度系統(tǒng)啟動的一個調(diào)度進(jìn)程，在正常的調(diào)度過程中，調(diào)度進(jìn)程根據(jù)配置的任務(wù)類型運(yùn)行相應(yīng)代碼，比如，如果運(yùn)行的任務(wù)是一個hive腳本，則調(diào)度進(jìn)程會通過hive的客戶端提交hive腳本給hive服務(wù)端來執(zhí)行該腳本，這里為運(yùn)行hive腳本所需要的hive客戶端代碼被統(tǒng)一抽象成一個SideCarProxy組件，提供統(tǒng)一的接口，不同類型的ETL任務(wù)通過不同的SideCarProxy實現(xiàn)來提交和運(yùn)行不同類型的ETL任務(wù)，比如Spark任務(wù)的SideCarProxy實現(xiàn)就會提供提交spark任務(wù)的功能，Spark類型的ETL任務(wù)只需負(fù)責(zé)具體業(yè)務(wù)邏輯的實現(xiàn)。
為了支持ETL任務(wù)開啟數(shù)據(jù)質(zhì)量檢查功能，我們擴(kuò)展了SideCarProxy的功能，在保持與原來接口兼容的基礎(chǔ)上擴(kuò)展了三種接口，分別是數(shù)據(jù)質(zhì)量指標(biāo)采集接口，數(shù)據(jù)質(zhì)量指標(biāo)評估接口，數(shù)據(jù)質(zhì)量檢查動作接口和數(shù)據(jù)質(zhì)量告警配置接口。這些質(zhì)量檢查接口根據(jù)其觸發(fā)檢查的時間點不同可以進(jìn)一步分為前置檢查，中置檢查和后置檢查。
前置檢查是在ETL任務(wù)運(yùn)行前觸發(fā)的質(zhì)量檢查工作，一般用于檢查ETL任務(wù)的輸入數(shù)據(jù)是否滿足要求；中置檢查時在ETL任務(wù)運(yùn)行期間監(jiān)控任務(wù)運(yùn)行情況的一種檢查機(jī)制，常常用于任務(wù)啟動時間，運(yùn)行時長，完成時間等指標(biāo)的檢查；后置檢查是在ETL任務(wù)運(yùn)行完成后觸發(fā)的質(zhì)量檢查工作，一般用于檢查ETL任務(wù)的輸出數(shù)據(jù)是否滿足要求。
數(shù)據(jù)質(zhì)量的檢查依賴數(shù)據(jù)質(zhì)量檢查指標(biāo)的定義，這種指標(biāo)的定義完全由業(yè)務(wù)根據(jù)自身的需要定義。為了提供系統(tǒng)的使用便利性，系統(tǒng)內(nèi)置了一些常用的數(shù)據(jù)質(zhì)量檢查指標(biāo)，比如任務(wù)的啟動時延，運(yùn)行時長，完成時延。對于業(yè)務(wù)特定的指標(biāo)，系統(tǒng)支持通過sparksql的方式來自定義業(yè)務(wù)特有的數(shù)據(jù)質(zhì)量采集指標(biāo)，如截圖3-2所示
圖3-2 質(zhì)量檢查的預(yù)定義指標(biāo)和自定義指標(biāo)
利用數(shù)據(jù)質(zhì)量指標(biāo)采集接口，可以實現(xiàn)從數(shù)據(jù)的時效性，完整性，一致性，統(tǒng)計特征等各個角度來實現(xiàn)數(shù)據(jù)質(zhì)量的監(jiān)控，下面通過示例的方式來說明怎么實現(xiàn)這些指標(biāo)的監(jiān)控。
時效性指標(biāo)目前主要是通過任務(wù)的啟動時延和結(jié)束時延來實現(xiàn)，啟動時延監(jiān)控ETL任務(wù)配置的啟動時間與任務(wù)實際的啟動時間之間的延遲；結(jié)束時延監(jiān)控ETL任務(wù)配置的啟動時間與任務(wù)實際的完成時間之間延遲；這兩個指標(biāo)監(jiān)控系統(tǒng)已經(jīng)原生支持，開發(fā)人員只需開啟這兩個監(jiān)控項即可
完整性指標(biāo)一般監(jiān)控目標(biāo)表的數(shù)據(jù)是否完整，最簡單的檢測方式就是統(tǒng)計目標(biāo)表指定分區(qū)的記錄數(shù)，這種檢測目前可以通過系統(tǒng)的自定義指標(biāo)接口來實現(xiàn)，其實現(xiàn)的SQL邏輯如下表所示
SELECT count(1) AS cnt FROMtarget_table_path WHERE pt_date = '${hivevar:pt_date}' |
表3-1 完整性指標(biāo)采集的SQL實現(xiàn)
SQL中的變量會自動被任務(wù)調(diào)度時所引用的具體變量值替換，每次ETL任務(wù)運(yùn)行時該指標(biāo)都會被檢測一次，其檢測值在經(jīng)過評估規(guī)則的評估后根據(jù)告警規(guī)則實現(xiàn)告警動作。后續(xù)規(guī)劃把一些大家常用的完整性指標(biāo)實現(xiàn)為系統(tǒng)原生支持，提高大家使用的便利性。
一致性指標(biāo)的監(jiān)控和完整性指標(biāo)的實現(xiàn)方式完全相同，目前的實現(xiàn)還需要用戶編寫SQL腳本來實現(xiàn)，后續(xù)也規(guī)劃把常用的一致性指標(biāo)實現(xiàn)為系統(tǒng)原生支持的方式。
這類指標(biāo)是完全依賴ETL任務(wù)本身的業(yè)務(wù)邏輯的，本質(zhì)上是一類數(shù)據(jù)的業(yè)務(wù)質(zhì)量的檢測，目前該類指標(biāo)的監(jiān)控都需要業(yè)務(wù)自己通過SQL的方式來表達(dá)指標(biāo)采集邏輯，系統(tǒng)只會提供這些指標(biāo)的保存和管理功能。下面以監(jiān)控任務(wù)的數(shù)據(jù)傾斜程度為例來說明這類監(jiān)控指標(biāo)的實現(xiàn)，假定數(shù)據(jù)傾斜以數(shù)據(jù)分布偏離均勻分布的程度來衡量，則其傾斜指標(biāo)可以定義為(公式來源于信息論的交叉熵)
SELECT sum(ln(cnt * 1.0/ total)) ASskew_rate FROM ( SELECT key, cnt, sum(cnt) over () AStotal FROM ( SELECT key, count(1) AScnt FROMtarget_table_path WHEREpt_date = '${hivevar:pt_date}' GROUP BYkey ) t ) |
表3-2 數(shù)據(jù)統(tǒng)計特征指標(biāo)采集的SQL實現(xiàn)
獲取這個傾斜率后根據(jù)評估規(guī)則中配置的閾值即可檢測數(shù)據(jù)傾斜的程度是否在合理的范圍內(nèi)，并做相應(yīng)的告警。
數(shù)據(jù)質(zhì)量指標(biāo)評估接口用于評估采集到的數(shù)據(jù)指標(biāo)是否符合數(shù)據(jù)質(zhì)量要求，其接口主要接受兩個參數(shù)，分別是評估規(guī)則和閾值范圍。評估規(guī)則決定了采集到的指標(biāo)值經(jīng)過怎樣的計算才能轉(zhuǎn)換成評估值，閾值范圍決定了評估值的合理范圍，評估值一旦超出閾值范圍，就視為數(shù)據(jù)質(zhì)量不合格。
根據(jù)業(yè)務(wù)的需要，可以選擇不同的評估規(guī)則，為了提高系統(tǒng)的使用便利性，系統(tǒng)內(nèi)置了透傳，同比，環(huán)比三個評估規(guī)則，業(yè)務(wù)也可以根據(jù)業(yè)務(wù)的需要通過sparksql自定義評估規(guī)則。
圖3-3 質(zhì)量檢查的評估規(guī)則與告警設(shè)置
數(shù)據(jù)質(zhì)量檢查動作接口配置數(shù)據(jù)質(zhì)量檢查不合格時所采取的措施，目前支持忽略，告警和阻塞三種動作。忽悠表示不做任何操作，檢查任務(wù)和ETL任務(wù)正常運(yùn)行；告警表示根據(jù)配置的告警模板通過釘釘，短信或電話的方式發(fā)出告警消息，但檢查任務(wù)和ETL任務(wù)都正常繼續(xù)運(yùn)行不受影響；阻塞表示根據(jù)配置的告警模板通過釘釘，短信或電話的方式發(fā)出告警消息，同時該ETL任務(wù)及其質(zhì)量檢查任務(wù)都終止，ETL任務(wù)視為執(zhí)行失敗，依賴該任務(wù)的后續(xù)任務(wù)不能繼續(xù)執(zhí)行，此時，需要人工干預(yù)修復(fù)數(shù)據(jù)并通過數(shù)據(jù)質(zhì)量檢查后該任務(wù)才視為執(zhí)行成功。
數(shù)據(jù)質(zhì)量告警配置接口主要配置告警的接收人，接受渠道和其他一些與告警有關(guān)的一些高級設(shè)置
數(shù)據(jù)質(zhì)量監(jiān)控項目為業(yè)務(wù)數(shù)據(jù)質(zhì)量的監(jiān)控提供了一個統(tǒng)一的平臺，使得業(yè)務(wù)數(shù)據(jù)的質(zhì)量保障工作從被動通知提升到了主動發(fā)現(xiàn)的水準(zhǔn)，并為業(yè)務(wù)本身參與數(shù)據(jù)質(zhì)量保障工作提供的參與手段。
同時，為了進(jìn)一步提高數(shù)據(jù)質(zhì)量的保障工作，數(shù)據(jù)質(zhì)量監(jiān)控項目也在不斷給增強(qiáng)和完善，后續(xù)規(guī)劃改善的幾個方面主要有：
1.持續(xù)提供更多的預(yù)定義采集指標(biāo)，預(yù)定義評估指標(biāo)
2.支持更多的自定義指標(biāo)的實現(xiàn)方式，比如支持通過python實現(xiàn)自定義指標(biāo)
3.通過利用ETL任務(wù)的依賴血緣關(guān)系，能進(jìn)一步評估數(shù)據(jù)質(zhì)量問題的影響范圍，根據(jù)影響范圍給與不同的告警等級，根據(jù)影響的業(yè)務(wù)線提前通知相關(guān)業(yè)務(wù)人員和開發(fā)人員做好相關(guān)的協(xié)調(diào)工作。
熱門文章
相關(guān)文章
極光官方微信公眾號
關(guān)注我們，即時獲取最新極光資訊
現(xiàn)在注冊，領(lǐng)取新人大禮包
