时间: 2021-07-30 09:15:58 人气: 9 评论: 0
“指标”是指对于数据的统计值,建立指标体系是为了在报表、Dashboard等工具中快速灵活体现公司数据。
从直观上来理解,报表系统中的每张报表是通过一些SQL语句计算出来的,系统只要每天按照每张报表的SQL定时去跑数据就可以了。
但是随着时间的推移,报表数量越来越多,每天的定时SQL任务跑不动了。但是**发现其实很多报表用到了类似的指标,可能维度不同或者可能完全相同。
这时候就需要升华一下方案,将报表的计算,细化到指标的计算上。
上述问题的解决需要通过一套完善的指标管理服务来实现,指标服务相当于存储了某个指标各种维度下的SQL查询结果。如下图所示,对于指标1,指标服务需要存储其在维度1和维度2等维度下的所有拆分值,即存储的是“维度1-维度2-指标1的值”这样的索引结构。
有些数据团队**把这些指标值存储为数据仓库中的一个层级,相当于是对DW层明细数据的统计值计算,但是在实际应用中,对指标值的调用需要满足很强的即时性,存在数据仓库中可能达不到这样的性能要求,于是改为存储在HBase这种Key-Value存储方式的数据库中。
按照这样的存储方式好处是什么呢?
当你想要看指标1在“维度1=A&维度2=a”等各种组合条件下的值的时候,可以方便取出来,如果指标1是可以简单加和的,那么你还可以查看各种维度组合加和的数据。比如:不选择维度1和维度2的条件,直接看指标1的总计值,也是可以通过加和做到的。
这样的处理方式还为用户自助创建报表提供了可能,用户可以选择想看的指标在任意维度下的数据,还可以任意拼接指标形成自己的专属报表。
而且,这样做,一个指标不管被多少个报表用到,只用计算一遍数据即可。具体报表呈现的时候,实际只是将各种统计值进行组合,不需要运行SQL实时拉取计算数据,效率也就提高了很多。
指标系统实际就是写一个稍微复杂的包含多个group by的SQL,其实看到上面的图,大家也可以联想到,其实就是自己在运行SQL的时候得到的一个包含多个索引的group by结果。
思路即使将指标拆分到最小粒度,再在报表中根据需要组合各个维度下的值。
上面解决方案听起来很完美,实际操作中还是有不少问题存在的。
指标的原理讲完了,那么在实际操作中,我们需要做哪些指标出来呢?
其实指标需求主要来自业务方运营人员等,但是不同运营部门可能关心的侧重点不同,而且**有遗漏情况。
首先我们要把不同部门的需求收集完,然后根据需求指标类型进行分类。在分类中要cover到大家的需求,还要尽可能穷举其他可能的指标。这部分也是依赖自己对于业务系统的了解及数据库的了解,其实跟数据仓库的搭建是一体的事情。
作者:小九,一枚互金数据产品
本文由 @小九 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议