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

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

 

 

从上往下定义, 阿里云

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

dws的数据来源于dwd。支付宝

dwd的数据来源于ods。table

--------im

接下来咱们定义原子指标和派生指标。支付

派生指标定义在dws层。而且绑定原子指标。全部的应用数据由派生指标去group by。数据

原子指标定义在dwd层+虚拟层。原子指标绑定一个dwd的度量值,可是有可能会有计算,因此不彻底在dwd,运行的时候可能会进行计算。称为一个虚拟的层。img

固然能够把这个虚拟层作出来,专门作一层原子指标层。tab

 

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

  指标名称  指标来源 指标口径
原子指标 能够与度量值一致,也能够不一致 绑定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便可,很是简单方便。

相关文章
相关标签/搜索