網(wǎng)易嚴(yán)選數(shù)據(jù)質(zhì)量實踐
Hi，我是王知無，一個大數(shù)據(jù)領(lǐng)域的原創(chuàng)作者。? 放心關(guān)注我，獲取更多行業(yè)的一手消息。
這篇文章將從三個方面給大家介紹：
第一部分，數(shù)據(jù)質(zhì)量問題的危害和發(fā)生原因；
第二部分，如何保障數(shù)據(jù)質(zhì)量；
第三部分，網(wǎng)易嚴(yán)選數(shù)據(jù)質(zhì)量實踐。
數(shù)據(jù)質(zhì)量問題的危害和發(fā)生原因
1. 數(shù)據(jù)質(zhì)量問題的危害
數(shù)據(jù)質(zhì)量問題的危害通常體現(xiàn)在四個方面：數(shù)據(jù)的完整性、數(shù)據(jù)延遲、數(shù)據(jù)準(zhǔn)確性、數(shù)據(jù)一致性。
數(shù)據(jù)完整性??猶記得2018年杭研和考拉一起共建數(shù)據(jù)中臺，為了更好的了解業(yè)務(wù)，我駐扎到考拉現(xiàn)場。剛?cè)滋欤?dāng)時考拉的業(yè)務(wù)投訴數(shù)倉、說流量數(shù)據(jù)不正確，排查了半天，發(fā)現(xiàn)是流量數(shù)據(jù)丟失，原因是幾臺機器數(shù)據(jù)沒有收集，最終定為P2事故。
數(shù)據(jù)延遲??在考拉呆了幾個星期，有一天分析師和業(yè)務(wù)在群里吼，怎么數(shù)據(jù)還沒有產(chǎn)出？都十點多了。原因是一個關(guān)鍵任務(wù)失敗，報警電話給對應(yīng)人沒有叫起來，導(dǎo)致了整個數(shù)據(jù)延遲4小時+，定級P3事故。
數(shù)據(jù)準(zhǔn)確性??2020年下半年嚴(yán)選由于一個任務(wù)節(jié)點依賴有問題，沒有依賴到數(shù)據(jù)，導(dǎo)致了用戶標(biāo)簽一堆老客當(dāng)成了新客，造成了30w+的資損P1事故。
數(shù)據(jù)一致性??2020年 嚴(yán)選新客運營同學(xué)提出用戶當(dāng)前紅包數(shù)據(jù)不準(zhǔn)確，用戶紅包用掉了，怎么APP上還有浮層提醒，定位發(fā)現(xiàn)flink任務(wù)里面的一個task寫ES的時候假死，其他task正常。
?
數(shù)據(jù)質(zhì)量會導(dǎo)致資損、業(yè)務(wù)分析滯后、錯誤、算法模型不準(zhǔn)確、數(shù)據(jù)質(zhì)疑 等等問題，我們可以分析下具體的發(fā)生原因。
2. 數(shù)據(jù)質(zhì)量問題發(fā)生的原因
原因可以總結(jié)為兩個方面：系統(tǒng)不穩(wěn)定、程序BUG
系統(tǒng)不穩(wěn)定
埋點服務(wù)器配置更新或掛掉導(dǎo)致日志收集問題；
?日志和數(shù)據(jù)庫數(shù)據(jù)同步問題；
?離線計算平臺任務(wù)突然變慢卡死或失敗問題；
?實時計算平臺任務(wù)Task卡死；
?KAFKA壓力大數(shù)據(jù)延遲。
程序bug
后端程序有Bug原始數(shù)據(jù)有問題；
數(shù)據(jù)開發(fā)程序有Bug；
實時任務(wù)和離線任務(wù)邏輯不一致；
上游數(shù)據(jù)變更未通知下游。
知道了發(fā)生數(shù)據(jù)質(zhì)量問題的原因，接下來我們怎么防范呢？
如何保障數(shù)據(jù)質(zhì)量
1. 采用規(guī)范的開發(fā)模式（解決后端和數(shù)據(jù)開發(fā)的Bug）
利用網(wǎng)易有數(shù)的中臺產(chǎn)品：數(shù)據(jù)測試中心，做到開發(fā)->測試->上線監(jiān)控流程
第一次開發(fā)的時候，探查數(shù)據(jù)形態(tài)(如枚舉數(shù)量),進(jìn)行唯一性檢測,和業(yè)務(wù)確認(rèn)數(shù)據(jù)量；
后期修改任務(wù)(業(yè)務(wù)改造)，通過主鍵，進(jìn)行改造前后數(shù)據(jù)對比；
針對核心資產(chǎn)任務(wù)，進(jìn)行code view機制，審批后提交上線；
上線后增加唯一性監(jiān)控、行數(shù)監(jiān)控、枚舉值監(jiān)控、指標(biāo)值監(jiān)控等相應(yīng)監(jiān)控。
2. 通過基線的機制保障數(shù)據(jù)及時性
利用網(wǎng)易有數(shù)的中臺產(chǎn)品：任務(wù)運維中心，設(shè)置2點半基線->4點半基線->7點半基線，保證核心維表和dwd表、核心dws相關(guān)dwd表、核心dm層表及時產(chǎn)出
采用預(yù)警的方式提前白天處理,減少夜晚報警(如流量當(dāng)天數(shù)據(jù)監(jiān)控)；
采用值班機制、多次呼叫并升級，防止電話打不醒、任務(wù)延遲事故問題。
3. 數(shù)據(jù)質(zhì)量監(jiān)控
利用網(wǎng)易有數(shù)中臺產(chǎn)品：數(shù)據(jù)質(zhì)量中心，進(jìn)行完整性、準(zhǔn)確性、一致性監(jiān)控
【完整性】針對當(dāng)天日志的IP地址數(shù)目進(jìn)行監(jiān)控，如果發(fā)現(xiàn)IP減少進(jìn)行白天報警規(guī)則，(避免第二天T+1任務(wù)出問題)；
【準(zhǔn)確性】核心dwd和dim表進(jìn)行行數(shù)、波動性、主鍵、枚舉值監(jiān)控保證準(zhǔn)確性；
【準(zhǔn)確性】核心dws指標(biāo)、枚舉 進(jìn)行監(jiān)控；
【一致性】針對實時和離線數(shù)據(jù)進(jìn)行對比監(jiān)控(Lambda架構(gòu))? 針對不同存儲引擎數(shù)據(jù)對比監(jiān)控(如Mysql、ES、Kudu)。
保障數(shù)據(jù)質(zhì)量的輔助產(chǎn)品已經(jīng)到位了，我們是怎么實踐的呢？
數(shù)據(jù)質(zhì)量實踐
1. 開發(fā)篇-超會改造
背景：
由于之前后端表設(shè)計不合理、導(dǎo)致新業(yè)務(wù)不能支持、業(yè)務(wù)后端需要改造。
改造過程：
業(yè)務(wù)10+表進(jìn)行變更、甚至有一張表拆分成4+表的場景、業(yè)務(wù)含義、枚舉大規(guī)模變更；
我們進(jìn)行了20+數(shù)據(jù)模型對比，如果有問題反饋給業(yè)務(wù)后端改造
改造結(jié)果：
幫助主站后端找到8+問題，讓其進(jìn)行修復(fù)；保證了改造前后數(shù)倉數(shù)據(jù)一致性，最終成功上線切換。
2. 保障及時性
我們進(jìn)行了輪班值班機制。每人3天，一個主值班人員、一個被值班人員。主要設(shè)立3條基線 2點半、4點半、7點半。
在基線我們有兩種報警：一種預(yù)警、一種破線。
掛在基線里面的任務(wù)或者鏈路里面的任務(wù)失敗，直接電話報警；
通過近14天排除掉最長運行時間和最短的運行時間進(jìn)行鏈路計算時間，如果有可能破線，會進(jìn)行基線破線電話報警。
通過預(yù)警我們不會進(jìn)行電話報警，會采用短信、pop、郵件報警，如2點半基線在兩點的時候沒完成(緩沖半個小時)，這樣白天我們進(jìn)行任務(wù)優(yōu)化。如果不長期優(yōu)化，就會惡性循環(huán)，在破線的邊緣徘徊。
如果值班人電話打不通沒處理，會給被值班人員進(jìn)行呼叫。
PS: 值班很痛苦、需要大家共同保障。
3. 保障完整性、準(zhǔn)確性、一致性
日志監(jiān)控
對于正常日志丟失，我們進(jìn)行了IP數(shù)量的校驗。
針對當(dāng)天流量日志進(jìn)行IP數(shù)量的監(jiān)控，如大于多少臺，以及波動性監(jiān)控；當(dāng)機器數(shù)量減少的時候觸發(fā)報警。這里的報警要注意的點 是當(dāng)天的流量數(shù)據(jù)，非T+1（如果半夜叫起處理的話基本也延遲了），也不存在阻斷下游的概念。
如果有的日志有對應(yīng)DB數(shù)據(jù)，此時還可以加上日志和db數(shù)據(jù)的對比較監(jiān)控。
業(yè)務(wù)上游變更
業(yè)務(wù)上游變更可能會涉及到字段名稱、類型，這種我們主要采用審批和變更提醒的方式進(jìn)行防護(hù)，還有一種是業(yè)務(wù)的邏輯的變更。
case?when?a.topic?=?"getCartCoupon"?then?1when?a.topic?=??"getCoupon"?and?a.sub_welfare_type?not?in?(6)?then?2?when?a.topic?=?"pushSms"?then?3when?a.topic?=?"getCoupon"?and?a.sub_welfare_type?in?(6)?then?6when?a.topic?=?"openCard"?then?6else 0 end as welfare_type,
數(shù)倉針對業(yè)務(wù)進(jìn)行定義了枚舉，當(dāng)業(yè)務(wù)有新的類型產(chǎn)出的時候，我們可能識別不出來，那怎么能快速發(fā)現(xiàn)呢？答案如下：
重要資損模型
有時候數(shù)倉團隊會出dm模型用來進(jìn)行發(fā)放福利，這個如果稍有差錯，就可能帶來大的資損事故(錢的多少決定了事故的等級)，在這塊我們會進(jìn)行基礎(chǔ)的監(jiān)控和發(fā)放錢的監(jiān)控。
如果當(dāng)天需要發(fā)放超過10w就會阻斷。
標(biāo)簽相關(guān)監(jiān)控
在用戶標(biāo)簽這塊我們會有實時+離線的dm層明細(xì)數(shù)據(jù)、匯總數(shù)據(jù)，為了保障標(biāo)簽不帶來資損，這塊我們也進(jìn)行了全方位的質(zhì)量監(jiān)控(這塊類似于dwd 和dws 的數(shù)據(jù)監(jiān)控)。
比如在明細(xì)數(shù)據(jù)這塊我們主要進(jìn)行了唯一性和行數(shù)以及波動性的檢測。
匯總數(shù)據(jù)這塊我們除了基礎(chǔ)唯一性、行數(shù)、波動性的檢測外加了指標(biāo)監(jiān)控。
在實時和離線這塊我們進(jìn)行了對比監(jiān)控。
對于標(biāo)簽，除了存儲hive kudu外還會存儲到ES和Hbase里面，所以我們還加了數(shù)據(jù)對比監(jiān)控。
事實證明，只有完善的監(jiān)控才能保證標(biāo)簽的整體質(zhì)量。
總結(jié)
最后總結(jié)下在數(shù)據(jù)質(zhì)量實踐過程中沉淀的方法。第一個沉淀了實時標(biāo)簽開發(fā)流程規(guī)范：
第二個是沉淀了質(zhì)量監(jiān)控的方法：
以上是我今天介紹的內(nèi)容，希望能給大家?guī)硪恍┙梃b，謝謝。
如果這個文章對你有幫助，不要忘記?「在看」?「點贊」?「收藏」?三連啊喂！
