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

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

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

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

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

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

小飛回答，我從credit_card_transaction_tab裡取的使用者，都是有信用記錄的使用者。

火眼睛睛的老闆一眼就把問題指出來：“你這裡只算了持有信用卡的使用者，我們還有消費分期和現金分期的使用者都沒有算在裡面。”

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

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

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

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

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

瞭解資料倉庫的表

整理表和表之間的邏輯關係

理解使用者資料在資料倉庫的落庫邏輯

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

關注“金科應用研院”，回覆“ZH”領取風控資料合集

1.瞭解資料倉庫的表

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

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

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

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

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

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

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

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

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

2.整理表和表之間的邏輯關係

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

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

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

在這裡，使用者維度表，產品資訊表和借貸記錄表可以認為是維度表，使用者信用分可以認為是使用者維度擴展出來的明細資訊，還款記錄可以認為是借貸維度擴展出來的明細資訊。

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

回顧下之前的SQL例子：

這裡從借貸記錄表裡拿使用者維度的資訊就是非常不合理的一類邏輯。

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

3、理解使用者資料在資料倉庫的落庫邏輯

在熟悉了資料表裡的欄位和表的相互關係後，接下來就需要感受資料在業務邏輯中的流動和落盤。

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

當業務說使用者註冊賬戶，腦子裡就要想著在使用者維度表增加一行，使用者註冊的相關資訊會被記錄在這個維度表裡。

然後使用者填寫相關的表格提交資訊，就會知道我們收集的使用者資訊會按SOP流程在規定的時間落盤在使用者資訊表中。

其中哪些資訊是必須非空的，哪些是可以有缺失的，缺失的時候資料表裡是None值還是預設值。

如果使用者更新這些資訊，資料表是新增一個記錄還是覆蓋已有的記錄？會對我們後續建模有無影響？是否有未來資訊洩露的可能？

使用者在從下拉列表中選擇資訊的時候，下拉列表是固定不變的還是會改變的？會引起資料不一致嘛？後續需要對資料做清洗和歸一化嘛？

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

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

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

瞭解資料倉庫的表

整理表和表之間的邏輯關係

理解使用者資料在資料倉庫的落庫邏輯

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

關注“金科應用研院”，回覆“ZH”領取風控資料合集