編輯導(dǎo)語：數(shù)據(jù)分析的前期工作一定要確保無誤，才能保證后期在進(jìn)行數(shù)據(jù)運用和構(gòu)建時不出錯；數(shù)據(jù)倉庫里的數(shù)據(jù)也是非常重要的，當(dāng)你拿到一個數(shù)據(jù)分析的任務(wù)時，你可以先到數(shù)據(jù)倉庫進(jìn)行獲??；本文作者介紹了如何保證取出的數(shù)據(jù)質(zhì)量問題，我們一起來看一下。

在數(shù)據(jù)分析中，大家往往會比較重視數(shù)據(jù)清洗，數(shù)據(jù)統(tǒng)計和特征構(gòu)建這些所謂的高級工作，而比較容易忽略數(shù)據(jù)獲取這個環(huán)節(jié)。

大家可能會說，從數(shù)據(jù)倉庫取數(shù)據(jù)不是一件很easy的事情嗎，兩行SQL語句就可以搞定。

事實上，很多數(shù)據(jù)分析的錯誤都是在數(shù)據(jù)獲取階段埋下的地雷，導(dǎo)致后續(xù)不停的返工，這里我們只討論從數(shù)據(jù)倉庫取數(shù)據(jù)的情形。

舉個例子：

小飛是糧糧電商數(shù)字金融部門的新員工，老板讓小飛統(tǒng)計下電商客戶向信貸客戶的轉(zhuǎn)化漏斗結(jié)構(gòu)。

小飛接到任務(wù)非常興奮，打開了電腦，兩行SQL語句把數(shù)據(jù)抓進(jìn)excel，然后開始各種花式分析，忙得不亦樂乎。

當(dāng)他把數(shù)據(jù)準(zhǔn)備成各種酷炫圖表給老板匯報時，老板問了一句：“你這個信貸客戶的人數(shù)比我們線上監(jiān)控的人數(shù)少了一半以上，你是從哪里拿的用戶數(shù)據(jù)呀？”

小飛回答，我從credit card transaction tab里取的用戶，都是有信用記錄的用戶。

火眼金睛的老板一眼就把問題指出來：“你這里只算了持有信用卡的用戶，我們還有消費分期和現(xiàn)金分期的用戶都沒有算在里面?！?/p>

結(jié)果由于最基本的客戶數(shù)沒有算對，小飛后面所有的分析結(jié)果展示都沒有意義了，只好默默回去重新準(zhǔn)備數(shù)據(jù)。

這就是一個典型忽視基本的數(shù)據(jù)獲取工作，在陰溝里翻船的例子。

大家剛?cè)肼殨r，都急于表現(xiàn)自己，看到一個數(shù)據(jù)能滿足自己要求就立馬使用，往往會寫出下面這樣的SQL語句：

這里transaction表的主鍵是txn id，一個用戶可能有多條交易記錄，所以被迫使用DISTINCT去重，暴力取出用戶的列表。

基于上面的案列，我們可以知道，在做數(shù)據(jù)分析前，前期數(shù)據(jù)獲取時做的準(zhǔn)備工作是必不可少的，通常我們需要做如下的事情：

1. 了解數(shù)據(jù)倉庫的表；
2. 整理表和表之間的邏輯關(guān)系；
3. 理解用戶數(shù)據(jù)在數(shù)據(jù)倉庫的落庫邏輯；

接下來，我以自己所在的金融行業(yè)為例，針對上面三點詳細(xì)展開。

一、了解數(shù)據(jù)倉庫的表

在接到一個數(shù)據(jù)分析的任務(wù)時，第一件時間就是找到相關(guān)數(shù)據(jù)的負(fù)責(zé)人，拿到存儲數(shù)據(jù)的表和文檔。

一般金融公司會有幾個部門：DEV、DE、BI、DS。

作為DS的建模人員，去問誰才能獲得最準(zhǔn)確的信息呢？

這里大部分人會選擇問DS內(nèi)部的同事或者BI，因為都是做數(shù)據(jù)分析，大家也比較熟悉。

但事實上，DS和BI都不是數(shù)據(jù)質(zhì)量負(fù)責(zé)的人；很多時候，數(shù)據(jù)表的變動他們是不清楚的，詢問他們大概率拿到的信息都不能保證權(quán)威性。

在初步了解一個數(shù)據(jù)的時候，作為DS，其實最佳的詢問對象是DE。

因為DE是負(fù)責(zé)把DEV做的生產(chǎn)數(shù)據(jù)庫的表拉到數(shù)據(jù)倉庫，并構(gòu)建數(shù)倉表的負(fù)責(zé)人，他們對表的結(jié)構(gòu)和數(shù)據(jù)的變動是最有發(fā)言權(quán)的。

一般情況下，DE在處理數(shù)據(jù)時，都會把數(shù)據(jù)的原始表從生產(chǎn)數(shù)據(jù)庫里搬一份到數(shù)據(jù)倉庫里，然后構(gòu)建對應(yīng)的數(shù)倉表。

所以一個數(shù)據(jù)在數(shù)據(jù)倉庫一般有兩個記錄：原始表記錄和數(shù)倉表記錄。

如果DE說暫時還沒有構(gòu)建對應(yīng)的數(shù)倉表，你要基于原始表做工作的話，后續(xù)是需要迭代到數(shù)倉表上去的。

二、整理表和表之間的邏輯關(guān)系

在找到DE的負(fù)責(zé)人后，需要他們提供數(shù)據(jù)表對應(yīng)的文檔，然后整理出這些表之間的邏輯關(guān)系，一般數(shù)倉表都會有維度表和明細(xì)表兩大類，常見的套路就是維度表去關(guān)聯(lián)明細(xì)表。

舉個例子，信貸數(shù)據(jù)的表基本上可以歸納成用戶相關(guān)的表，產(chǎn)品相關(guān)的表，貸款記錄的表和還款記錄的表。

我們可以把表的關(guān)系畫成簡易版的ER圖結(jié)，方便自己和團隊的其他成員理解。

在這里，用戶維度表，產(chǎn)品信息表和借貸記錄表可以認(rèn)為是維度表，用戶信用分可以認(rèn)為是用戶維度擴展出來的明細(xì)信息，還款記錄可以認(rèn)為是借貸維度擴展出來的明細(xì)信息。

所以在寫SQL取用戶的時候，都是從用戶的維度表出發(fā)去關(guān)聯(lián)其他對應(yīng)的用戶層面明細(xì)表，這樣的SQL邏輯是最嚴(yán)謹(jǐn)可靠的。

回顧下之前的SQL例子：

這里從借貸記錄表里拿用戶維度的信息就是非常不合理的一類邏輯。

如果我們是想找有信貸記錄的用戶列表的話，應(yīng)該是用戶維度表去關(guān)聯(lián)借貸記錄表，并在篩選條件中設(shè)置只挑選有信貸記錄的用戶，這樣的SQL才是嚴(yán)謹(jǐn)可靠的。

三、理解用戶數(shù)據(jù)在數(shù)據(jù)倉庫的落庫邏輯

在熟悉了數(shù)據(jù)表里的字段和表的相互關(guān)系后，接下來就需要感受數(shù)據(jù)在業(yè)務(wù)邏輯中的流動和落盤。

一個數(shù)據(jù)老鳥在和業(yè)務(wù)溝通時候，會在腦子里帶著表結(jié)構(gòu)去詢問業(yè)務(wù)的SOP。

當(dāng)業(yè)務(wù)說用戶注冊賬戶，腦子里就要想著在用戶維度表增加一行，用戶注冊的相關(guān)信息會被記錄在這個維度表里。

然后用戶填寫相關(guān)的表格提交信息，就會知道我們收集的用戶信息會按SOP流程在規(guī)定的時間落盤在用戶信息表中。

其中哪些信息是必須非空的，哪些是可以有缺失的，缺失的時候數(shù)據(jù)表里是None值還是默認(rèn)值。

如果用戶更新這些信息，數(shù)據(jù)表是新增一個記錄還是覆蓋已有的記錄？會對我們后續(xù)建模有無影響？是否有未來信息泄露的可能？用戶在從下拉列表中選擇信息的時候，下拉列表是固定不變的還是會改變的？會引起數(shù)據(jù)不一致嘛？后續(xù)需要對數(shù)據(jù)做清洗和歸一化嘛？

只有當(dāng)你回顧一個業(yè)務(wù)流程，用戶的每個數(shù)據(jù)從app流轉(zhuǎn)到數(shù)據(jù)表的邏輯都非常清晰后，才算做完了數(shù)據(jù)獲取的準(zhǔn)備工作。

說到這里，你可能就不會覺得數(shù)據(jù)獲取是一件很簡單的事情，而是需要很多耐心和經(jīng)驗，很考驗一個人溝通能力和信息歸納整理能力的一件事情。

總結(jié)一下，在拿到一個數(shù)據(jù)分析任務(wù)的時候，首先要做好數(shù)據(jù)獲取的準(zhǔn)備工作，分成三方面：

1. 了解數(shù)據(jù)倉庫的表；
2. 整理表和表之間的邏輯關(guān)系；
3. 理解用戶數(shù)據(jù)在數(shù)據(jù)倉庫的落庫邏輯；

這些工作會能極大地加深你對數(shù)據(jù)的理解，能在項目的早期把數(shù)據(jù)的坑點都找出來，能讓你迅速的融入到業(yè)務(wù)中，做一個既有分析建模技能又有業(yè)務(wù)實戰(zhàn)能力的數(shù)據(jù)科學(xué)家。

本文由 @FAL金科應(yīng)用研院 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 unsplash，基于 CC0 協(xié)議