在做數(shù)據(jù)分析之前，數(shù)據(jù)獲取環(huán)節(jié)常常會被人忽略，但這也是關(guān)鍵的一步。本文基于相關(guān)案例，總結(jié)了數(shù)據(jù)獲取的三點準備工作，希望對你有所啟發(fā)。

在數(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ù)獲取階段埋下的地雷，導致后續(xù)不停的返工。這里我們只討論從數(shù)據(jù)倉庫取數(shù)據(jù)的情形。

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

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

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

小飛回答，我從credit_card_transaction_tab里取的用戶，都是有信用記錄的用戶。

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

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

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

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

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

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

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

接下來，我針對上面三點詳細展開。

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

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

一般金融公司會有幾個部門：Dev, DE, BI, DS。作為DS的建模人員，去問誰才能獲得最準確的信息呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

回顧下之前的SQL例子：

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

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

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

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

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

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

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

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

如果用戶更新這些信息，數(shù)據(jù)表是新增一個記錄還是覆蓋已有的記錄？會對我們后續(xù)建模有無影響？是否有未來信息泄露的可能？

用戶在從下拉列表中選擇信息的時候，下拉列表是固定不變的還是會改變的？會引起數(shù)據(jù)不一致嘛？后續(xù)需要對數(shù)據(jù)做清洗和歸一化嘛？

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

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

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

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

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