網(wǎng)易嚴選數(shù)據(jù)質(zhì)量實踐

大家好，我是來自網(wǎng)易嚴選大數(shù)據(jù)團隊的牧天，首先感謝網(wǎng)易有數(shù)的同事們組織了此次數(shù)據(jù)治理大賽，我參賽的題目是《網(wǎng)易嚴選數(shù)據(jù)質(zhì)量實踐》。我將從三個方面給大家介紹，第一部分，數(shù)據(jù)質(zhì)量問題的危害和發(fā)生原因；第二部分，如何保障數(shù)據(jù)質(zhì)量；第三部分，網(wǎng)易嚴選數(shù)據(jù)質(zhì)量實踐。

1. 數(shù)據(jù)質(zhì)量問題的危害

數(shù)據(jù)質(zhì)量問題的危害通常體現(xiàn)在四個方面：數(shù)據(jù)的完整性、數(shù)據(jù)延遲、數(shù)據(jù)準確性、數(shù)據(jù)一致性。

數(shù)據(jù)完整性??猶記得2018年杭研和考拉一起共建數(shù)據(jù)中臺，為了更好的了解業(yè)務(wù)，我駐扎到考拉現(xiàn)場。剛?cè)滋欤敃r考拉的業(yè)務(wù)投訴數(shù)倉、說流量數(shù)據(jù)不正確，排查了半天，發(fā)現(xiàn)是流量數(shù)據(jù)丟失，原因是幾臺機器數(shù)據(jù)沒有收集，最終定為P2事故。

數(shù)據(jù)延遲??在考拉呆了幾個星期，有一天分析師和業(yè)務(wù)在群里吼，怎么數(shù)據(jù)還沒有產(chǎn)出？都十點多了。原因是一個關(guān)鍵任務(wù)失敗，報警電話給對應人沒有叫起來，導致了整個數(shù)據(jù)延遲4小時+，定級P3事故。

數(shù)據(jù)準確性??2020年下半年嚴選由于一個任務(wù)節(jié)點依賴有問題，沒有依賴到數(shù)據(jù)，導致了用戶標簽一堆老客當成了新客，造成了30w+的資損P1事故。

數(shù)據(jù)一致性??2020年 嚴選新客運營同學提出用戶當前紅包數(shù)據(jù)不準確，用戶紅包用掉了，怎么APP上還有浮層提醒，定位發(fā)現(xiàn)flink任務(wù)里面的一個task寫ES的時候假死，其他task正常。

?

數(shù)據(jù)質(zhì)量會導致資損、業(yè)務(wù)分析滯后、錯誤、算法模型不準確、數(shù)據(jù)質(zhì)疑 等等問題，我們可以分析下具體的發(fā)生原因。

2. 數(shù)據(jù)質(zhì)量問題發(fā)生的原因

原因可以總結(jié)為兩個方面：系統(tǒng)不穩(wěn)定、程序BUG

系統(tǒng)不穩(wěn)定

• 埋點服務(wù)器配置更新或掛掉導致日志收集問題；

• ?日志和數(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ì)量問題的原因，接下來我們怎么防范呢？

1. 采用規(guī)范的開發(fā)模式（解決后端和數(shù)據(jù)開發(fā)的Bug）

利用網(wǎng)易有數(shù)的中臺產(chǎn)品：數(shù)據(jù)測試中心，做到開發(fā)->測試->上線監(jiān)控流程

第一次開發(fā)的時候，探查數(shù)據(jù)形態(tài)(如枚舉數(shù)量),進行唯一性檢測,和業(yè)務(wù)確認數(shù)據(jù)量；

后期修改任務(wù)(業(yè)務(wù)改造)，通過主鍵，進行改造前后數(shù)據(jù)對比；

針對核心資產(chǎn)任務(wù)，進行code view機制，審批后提交上線；

上線后增加唯一性監(jiān)控、行數(shù)監(jiān)控、枚舉值監(jiān)控、指標值監(jiān)控等相應監(jiān)控。

2. 通過基線的機制保障數(shù)據(jù)及時性

利用網(wǎng)易有數(shù)的中臺產(chǎn)品：任務(wù)運維中心，設(shè)置2點半基線->4點半基線->7點半基線，保證核心維表和dwd表、核心dws相關(guān)dwd表、核心dm層表及時產(chǎn)出

采用預警的方式提前白天處理,減少夜晚報警(如流量當天數(shù)據(jù)監(jiān)控)；

采用值班機制、多次呼叫并升級，防止電話打不醒、任務(wù)延遲事故問題。

3. 數(shù)據(jù)質(zhì)量監(jiān)控

利用網(wǎng)易有數(shù)中臺產(chǎn)品：數(shù)據(jù)質(zhì)量中心，進行完整性、準確性、一致性監(jiān)控

【完整性】針對當天日志的IP地址數(shù)目進行監(jiān)控，如果發(fā)現(xiàn)IP減少進行白天報警規(guī)則，(避免第二天T+1任務(wù)出問題)；

【準確性】核心dwd和dim表進行行數(shù)、波動性、主鍵、枚舉值監(jiān)控保證準確性；

【準確性】核心dws指標、枚舉 進行監(jiān)控；

【一致性】針對實時和離線數(shù)據(jù)進行對比監(jiān)控(Lambda架構(gòu))? 針對不同存儲引擎數(shù)據(jù)對比監(jiān)控(如Mysql、ES、Kudu)。

保障數(shù)據(jù)質(zhì)量的輔助產(chǎn)品已經(jīng)到位了，我們是怎么實踐的呢？

1. 開發(fā)篇-超會改造

背景：

由于之前后端表設(shè)計不合理、導致新業(yè)務(wù)不能支持、業(yè)務(wù)后端需要改造。

改造過程：

業(yè)務(wù)10+表進行變更、甚至有一張表拆分成4+表的場景、業(yè)務(wù)含義、枚舉大規(guī)模變更；

我們進行了20+數(shù)據(jù)模型對比，如果有問題反饋給業(yè)務(wù)后端改造

改造結(jié)果：

幫助主站后端找到8+問題，讓其進行修復；保證了改造前后數(shù)倉數(shù)據(jù)一致性，最終成功上線切換。

2. 保障及時性

我們進行了輪班值班機制。每人3天，一個主值班人員、一個被值班人員。主要設(shè)立3條基線 2點半、4點半、7點半。

在基線我們有兩種報警：一種預警、一種破線。

掛在基線里面的任務(wù)或者鏈路里面的任務(wù)失敗，直接電話報警；

通過近14天排除掉最長運行時間和最短的運行時間進行鏈路計算時間，如果有可能破線，會進行基線破線電話報警。

通過預警我們不會進行電話報警，會采用短信、pop、郵件報警，如2點半基線在兩點的時候沒完成(緩沖半個小時)，這樣白天我們進行任務(wù)優(yōu)化。如果不長期優(yōu)化，就會惡性循環(huán)，在破線的邊緣徘徊。

如果值班人電話打不通沒處理，會給被值班人員進行呼叫。

PS: 值班很痛苦、需要大家共同保障。

3. 保障完整性、準確性、一致性

日志監(jiān)控

對于正常日志丟失，我們進行了IP數(shù)量的校驗。

針對當天流量日志進行IP數(shù)量的監(jiān)控，如大于多少臺，以及波動性監(jiān)控；當機器數(shù)量減少的時候觸發(fā)報警。這里的報警要注意的點 是當天的流量數(shù)據(jù)，非T+1（如果半夜叫起處理的話基本也延遲了），也不存在阻斷下游的概念。

如果有的日志有對應DB數(shù)據(jù)，此時還可以加上日志和db數(shù)據(jù)的對比較監(jiān)控。

業(yè)務(wù)上游變更

業(yè)務(wù)上游變更可能會涉及到字段名稱、類型，這種我們主要采用審批和變更提醒的方式進行防護，還有一種是業(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ù)進行定義了枚舉，當業(yè)務(wù)有新的類型產(chǎn)出的時候，我們可能識別不出來，那怎么能快速發(fā)現(xiàn)呢？答案如下：

重要資損模型

有時候數(shù)倉團隊會出dm模型用來進行發(fā)放福利，這個如果稍有差錯，就可能帶來大的資損事故(錢的多少決定了事故的等級)，在這塊我們會進行基礎(chǔ)的監(jiān)控和發(fā)放錢的監(jiān)控。

如果當天需要發(fā)放超過10w就會阻斷。

標簽相關(guān)監(jiān)控

在用戶標簽這塊我們會有實時+離線的dm層明細數(shù)據(jù)、匯總數(shù)據(jù)，為了保障標簽不帶來資損，這塊我們也進行了全方位的質(zhì)量監(jiān)控(這塊類似于dwd 和dws 的數(shù)據(jù)監(jiān)控)。

比如在明細數(shù)據(jù)這塊我們主要進行了唯一性和行數(shù)以及波動性的檢測。

匯總數(shù)據(jù)這塊我們除了基礎(chǔ)唯一性、行數(shù)、波動性的檢測外加了指標監(jiān)控。

在實時和離線這塊我們進行了對比監(jiān)控。

對于標簽，除了存儲hive kudu外還會存儲到ES和Hbase里面，所以我們還加了數(shù)據(jù)對比監(jiān)控。

事實證明，只有完善的監(jiān)控才能保證標簽的整體質(zhì)量。

最后總結(jié)下在數(shù)據(jù)質(zhì)量實踐過程中沉淀的方法。第一個沉淀了實時標簽開發(fā)流程規(guī)范：

第二個是沉淀了質(zhì)量監(jiān)控的方法：