如何保证从数据仓库取出的数据质量？( 二 )

二、整理表和表之间的逻辑关系
在找到DE的负责人后，需要他们提供数据表对应的文档，然后整理出这些表之间的逻辑关系，一般数仓表都会有维度表和明细表两大类，常见的套路就是维度表去关联明细表。
举个例子，信贷数据的表基本上可以归纳成用户相关的表，产品相关的表，贷款记录的表和还款记录的表。
我们可以把表的关系画成简易版的ER图结，方便自己和团队的其他成员理解。

本文插图
在这里，用户维度表，产品信息表和借贷记录表可以认为是维度表，用户信用分可以认为是用户维度扩展出来的明细信息，还款记录可以认为是借贷维度扩展出来的明细信息。
所以在写SQL取用户的时候，都是从用户的维度表出发去关联其他对应的用户层面明细表，这样的SQL逻辑是最严谨可靠的。
回顾下之前的SQL例子：
这里从借贷记录表里拿用户维度的信息就是非常不合理的一类逻辑。
如果我们是想找有信贷记录的用户列表的话，应该是用户维度表去关联借贷记录表，并在筛选条件中设置只挑选有信贷记录的用户，这样的SQL才是严谨可靠的。
三、理解用户数据在数据仓库的落库逻辑
在熟悉了数据表里的字段和表的相互关系后，接下来就需要感受数据在业务逻辑中的流动和落盘。
一个数据老鸟在和业务沟通时候，会在脑子里带着表结构去询问业务的SOP 。
当业务说用户注册账户，脑子里就要想着在用户维度表增加一行，用户注册的相关信息会被记录在这个维度表里。
然后用户填写相关的表格提交信息，就会知道我们收集的用户信息会按SOP流程在规定的时间落盘在用户信息表中。
其中哪些信息是必须非空的，哪些是可以有缺失的，缺失的时候数据表里是None值还是默认值。
如果用户更新这些信息，数据表是新增一个记录还是覆盖已有的记录？会对我们后续建模有无影响？是否有未来信息泄露的可能？用户在从下拉列表中选择信息的时候，下拉列表是固定不变的还是会改变的？会引起数据不一致嘛？后续需要对数据做清洗和归一化嘛？
只有当你回顾一个业务流程，用户的每个数据从app流转到数据表的逻辑都非常清晰后，才算做完了数据获取的准备工作。
说到这里，你可能就不会觉得数据获取是一件很简单的事情，而是需要很多耐心和经验，很考验一个人沟通能力和信息归纳整理能力的一件事情。
总结一下，在拿到一个数据分析任务的时候，首先要做好数据获取的准备工作，分成三方面：