本文要来说说,数仓中的数据指标库
数仓系列:
【数仓】数据仓库的思考(一):https://blog.csdn.net/lsr40/article/details/105576047
【数仓】数据仓库的建设(二):https://blog.csdn.net/lsr40/article/details/105639190
【数仓】数据仓库的元数据管理(三):https://blog.csdn.net/lsr40/article/details/105654112
【数仓】数据仓库的数据质量任务监控(四):https://blog.csdn.net/lsr40/article/details/105689342
不知道大家在日常工作中是否会经常遇到如下类似的问题:
问题一:
BI团队:为什么 A 页面上的数据和 B 页面上的数据对不上?
开发:我去看看(一段时间后),A 是来自 a 表,B 是来自 b 表,一个包含通过公式一算出来的,另一个是公式二算出来的
问题二:
数据开发:同样的指标在不同的项目里被用到,开发 A 同学从 a 表里取了数据,开发 B 同学从 b 表里取了数据,我应该从哪里取数据?指标的逻辑变了2张表都需要做对应的修改?
问题三:
数据开发和 BI 工程师:没有现成的指标,我要的指标数据怎么来?问数仓同学然后口口相传?
如果大家遇到过上述类似的问题,说明需要指标库这样的一套指标管理工具来规范指标的定义与维护。
问题1体现的是指标定义不够清晰明确,两个页面上的指标定义其实是不同的,但是页面上的看到的可能是同一个中文名称或者名称很类似,又或者同样一个含义的指标在不同的界面上展示的名称却不相同,让人产生歧义。
问题2体现的问题是同一个指标因为由不同的数据开发同学来制作,可能会被重复开发,不但造成资源浪费,还会造成维护困难。
问题3体现的问题是对于需要新开发的指标
1、缺少现成的指标开发工具
2、该使用数仓中哪一层的哪些表,表情况和是否有什么需要注意的?
3、甚至要数的同事都描述不清楚要的数据是什么样子的,然后一直让出数据的同事返工
我觉得这太过分了,自己要什么都说不清楚, 然后一直开发完让别人返工!!!
随着数据需求越来越多,并且要数的部门越来越多,指标定义混乱,描述不清,就会导致数仓同事工作被频繁打断,不停在跟新的人解释某个指标是怎么生成的,口口相传是最可怕的(因为会有巨大的时间成本消耗,并且可能会有误差)
当然,我说的分类仅仅是我个人的见解,大家也可以有各自的分类方式!
1、原生指标(不需要附加公式)
原生指标,指的是,做数仓的时候,我们做出来的一些基础指标
例如:pv,uv,rank(按照某个字段排序),ratio(占比),转化率等,这类实际的,通用型的指标,计算方式全国甚至全世界都统一的指标,我们认为是原生指标
2、衍生指标(需要自定义规则,添加公式生成的指标)
衍生指标 = 原生指标(可以是保存到表中的或者重新算的) + 修饰词(where条件)+ 维度(group by )
这个就很多了,例如:各个公司可能会根据uv做出一些推及全网的各种指标(明显使用了公式),某些效果,价值指标,甚至tgi可能也不是使用大家统一认定的公式生成的,
衍生指标一定要记录相应信息:
中文,英文,使用公式/存储过程,维度(日,周,月,或者其他维度),修饰词(where条件),样例模板sql,用于哪个产品,从哪张表开始存在,中文说明备注信息,制作人,生成时间,修改时间等
还需要根据各自公司的需求,去增加或者减少字段
顺便提一句,同一类型的产品,所要计算的指标还是会比较类似的,比如做app产品,可能就会有活跃用户,留存,新增,使用时长,用户类型(轻度用户,重度用户),渠道(投放和收益分析)等,可以相互借鉴,这就偏数据分析了,不是本文的重点,所以我就提一嘴~
生成指标的最简单的方式,当然是给到相应的计算方法和表,让数据需求方直接去表里面跑个sql,获得数据,导出到excel
但这样的方式,未免太过简陋,既没有权限的控制,也会导致部分数据需求方水平不行sql写的太烂,影响数据库性能,影响正常的流程。
所以最好的方式是,能够开发成一个平台,让数据需求方申请对应的表权限,选择修饰词,选择维度,选择原生指标,传入公式,获得想要的指标,并且提供不同的导出数据的方式
并且要思考下,如果用户选择的修饰词,维度,原生指标已经生成过相应的指标,是否要提示用户来避免重复开发和计算?
好了数仓的系列应该到这里告一段落了,当然每个人的理解都不一样,我只是分享我自己的看法,如果大家有什么问题,欢迎留言讨论~