简单设计一个onedata指标管理体系

以阿里云的maxcompute的数据仓库架构为例,

 

 

从上往下定义, 

dwp的数据,来源是dws+dim,最主要是dws。这里不讨论dim的作用。

dws的数据来源于dwd。

dwd的数据来源于ods。

——–

接下来我们定义原子指标和派生指标。

派生指标定义在dws层。并且绑定原子指标。所有的应用数据由派生指标去group by。

原子指标定义在dwd层+虚拟层。原子指标绑定一个dwd的度量值,但是有可能会有计算,所以不完全在dwd,运行的时候可能会进行计算。称为一个虚拟的层。

当然可以把这个虚拟层做出来,专门做一层原子指标层。

 

这个时候我们的指标管理系统里面应该有以下东西:

  指标名称  指标来源 指标口径
原子指标 可以与度量值一致,也可以不一致 绑定dwd的表名和字段

1.和绑定的dwd的度量值完全对应

2.需要一点计算,录入计算逻辑

派生指标 修饰词+原子指标名称+时间周期 绑定一个原子指标   

①修饰词:作为where过滤的字段

②时间周期:近7天,近一个月等

③聚合操作:平均,求和等

③聚合维度,也可以不录,在模型管理里录

应用指标 同环比+修饰词+派生指标 绑定一个派生指标

①聚合的维度:派生指标所在表的字段

②可能有一些简单的过滤。

③可能会有一些同环比的计算

绝对不允许有字段计算,如加减乘除,if转化等,如果有,说明逻辑没有下沉。

 

 

举个例子:

应用指标需要:当月人流量大于2w次并且支付渠道为支付宝的的平均订单金额净增长,维度:每一个城市

拥有的业务过程:订单表。门店人流量表。

  名称   来源 口径
原子指标 订单金额 交易表:支付金额,退款金额 支付金额-退款金额
派生指标

当月人流量大于2w次

并且支付渠道为支付宝的的平均订单金额

订单金额

①修饰词:

where 支付渠道=支付宝

having 月人流量>2w

②时间周期

where 订单时间是一个月

③聚合操作:平均

③维度:城市,品类

(聚合维度比业务指标更宽)

应用指标

当月人流量大于2w次

并且支付渠道为支付宝的的平均订单金额净增长

当月人流量大于2w次

并且支付渠道为支付宝的的平均订单金额

①聚合维度:城市

②环比计算,当月减上月

以上将一个应用指标的计算逻辑沉淀到不同的层次中的指标管理方式,实现了从度量值到最后应用指标的统一,再加上术语管理系统,

可以解决指标同名不同义,同义不同名的口径问题。称之为one data,即一个应用指标有且只有唯一的计算逻辑。

—————————————————————————————-

《模型的作用》

dws的表可以称之为派生指标的模型。

一个派生指标可以有不同的维度。比如近7月,近一个月,城市品类的,城市商圈的,所以 派生指标:模型 = 1:n

可以在录入不同维度的派生指标时,

①当做是不同的派生指标,将维度当做口径记录下来

②当做是同一个派生指标,建设不同维度的模型(表),绑定这个派生指标。如果这么做,应用指标绑定的将不是派生指标,而是dws模型里的字段。

—————————————————————————————-

《是否可以将度量值认为是原子指标》

原子指标代表的是指标的最底层,是服务于指标系统的。度量值代表的是业务发生的过程中产生的数据,是记录业务客观现象的。

虽然两者的字段有很多重合的地方,最好将原子指标重新定义,防止指标管理体系和数仓公共表建设过于耦合而增大统一指标口径的难度。

—————————————————————————————-

《派生指标和应用指标的区别》

应用指标的来源是派生指标,不一定要计算同环比,很多时候名称是一模一样的。

他们的区别在于维度。

dws为了满足更多的应用指标的计算,维度会更多 更细。

打个比方,维度为城市 品类 商圈 门店等级 的订单金额,可以上卷 城市维度,品类维度,商圈维度,城市+品类维度,等多达15个组合的应用指标。

这样BI计算应用指标的时候,就只要根据自己关心的维度做group by即可,非常简单方便。