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