企業(yè)大數(shù)據(jù)質(zhì)量管理的一些經(jīng)驗(yàn) - 知乎專欄 https://zhuanlan.zhihu.com/p/25309728

將各產(chǎn)品線的用戶標(biāo)識(shí)統(tǒng)一，然后統(tǒng)一對(duì)用戶行為log進(jìn)行統(tǒng)一定義，所有的log在錄入DT平臺(tái)時(shí)，均需要按照統(tǒng)一的schema來錄入。
除了客戶端的統(tǒng)一定義之外，數(shù)據(jù)平臺(tái)方對(duì)數(shù)據(jù)表的schema設(shè)計(jì)也很重要，這直接決定了數(shù)據(jù)錄入之后的數(shù)據(jù)質(zhì)量。

//
因?yàn)榘俣葍?nèi)部有很好的wiki系統(tǒng)，這套系統(tǒng)設(shè)計(jì)完成之后，所有l(wèi)og的定義、User Data Warehouse中的fact tables和dimension tables都在wiki上有明確的記錄，方便后來者對(duì)知識(shí)的繼承。
后來系統(tǒng)上線之后，我們通過對(duì)數(shù)據(jù)的diff工作，將數(shù)據(jù)處理環(huán)節(jié)中可能導(dǎo)致數(shù)據(jù)異常的問題全部排查了一遍（這些大部分都是一次性工作），最終保證了最后分析平臺(tái)上線時(shí)數(shù)據(jù)的質(zhì)量。

//
總結(jié)起來就只有幾點(diǎn)：
– 定義明確
– 策略清晰
– 規(guī)范統(tǒng)一
– 知識(shí)繼承
– 誤差可解釋
當(dāng)然，不論前期做得多么好，數(shù)據(jù)diff的工作要認(rèn)真做，這將是最佳的全盤檢查的機(jī)會(huì)。

這幾年一直在互聯(lián)網(wǎng)公司從事數(shù)據(jù)分析數(shù)據(jù)產(chǎn)品相關(guān)的工作，因此主要從過去工作中碰到的數(shù)據(jù)質(zhì)量的問題中引申出來的一些想法和執(zhí)行情況。

Google最早建立了網(wǎng)站的數(shù)據(jù)質(zhì)量標(biāo)準(zhǔn)

最早入門做數(shù)據(jù)分析的時(shí)候，我主要依賴google analytics來做網(wǎng)站的流量分析。這個(gè)時(shí)期是沒有數(shù)據(jù)質(zhì)量問題的——因?yàn)槿渴怯玫膅oogle的標(biāo)準(zhǔn)和定義，我要做的就是學(xué)習(xí)它的規(guī)則。
移動(dòng)產(chǎn)品的數(shù)據(jù)質(zhì)量須從客戶端開始，且越早越好
我第一次遇到數(shù)據(jù)質(zhì)量問題，是在百度做一個(gè)行業(yè)分析數(shù)據(jù)產(chǎn)品的時(shí)候。這個(gè)時(shí)期的數(shù)據(jù)質(zhì)量的問題主要來自于移動(dòng)設(shè)備數(shù)據(jù)上傳的不穩(wěn)定性。當(dāng)時(shí)的產(chǎn)品需要應(yīng)用調(diào)用系統(tǒng)的某些接口來獲取數(shù)據(jù)來進(jìn)行統(tǒng)計(jì)，數(shù)據(jù)在采集和上傳的時(shí)候會(huì)有一部分?jǐn)?shù)據(jù)丟失，導(dǎo)致部分?jǐn)?shù)據(jù)記錄不全或者紀(jì)錄丟失的情況。
從這里我得到的經(jīng)驗(yàn)就是在做移動(dòng)端相關(guān)產(chǎn)品的數(shù)據(jù)分析和產(chǎn)品時(shí)，第一要?jiǎng)?wù)就是保證客戶端采集和上傳數(shù)據(jù)的穩(wěn)定性和一致性——確保不同版本客戶端發(fā)布的時(shí)候原始數(shù)據(jù)采集的口徑一致，以及在復(fù)雜網(wǎng)絡(luò)狀況以及用戶行為情況下數(shù)據(jù)上傳策略合理。
當(dāng)然有些時(shí)候我們不可能保證數(shù)據(jù)完全的正確。畢竟數(shù)據(jù)上傳的時(shí)候用戶的移動(dòng)網(wǎng)絡(luò)斷掉，以及跨天行為統(tǒng)計(jì)所產(chǎn)生的誤差是不可避免的。移動(dòng)客戶端的數(shù)據(jù)總會(huì)有那么百分之零點(diǎn)幾的差異，但是只要在可控的范圍內(nèi)，就可以保證后續(xù)生產(chǎn)數(shù)據(jù)的質(zhì)量。
多產(chǎn)品線最重要的是用戶標(biāo)識(shí)的一致
2012年的時(shí)候有幸參與到百度公司級(jí)別的一次大數(shù)據(jù)平臺(tái)建設(shè)浪潮中。當(dāng)時(shí)基礎(chǔ)架構(gòu)部與移動(dòng)云事業(yè)部聯(lián)合開展了一個(gè)針對(duì)移動(dòng)云所有產(chǎn)品線的大數(shù)據(jù)平臺(tái)落地計(jì)劃。
因?yàn)闅v史原因，當(dāng)時(shí)移動(dòng)云的數(shù)據(jù)治理以及數(shù)據(jù)應(yīng)用的狀況不太理想。各個(gè)產(chǎn)品線各自為戰(zhàn)，自己打自己的產(chǎn)品log，然后自己從log中取出自己想要的計(jì)算字段算出結(jié)果來分析產(chǎn)品。這種方式不僅效率低下，而且同一個(gè)事業(yè)部的不同產(chǎn)品數(shù)據(jù)不能打通分析，更妄談同其他事業(yè)部甚至PC端的搜索數(shù)據(jù)打通了。

解鈴還需系鈴人

當(dāng)時(shí)最需要做的事是將各產(chǎn)品線的用戶標(biāo)識(shí)統(tǒng)一，然后統(tǒng)一對(duì)用戶行為log進(jìn)行統(tǒng)一定義，所有的log在錄入DT平臺(tái)時(shí)，均需要按照統(tǒng)一的schema來錄入。這樣做會(huì)導(dǎo)致很多的歷史數(shù)據(jù)丟失，但是讓后續(xù)所有的產(chǎn)品線依賴公司統(tǒng)一大平臺(tái)資源（比如后來做推廣時(shí)，整體可以用同一套推廣系統(tǒng)和質(zhì)量管控系統(tǒng)等）。
這個(gè)過程中，以什么為規(guī)范來做統(tǒng)一的定義是一個(gè)比較麻煩的事情，如果重新定義一套，會(huì)導(dǎo)致數(shù)據(jù)沒有延續(xù)性，對(duì)自身內(nèi)傷嚴(yán)重。所以當(dāng)時(shí)產(chǎn)品部門內(nèi)部商定了以搜索產(chǎn)品為核心來制定整體標(biāo)準(zhǔn)，簡(jiǎn)單來說就是所有的產(chǎn)品采用搜索產(chǎn)品歷史沿襲的log定義規(guī)則來進(jìn)行修改。最終達(dá)成客戶端日志的統(tǒng)一性。
除了客戶端的統(tǒng)一定義之外，數(shù)據(jù)平臺(tái)方對(duì)數(shù)據(jù)表的schema設(shè)計(jì)也很重要，這直接決定了數(shù)據(jù)錄入之后的數(shù)據(jù)質(zhì)量。
因?yàn)榘俣葍?nèi)部有很好的wiki系統(tǒng)，這套系統(tǒng)設(shè)計(jì)完成之后，所有l(wèi)og的定義、User Data Warehouse中的fact tables和dimension tables都在wiki上有明確的記錄，方便后來者對(duì)知識(shí)的繼承。
后來系統(tǒng)上線之后，我們通過對(duì)數(shù)據(jù)的diff工作，將數(shù)據(jù)處理環(huán)節(jié)中可能導(dǎo)致數(shù)據(jù)異常的問題全部排查了一遍（這些大部分都是一次性工作），最終保證了最后分析平臺(tái)上線時(shí)數(shù)據(jù)的質(zhì)量。

更多的問題來自對(duì)數(shù)據(jù)的定義

繼續(xù)下去的經(jīng)歷中，基本上客戶端的數(shù)據(jù)質(zhì)量問題都比較容易的解決掉了。反而是業(yè)務(wù)需求端定義不明確的問題一而再的發(fā)生——特別是業(yè)務(wù)流程比較復(fù)雜的時(shí)候。比如當(dāng)時(shí)在滴滴打車有這么一個(gè)指標(biāo)：訂單完成數(shù)。這里有個(gè)問題，訂單是結(jié)束計(jì)算完成還是支付算完成？然后你就發(fā)現(xiàn)：
– 如果按照訂單結(jié)束，不論支付來看，那么一個(gè)跨越12點(diǎn)的訂單會(huì)在第一天計(jì)算成一個(gè)未完成訂單，第二天多一個(gè)完成訂單。數(shù)據(jù)回溯可以解決這個(gè)問題，但是你會(huì)發(fā)現(xiàn)當(dāng)你回頭看歷史數(shù)據(jù)時(shí)，數(shù)字總是在變的。
– 如果按照訂單支付結(jié)束來計(jì)算——數(shù)據(jù)回溯都解決不了跨天的問題了，因?yàn)楹脦滋熘笤僦Ц兜挠脩舯缺冉允恰?br> 這種情況在周五以及節(jié)假日前出現(xiàn)的情況尤其多，導(dǎo)致那時(shí)候的數(shù)據(jù)基本不可用，而且很多策略出現(xiàn)問題——當(dāng)時(shí)有個(gè)政策是對(duì)一天拉滿N單的司機(jī)進(jìn)行獎(jiǎng)勵(lì)，那么到了凌晨的時(shí)候，有些忙著完成任務(wù)的司機(jī)會(huì)拒絕接受長(zhǎng)途訂單，然后用戶就不開心了。
之后我們就將這一個(gè)指標(biāo)拆解成訂單完成數(shù)和訂單支付支付完成數(shù)，這兩個(gè)數(shù)據(jù)不進(jìn)行數(shù)據(jù)回溯，只是按照訂單最終狀態(tài)發(fā)生的時(shí)候來計(jì)算。但是在計(jì)算訂單完成率和訂單支付成功率時(shí)，我就比較煩惱了，然后這個(gè)問題直到我最終離職也沒有比較好的解決辦法（求高手支招）。

絮絮叨叨說了這么多，其實(shí)總結(jié)起來就只有幾點(diǎn)：
– 定義明確
– 策略清晰
– 規(guī)范統(tǒng)一
– 知識(shí)繼承
– 誤差可解釋
當(dāng)然，不論前期做得多么好，數(shù)據(jù)diff的工作要認(rèn)真做，這將是最佳的全盤檢查的機(jī)會(huì)。

歡迎大家掃碼關(guān)注數(shù)據(jù)產(chǎn)品經(jīng)理公眾號(hào)，如想加入《數(shù)據(jù)產(chǎn)品經(jīng)理會(huì)》群，請(qǐng)加 劉洋 微信：liuyangfjnu 。