• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

指标系统计算架构设计

开发技术 开发技术 4周前 (09-26) 28次浏览

前言

前一篇《指标管理系统设计》,我讲了指标体系要解决的问题,以及指标系统宏观搭建和模型上的设计。其中对具体实施时的计算存储架构说的不是特别清楚。这一篇,我将着重介绍指标计算架构的设计。

过往的一些实现问题

指标体系跟标签体系其实有些类似,都有很多的字段,甚至在某种程度上,他们还可以成为依托关系。比如标签系统可以使用指标体系作为数据基础,当然这是题外话。这里列举下我之前参与的标签系统和一些报表开发所存在的问题。

下图是一个标签系统的的标签加工逻辑片段,这个脚本一次性的将标签体系中的所有标签挨个计算出来
指标系统计算架构设计

下图是一个报表sql的脚本片段,它也一次性计算出了该表报的多个字段,有很复杂的加工逻辑
指标系统计算架构设计

从软件设计的角度来看,上述的开发方式耦合度很高,这会带来一些列的问题

  • 所有逻辑耦合在一起,后续阅读理解很困难
  • 要下线、新增、更新一个指标/标签需要更改原来的脚本,代价较高,出现bug时还会影响之前的指标/标签
  • 多个报表拥有相同口径的指标时,该指标的加工逻辑需要在多个报表中重复编写,修改时也需要多处修改,难免挂一漏万

计算架构设计

对于上述问题,解决的主要思想是,低耦合高内聚。将报表拆散到指标粒度,计算存储的单元不是报表,而是指标。从而让指标的复用性增强,也是的对单个指标增删改的效率更高,提升整个系统的稳健性。

整个计算架构分为如下图的四层
指标系统计算架构设计

  • 基础数仓层,这一层主要是数仓模型
  • 指标计算层,一个指标一个计算任务(任务可以是sql或其他加工脚本代码),它基于底层的基础数仓层进行加工
  • 指标存储层,每一个加工好的指标,都有一个对应的表来存储
  • 报表层,业务报表的输出,通过灵活的join组合各指标表,即可得出最终的报表

为什么要一个指标一个表

不同指标其使用的维度个数不同,这使得指标结果数据的字段都是不同的,无法统一用一个表来存放所有指标值。比如最近30天各大区的销售额指标,使用了一个维度,大区

大区 销售额
华中 500000
华北 600000
华东 700000

而最近30天,各大区,各产品线的销售额度,就使用了两个维度,大区产品线

大区 产品线 销售额
华中 女装 10000
华中 男装 20000
华北 男装 30000
华北 童装 40000

一个表一个指标是否过多

指标只要不重复建设,上万个差不多能覆盖一般公司的所有报表需求。上万个表对于一般的大数据处理系统比如hive来说,没什么大问题。何况这些指标表只是多,并不一定数据量大。

参考资料

https://mp.weixin.qq.com/s/uavKimWskRE8Ea83fv_tpA
https://www.cnblogs.com/niceshot/p/13640630.html


喜欢 (0)