如何保证从数据仓库取出的数据质量?

0 评论 6147 浏览 6 收藏 10 分钟

编辑导语:数据分析的前期工作一定要确保无误,才能保证后期在进行数据运用和构建时不出错;数据仓库里的数据也是非常重要的,当你拿到一个数据分析的任务时,你可以先到数据仓库进行获取;本文作者介绍了如何保证取出的数据质量问题,我们一起来看一下。

在数据分析中,大家往往会比较重视数据清洗,数据统计和特征构建这些所谓的高级工作,而比较容易忽略数据获取这个环节。

大家可能会说,从数据仓库取数据不是一件很easy的事情吗,两行SQL语句就可以搞定。

事实上,很多数据分析的错误都是在数据获取阶段埋下的地雷,导致后续不停的返工,这里我们只讨论从数据仓库取数据的情形。

举个例子:

小飞是粮粮电商数字金融部门的新员工,老板让小飞统计下电商客户向信贷客户的转化漏斗结构。

小飞接到任务非常兴奋,打开了电脑,两行SQL语句把数据抓进excel,然后开始各种花式分析,忙得不亦乐乎。

当他把数据准备成各种酷炫图表给老板汇报时,老板问了一句:“你这个信贷客户的人数比我们线上监控的人数少了一半以上,你是从哪里拿的用户数据呀?”

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

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

结果由于最基本的客户数没有算对,小飞后面所有的分析结果展示都没有意义了,只好默默回去重新准备数据。

这就是一个典型忽视基本的数据获取工作,在阴沟里翻船的例子。

大家刚入职时,都急于表现自己,看到一个数据能满足自己要求就立马使用,往往会写出下面这样的SQL语句:

这里transaction表的主键是txn id,一个用户可能有多条交易记录,所以被迫使用DISTINCT去重,暴力取出用户的列表。

基于上面的案列,我们可以知道,在做数据分析前,前期数据获取时做的准备工作是必不可少的,通常我们需要做如下的事情:

  1. 了解数据仓库的表;
  2. 整理表和表之间的逻辑关系;
  3. 理解用户数据在数据仓库的落库逻辑;

接下来,我以自己所在的金融行业为例,针对上面三点详细展开。

一、了解数据仓库的表

在接到一个数据分析的任务时,第一件时间就是找到相关数据的负责人,拿到存储数据的表和文档。

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

作为DS的建模人员,去问谁才能获得最准确的信息呢?

这里大部分人会选择问DS内部的同事或者BI,因为都是做数据分析,大家也比较熟悉。

但事实上,DS和BI都不是数据质量负责的人;很多时候,数据表的变动他们是不清楚的,询问他们大概率拿到的信息都不能保证权威性。

在初步了解一个数据的时候,作为DS,其实最佳的询问对象是DE。

因为DE是负责把DEV做的生产数据库的表拉到数据仓库,并构建数仓表的负责人,他们对表的结构和数据的变动是最有发言权的。

一般情况下,DE在处理数据时,都会把数据的原始表从生产数据库里搬一份到数据仓库里,然后构建对应的数仓表。

所以一个数据在数据仓库一般有两个记录:原始表记录和数仓表记录。

如果DE说暂时还没有构建对应的数仓表,你要基于原始表做工作的话,后续是需要迭代到数仓表上去的。

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

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

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

我们可以把表的关系画成简易版的ER图结,方便自己和团队的其他成员理解。

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

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

回顾下之前的SQL例子:

这里从借贷记录表里拿用户维度的信息就是非常不合理的一类逻辑。

如果我们是想找有信贷记录的用户列表的话,应该是用户维度表去关联借贷记录表,并在筛选条件中设置只挑选有信贷记录的用户,这样的SQL才是严谨可靠的。

三、理解用户数据在数据仓库的落库逻辑

在熟悉了数据表里的字段和表的相互关系后,接下来就需要感受数据在业务逻辑中的流动和落盘。

一个数据老鸟在和业务沟通时候,会在脑子里带着表结构去询问业务的SOP。

当业务说用户注册账户,脑子里就要想着在用户维度表增加一行,用户注册的相关信息会被记录在这个维度表里。

然后用户填写相关的表格提交信息,就会知道我们收集的用户信息会按SOP流程在规定的时间落盘在用户信息表中。

其中哪些信息是必须非空的,哪些是可以有缺失的,缺失的时候数据表里是None值还是默认值。

如果用户更新这些信息,数据表是新增一个记录还是覆盖已有的记录?会对我们后续建模有无影响?是否有未来信息泄露的可能?用户在从下拉列表中选择信息的时候,下拉列表是固定不变的还是会改变的?会引起数据不一致嘛?后续需要对数据做清洗和归一化嘛?

只有当你回顾一个业务流程,用户的每个数据从app流转到数据表的逻辑都非常清晰后,才算做完了数据获取的准备工作。

说到这里,你可能就不会觉得数据获取是一件很简单的事情,而是需要很多耐心和经验,很考验一个人沟通能力和信息归纳整理能力的一件事情。

总结一下,在拿到一个数据分析任务的时候,首先要做好数据获取的准备工作,分成三方面:

  1. 了解数据仓库的表;
  2. 整理表和表之间的逻辑关系;
  3. 理解用户数据在数据仓库的落库逻辑;

这些工作会能极大地加深你对数据的理解,能在项目的早期把数据的坑点都找出来,能让你迅速的融入到业务中,做一个既有分析建模技能又有业务实战能力的数据科学家。

 

本文由 @FAL金科应用研院 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!