“指标”是指对于数据的统计值，建立指标体系是为了在报表、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实时拉取计算数据，效率也就提高了很多。
二、指标系统的SQL实现
指标系统实际就是写一个稍微复杂的包含多个group by的SQL，其实看到上面的图，大家也可以联想到，其实就是自己在运行SQL的时候得到的一个包含多个索引的group by结果。
思路即使将指标拆分到最小粒度，再在报表中根据需要组合各个维度下的值。
三、指标系统的优缺点
上面解决方案听起来很完美，实际操作中还是有不少问题存在的。
- 对于计算时需要去重的指标（比如：一个用户多个订单这种事实表，要计算用户的数量），你得到的只是在当前维度组合下的指标。并不能简单实现只取部分指标的场景，或不选择维度的场景，大家可以自己思考下为什么。
- 因为指标系统拆为了尽可能增大指标的可重复使用性，拆分了尽可能多的维度，有时候甚至维度的组合行数已经达到了10万+的级别。这就造成在报表系统中组合不同维度的数据有时候，实时处理压力很大。当然也是有办法进行优化的，这里就不深入介绍了。
- 因为指标是一层数据抽象，当指标数据出现问题的时候，排查问题就相当于多了一层。类似的，修复数据也要多修复一层。
- 另外，如果要给现有指标体系增加维度，旧数据的处理也是一件比较麻烦的事情，因为需要重跑之前的历史数据。
四、业务的指标体系建立
指标的原理讲完了，那么在实际操作中，我们需要做哪些指标出来呢？
其实指标需求主要来自业务方运营人员等，但是不同运营部门可能关心的侧重点不同，而且会有遗漏情况。
首先我们要把不同部门的需求收集完，然后根据需求指标类型进行分类。在分类中要cover到大家的需求，还要尽可能穷举其他可能的指标。这部分也是依赖自己对于业务系统的了解及数据库的了解，其实跟数据仓库的搭建是一体的事情。
閱讀更多 人人都是產品經理 的文章
