编写sql时如何进行有效自测以及提升数据质量

今天与领导沟通时总结了一下,因为数据这个东西,测试起来很麻烦,但是作为开发,需求做完后我还是得保证数据质量这个问题,所以有效的自测,也应该是一个具体的流程.

术语:

mapping: 需求文档

ods:数仓贴源层,即最开始采集过来的数据

dwd:数仓明细层,即对ods进行一定的清洗,转换,补充字段造出得明细表

dws:数仓主题层,本层数据多为主题宽表,字段很多,且有一定的聚合操作

ads:数仓应用层,本层为应用层数据,是对dws或者dwd进行一定的计算操作得来的,是给用户看的数据,也可以叫报表.

1.需求文档到手之后,先进行上游数据验证

        关联字段是否唯一,如果重复,说明需求文档有问题,绝大多数需求应该不会需要笛卡尔积进行数据膨胀,尤其是大数据.保证关联字段的唯一性是第一步的关键,尤其是这张表有很多张表进行关联的情况下.

        对应的处理就是与需求沟通,到底是去重,还是添加其他字段一起关联,还是进行一下行列转换等操作.

2.保证数据量的一致性

        说白了就是数据量不应该变化,主表ods层的数据是9000,在不考虑清洗的情况下,那么在dwd层计算时也应该时9000,不应该有数据量的变化.

        接下来进入了dws-ads计算层,这一层的数据量有改动,多数情况下会需要聚合然后进行计算等操作.

        但是聚合后的计算值一定会和原来的数量相同.比如计算pv,uv.计算pv,假设dwd表的最小粒度就是页面,而pv的意思就是页面统计,同一个页面的访问次数,所以,dws表的最小粒度是一个页面,也就是一个页面对应着一个pv值,而所有pv的值加起来,就应该是dwd的总数据量(不论是多了还是少了,肯定都是错的),uv同理.用户量是不会徒然增加或者减少的

3.选择两条样例数据,查看整体的数据流向

4.review  代码重新审视

        因为需求文档不断变动,可能做到后面的时候,开发完成的代码和已经有了一些细小的差异但是直观感受不到,然后等到上线时发现这些问题,然后积重难返.但是回过头来看代码,因为注释的关系,又会跟着自己之前的思路走.

        这是一个很容易走进自己思维误区的过程,所以我当前的想法以及意见是,先不写注释,如果有足够的开发与测试时间,那就不写注释,一点不写,等到代码回头审视的时候,一边看着需求文档,一边看着代码,并且给代码添加注释,这是一个重新读自己代码的过程,在这个过程里,就完成了review,并且更新了注释量,因为在开发代码阶段写注释总是会嫌麻烦,而review这个过程则不会.

5.不要为了省事而放弃一些必要的流程

        开发时多数情况下不会遇见大问题,多是一些鸡毛蒜皮的小事情,比如说,mapping上的字段命名与表的真实字段命名对应不上,这个问题可大可小,表的命名也是,有可能因为需求人员的疏忽,就导致命名上会出现好大的差异,最后的表名字与本来的设计方案大相径庭.

        所以在发现问题的时候,即使是细致到字段命名与mapping上的区别,也要与需求人员沟通,与测试人员沟通

        数仓的初衷就是方便管理,可以更为合理的管理数据.所以命名的规范一定是要非常的严格.作为开发人员我觉得并不应该背那么多的锅,因为很多时候不应该只是我开发的问题,不过作为执行者,代码是从我们开发手里写出来,多少也得抗点

        即先不提xx,xx的问题,难道你们开发就没有一点问题吗

        是的,主啊,我有罪