当前位置:   article > 正文

共性加工层的建设_数仓共性加工层

数仓共性加工层

共性加工层的建设

1、背景

在最懵懂的年纪混迹外包,当学校的光环一文不值以后,又在因缘际会之下进入了某券商,负责指标开发。发现此处指标开发基于指标平台进行。 基于笔者在数据行业多年的混迹,将自己对数据的认知进行总结,书以简文以待充盈。

因为一直从事证券行业的数据开发,所以数据架构更偏向于主题模型,所以此处仅对数仓的共性加工进行撰写。

2、数仓分层设计

在这里插入图片描述

这是之前在某公司做的数仓分层架构图,共分为五层。分别是:数据缓冲层(LDS)、操作数据层(ODS)、整合模型层(EDW)、共性加工层(GDM)、数据集市层(ADM)。

整合模型层采用主题模型的建模方式搭建数据模型。共性加工层一般是逆范式化的宽表,某种程度上采用星型模型建模的方法。是在主题模型的基础上对数据进行预加载和预关联。一方面保证复杂操作中间结果留存,一次加工多次使用,且保证统一加工口径;另一方面弥补主题模型的不足,将范式化的结果预关联方便后续加工。

共性加工层表存放的是汇总后的数据,一般都有统计日期,根据时间粒度不同,可以分为按月、按季、按年等不同粒度的数据表,但是根据实际数据的存储空间,可以通过统计日期适当调整共性加工层数据表的粒度。

(此处其他层析不做赘述,在其他网站可以轻松查到)

3、共性加工层的设计

(1) 需求分析

其实没有共性加工层同样可以满足应用,因为基础数据在主题模型层已经有了。共性加工层的意义我认为有如下几个点:

  • 预关联;在应用中高频出现需要关联某些表进行数据加工的情况,则可以在共性加工的明细层将最细粒度的数据先行关联,做到一次关联多次使用。

  • 预加载;在应用中需要用到某个值,但是这个值的计算需要耗费较长的时间,即便这个值不被高频访问也可以提前计算存储下来供后续使用,一方面节省时间,另一方面也可以对复杂结果进行留存方便核对。

  • 统一加工口径;随着应用的不断增加就会发现很多应用其实使用的值是相同的,但计算方式会有所差异,因为数据是在不同的系统之间进行流转的,同一份数据在A系统有,在B中也会有,不同业务接触到的直接系统是不一样的。但是数据的源头只有一个。设计共性加工可以保证数据同源,同时由于有了一定的存储和设计逐渐的让数据人员具备了较为专业的业务沟通能力。

从以上三点不难看出,共性加工层是冗余存储的,所以必然是有用才会存储下来,且一定是短而精的并不是什么样的数据都需要形成指标加工共性。

需求分析模板

表头填写说明
需求名称对需求的概要描述,一般由业务部门提供
所属业务主题对需求的初步分类
需求表样需求的报表样式(二维表、柱状图、折线图、混合图表,导出数据文件等)
提出部门提出需求的业务部门
提出人提出需求的业务部门工作人员
字段名称需求中的字段名称
字段类型指标(eg:市值)、维度(产品类型)、基本属性(一般出现在明细数据需求中)
基础指标一些指标由于各部门在统计时关注的角度不一样,在需求中展现出来的名称也就不一样,此处填写该字段来源字段指标名称
指标类型时点值、累计值
是否涉及同比计算是、否
是否涉及环比计算是、否
数据粒度日、周、月、季、年
相关维度
加工口径进行数据的统计的具体计算逻辑详细描述

(2)轻度汇总层

按照一定的业务主题进行划分,存储细粒度的统计数据。需要满足以下原则

  • 通用性:使用范围广泛使用频率较高的信息优先考虑;

  • 稳定性:只纳入加工口径比较稳定的属性,以减少变更维护;

  • 性能提升程度:有些业务数据计算时非常消耗性能,也考虑提炼共性,以提升性能;

  • 业务逻辑复杂程度:有些业务数据计算逻辑非常复杂,也考虑提炼一层中间表,以方便使用并统一口径;

  • 简约性:满足使用的情况下尽量以精简且便于维护为主,减少使用和维护陷阱。比如同比、累计指标等尽量不做设计。

  • 适当冗余:使用范围特别广泛的维度及属性可适当冗余,以减少关联。

(3)指标层

指标:指标是通过对数据进行采集、分析得到的一个汇总结果,是将业务单元拆分后的度量值。使得业务可描述、可度量。反应的是一个业务过程的规模和表现程度。

指标体系:通过对客观的指标描述和度量对象的性质、特征、变化等方面的一种体系化。对指标进行分类分级和标准化管理,并通过指标体系与基础数据和分析应用进行联系相辅相成。

对于高频访问的,尤其涉及占比计算的指标。可在轻度汇总表的基础上,对数据进行提炼和进一步汇总,并以键值对的形式进行存储。

命名方式:表名_index _[数据粒度]

日期粒度缩写
D
W
M
Q
Y

为了方便管理清晰知晓共落地了多少指标,每个指标的含义,虽说指标定义尽可能将业务逻辑稳定的指标落下来,但总的来说是从需求出发的是被动的,所以需要考虑非理想化的情况。或许某些指标在业务人员提出的时候对指标的理解和定义就是不合适的。基于种种考虑 一般需要设计指标字典表,表结构如下:

属性属性说明
指标英文名称
指标中文名称
数据粒度D、W、M、Q、Y
指标类型时点、累计
业务口径说明

指标定义标准

  • 原子指标:原子指标由业务过程、主体、度量三部分组成。eg:客户持仓市值规模
  • 衍生指标:数据范围、业务过程、主体、度量、可组合维度、时间粒度。eg:月末交易日客户持仓城投债市值规模

(4)深度汇总层

面向应用,按需设计,带有一定的业务导向,以贴近需求为主

  • 访问性能要求:公司领导等高优先级用户的需求,以及对访问速度要求较高的近生产类需求,需要保障访问速度(如:管理驾驶舱);

  • 少而精:非高优先级用户及非高访问速度要求的需求,无特殊性能要求的情况(偏向OLAP的诉求)不做深度汇总,以减少各种变更带来的调整工作量(比如统计口径、字段变化、加载程序维护错误等);

  • 通用性:可在公用性方面再做一层提炼,多个需求可以共用一个高度汇总表;

  • 并不是所有的共性需求都需要通过设计高度汇总层的表或视图来实现,也可以直接通过轻度汇总表和指标表来实现。

4、更新迭代

数仓本身就是这样,相较于做了多少报表,存了多少数据,其实更重要的是形成一套标准化的数据流程与分析方法。为的就是不断适应变化中的数据,适应发展中的业务逻辑。其实不存在无用的数据,只存在价值密度低的数据,随着技术的发展和技术与业务的相辅相成,很多之前不做价值探索的数据需要进行探索,也会产生新的业务数据。
  共性加工层更是如此,需要不断迭代优化,使其发挥价值。

本文内容由网友自发贡献,转载请注明出处:https://www.wpsshop.cn/w/寸_铁/article/detail/863675
推荐阅读
相关标签
  

闽ICP备14008679号