本文要来说说，数仓中的数据指标库

数仓系列：

【数仓】数据仓库的思考（一）：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写的太烂，影响数据库性能，影响正常的流程。

所以最好的方式是，能够开发成一个平台，让数据需求方申请对应的表权限，选择修饰词，选择维度，选择原生指标，传入公式，获得想要的指标，并且提供不同的导出数据的方式

并且要思考下，如果用户选择的修饰词，维度，原生指标已经生成过相应的指标，是否要提示用户来避免重复开发和计算？

好了数仓的系列应该到这里告一段落了，当然每个人的理解都不一样，我只是分享我自己的看法，如果大家有什么问题，欢迎留言讨论~