数据大体系（三）——指标

引

又见指标体系。之前有几篇拙作有聊到指标体系的建设，因此算是起了一个头。前几日文章里，主要是聊我们数据大体系的整体数据仓库的分层以及建设，那么细心的小伙伴是否会发出这样的疑问：那我们前些文章里所述的指标是放在哪一层呢？指标是否又需要进行分层，前面写的指标管理/治理是否就是分层的依据？指标是否又有命名的规范？

我们在这篇里主要想来解惑第一个问题：

1. 指标在哪一层

解

这个问题，让我们先回顾指标以及数仓分层的内容。

首先，先让我们来看看指标的定义：

```

是用于衡量事物发展程度的单位或者方法，一般我们使用数量或者数值来进行表示，因此从某种意义上来说，它就是度量。

```

因此，我们可以从简单地认为，指标就是一种统计的度量。前文也有提到 原子指标 + 修饰 = 衍生指标。这里修饰可以是时间，也可以是其他的维度。维度即事务或者现象的某一种特定特征。

好了， 那么让我们再看看数仓的主要分层的内容。

ODS 层，主要用于存储源系统中的原表内容；DW 层，则是将 ODS 层的内容， 进行数据打平形成以某些内容为主的大款表然后进行对应的轻聚合；DM 则是将某一主题域要用到的一系列数据集中起来，供上层进行调用；而 ads 层则是为了保持上层应用的灵活性提炼出来的应用层数据集。

从以上信息来看，我们可以看到，指标和数仓的分层，其实并不是在一个维度上来讨论数据的特征。如果一定要讨论，那么似乎 DM 这一层进行承载会比较合适。然而我们在现实中，指标并不一定固定是从 DM 层进行出具，一些企业甚至 DM 层都没有，所以我们不可同日而语地、武断地说属于哪一层。

从指标的定义上来讲，只要是一种统计的度量，加上维度的限定，就可以称之为一类指标。因此，dws，dm，ads 层的数据，甚至 dwd/ods，只要最终出来的是一个关系型的数据表（内存中），那就能是一个指标。这块，我们主要讨论两个话题，存和算。

存

存，主要指的是指标数据在数据库中的存储形式，笔者遇到的方式，可以有以下几种：

一指标一表

这种方式，可以将一个原子指标设定一个表，将指标对应的维度同时建立在表中。这样所有的由该原子指标衍生出的指标，都可以在这张表里轻松地出具。但这种方式有比较大的弊端——随着业务的发展，很多需要进行衍生的指标，或者另一种形式由衍生指标衍生出的指标，很难在一张表里进行表示。即，早期并无法能穷尽地去思考由原子指标衍生出的指标体系。当然它也有一定的好处， 方便理解，这张表都是从一个原子指标出来的，血缘关系清楚明了。

指标表和元数据表

这种管理方式，会有两张表，第一张表类似：

这里，indicator_id 表示指标的编码，indicator_desc 表示指标的含义。从以上的示例我们其实可以明白，不论是原子指标还是衍生指标，在这种管理方式下，都是一个指标 ，每个指标都在这张表里进行描述。而描述这些指标的其他信息，我们则在元数据表 里进行描述，如这个指标的 Owner 部门，更新周期，值的范围描述等一系列信息。这里是比较通用地一种描述法，这里就不再赘述。

类数据集市

我这里使用一个叫类数据集市 的名词来给这种管理模式取了一个居中的名字。因此它并非是数据集市或者指标集市，而是一种变种。首先在这种方式中，我们使用类似数据集市的方式，将一个相同域下的顶层数据指标进行汇集；其次，又不完全一致的是，我们将能够共享相同维度的指标在一张指标里进行存储。

这种方式，能够比较好地减少表的爆炸性增长，但又能保持一定的灵活性。或许是一种好的管理方式。

算

数据存好后，接下来就是进行呈现的方式。这里也可以分为两种。

直出

直出的形式，其实就是直接从某张表中取需要的字段/值形成二维表进行报表展现。这类基本无需额外的计算，直接取即可。

SQL

对于这类方式，则是固定一个 SQL 并且固定读取的表，每次生成对应的数据。

结

这篇文章我们讲的是指标，主要探讨的主题是指标应该在哪一层？答案似乎也容易看到：哪一层都能出具指标。

事实上， 指标的管理重点并不在于其在数据仓库的哪一层存储或者得出，而在于其指标口径 的一致性。在业务层面/产品层面，设计好指标的体系，与业务人员确定好指标的口径；在实际操作层面，确定指标的来源数据表，固定指标取数的 SQL 以及取数的周期性，要比指标从哪一层得出，要关键得多得多。

尾

今天是第 11 篇，感觉到文章写作的一些疲惫性。一开始明知是要写些什么主题，但脑子却不知不觉的地会跑偏。再回顾头去看这些文章，感觉每一篇都是草稿，不甚成体系输出。

只是对不住的是看官您。不过先这样往前吧，等该挑战结束，我们来结合这些文章再形成一系列的体系文章，这样希望能对看官更有一些帮助。