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

在數據分析中，大家往往會比較重視數據清洗，數據統計和特征構建這些所謂的高級工作，而比較容易忽略數據獲取這個環節。

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

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

舉個例子，小飛是糧糧電商數字金融部門的新員工，老板讓小飛統計下電商客戶向信貸客戶的轉化漏斗結構。

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

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

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

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

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

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

大家剛入職時，都急于表現自己，看到一個數據能滿足自己要求就立馬使用，往往會寫出下面這樣的SQL語句：

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

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

1. 了解數據倉庫的表
2. 整理表和表之間的邏輯關系
3. 理解用戶數據在數據倉庫的落庫邏輯

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

01 了解數據倉庫的表

在接到一個數據分析的任務時，第一件時間就是找到相關數據的負責人，拿到存儲數據的表和文檔。

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

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

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

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

因為DE是負責把Dev做的生產數據庫的表拉到數據倉庫，并構建數倉表的負責人，他們對表的結構和數據的變動是最有發言權的。

一般情況下，DE在處理數據時，都會把數據的原始表從生產數據庫里搬一份到數據倉庫里，然后構建對應的數倉表。

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

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

02 整理表和表之間的邏輯關系

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

舉個例子，信貸數據的表基本上可以歸納成用戶相關的表，產品相關的表，貸款記錄的表和還款記錄的表。

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

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

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

回顧下之前的SQL例子：

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

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

03 理解用戶數據在數據倉庫的落庫邏輯

在熟悉了數據表里的字段和表的相互關系后，接下來就需要感受數據在業務邏輯中的流動和落盤。

一個數據老鳥在和業務溝通時候，會在腦子里帶著表結構去詢問業務的SOP。

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

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

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

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

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

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

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

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

1. 了解數據倉庫的表
2. 整理表和表之間的邏輯關系
3. 理解用戶數據在數據倉庫的落庫邏輯

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