编辑导语：数据阐明的前期事情必然要确保无误，才气担保后期在举办数据运用和构建时不堕落；数据客栈里的数据也长短常重要的，当你拿到一个数据阐明的任务时，你可以先到数据客栈举办获取；本文作者先容了如何担保取出的数据质量问题，我们一起来看一下。

在数据阐明中，各人往往会较量重视数据清洗，数据统计和特征构建这些所谓的高级事情，而较量容易忽略数据获取这个环节。

各人大概会说，从数据客栈取数据不是一件很easy的工作吗，两行SQL语句就可以搞定。

事实上，很大都据阐明的错误都是在数据获取阶段埋下的地雷，导致后续不断的返工，这里我们只接头从数据客栈取数据的景象。

举个例子：

小飞是粮粮电商数字金融部分的新员工，老板让小飞统计下电商客户向信贷客户的转化漏斗布局。

小飞接到任务很是欢快，打开了电脑，两行SQL语句把数据抓进excel，然后开始各类花式阐明，忙得不亦乐乎。

当他把数据筹备成各类酷炫图表给老板讲述时，老板问了一句：“你这个信贷客户的人数比我们线上监控的人数少了一半以上，你是从那边拿的用户数据呀？”

小飞答复，我从credit card transaction tab里取的用户，都是有信用记录的用户。

火眼金睛的老板一眼就把问题指出来：“你这里只算了持有信用卡的用户，我们尚有消费分期和现金分期的用户都没有算在内里。”

功效由于最根基的客户数没有算对，小飞后头所有的阐明功效展示都没有意义了，只好冷静归去从头筹备数据。

这就是一个典范忽视根基的数据获取事情，在阴沟里翻船的例子。

各人刚入职时，都急于表示本身，看到一个数据能满意本身要求就立马利用，往往会写出下面这样的SQL语句：

这里transaction表的主键是txn id，一个用户大概有多条生意业务记录，所以被迫利用DISTINCT去重，暴力取出用户的列表。

基于上面的案列，我们可以知道，在做数据阐明前，前期数据获取时做的筹备事情是必不行少的，凡是我们需要做如下的工作：

相识数据客栈的表；

整理表和表之间的逻辑干系；

领略用户数据在数据客栈的落库逻辑；

接下来，我以本身地址的金融行业为例，针对上面三点具体展开。

一、相识数据客栈的表

在接到一个数据阐明的任务时，之一件时间就是找到相关数据的认真人，拿到存储数据的表和文档。

一般金融公司会有几个部分：DEV、DE、BI、DS。

作为DS的建模人员，去问谁才气得到最精确的信息呢？

这里大部门人会选择问DS内部的同事可能BI，因为都是做数据阐明，各人也较量熟悉。

但事实上，DS和BI都不是数据质量认真的人；许多时候，数据表的变换他们是不清楚的，询问他们或许率拿到的信息都不能担保权威性。

在劈头相识一个数据的时候，作为DS，其实更佳的询问工具是DE。

因为DE是认真把DEV做的出产数据库的表拉到数据客栈，并构建数仓表的认真人，他们对表的布局和数据的变换是最有讲话权的。

一般环境下，DE在处理惩罚数据时，城市把数据的原始表从出产数据库里搬一份到数据客栈里，然后构建对应的数仓表。

所以一个数据在数据客栈一般有两个记录：原始表记录和数仓表记录。

假如DE说临时还没有构建对应的数仓表，你要基于原始表做事情的话，后续是需要迭代到数仓表上去的。

二、整理表和表之间的逻辑干系

在找到DE的认真人后，需要他们提供数据表对应的文档，然后整理出这些表之间的逻辑干系，一般数仓表城市有维度表和明细表两大类，常见的套路就是维度表去关联明细表。

举个例子，信贷数据的表根基上可以归纳成用户相关的表，产物相关的表，贷款记录的表和还款记录的表。

我们可以把表的干系画成浅易版的ER图结，利便本身和团队的其他成员领略。

在这里，用户维度表，产物信息表和借贷记录表可以认为是维度表，用户信用分可以认为是用户维度扩展出来的明细信息，还款记录可以认为是借贷维度扩展出来的明细信息。

所以在写SQL取用户的时候，都是从用户的维度表出发去关联其他对应的用户层面明细表，这样的SQL逻辑是最严谨靠得住的。

回首下之前的SQL例子：

这里从借贷记录内外拿用户维度的信息就长短常不公道的一类逻辑。