数据仓库是所有产品的数据中心,公司体系下的所有产品产生的所有数据最终都流向数据仓库,可以说数据仓库不产生数据,也不消费数据,只是数据的搬运工。
注意: 本文讨论的数据公共层设计理念遵循维度建模思想
基于以上几点,需要将数据分层次管理,每一层分工合作,对数据进行不同程度的处理,如同工厂里的流水线一般,从而确保数据的生命性、生态性。
数据模型分为三层:
模型层次关系如图一:
数据操作层又被称为基础数据层.以天为时间周期,将操作数据几乎无处理地存放在数据仓库系统(Data Warehouse
)中。
公共维度模型层又被称作模型层,主题层,数据仓库层(DW层)。是我们在做数据仓库时要核心设计的一层,
在这里,存放明细事实数据,维表数据及公共指标汇总数据。其中明细事实数据,维表数据一般从ODS层数据加工生成;公共指标汇总数据一般根据维表数据和明细事实数据加工生成。
CDM又细分为 DWD(Data Warehouse Detail
),DWM(Data WareHouse Middle
)和DWS(Data WareHouse Servce
)三层架构。
总的设计理念和功能:
该层一般保持和ODS层一样的数据粒度,并且提供一定的数据质量保证。同时为提高数据的易用性,以维度建模方法为理论基础,采用一些维度退化手法,将维度退化至事实表中,减少事实表与维度表的关联,提高明细数据表的易用性。
注意:在该层也会做一部分的数据聚合,将相同主题的数据汇集到一张表中,提高数据的可用性。
业务场景:A公司是一家大型零售分销公司,因此往往有一张订单卖给零售商,零售商再下一张订单给零售店,零售单再下一张订单给终端用户。此时,每一级订单是断层,且来源于不同的系统的,因此每一级订单的表结构完全不同。
需求分析:无法从全链条上看到每一个商品在渠道中的流转,也无法实时跟踪到每个商品的具体转化效率。
解决方案:为了方便大家的使用,需要在DWD层做一张用户订单明细表。把每一级的订单按照主题分门别类(一级订单、二级订单、三级订单),统一字段名,并且建立一种关联关系,使这三者能串联起来,形成一整个渠道流程。
该层会在DWD层的数据基础上,对数据做轻度的聚合操作,生成一系列的中间表,提升公共指标的复用性,减少重复加工。
在实际计算中,如果直接从DWD或者ODS计算出宽表(DWS)的统计指标,会存在计算量太大并且维度太少的问题,因此一般的做法是,在DWM层先计算出多个小的中间表,然后再拼接成一张DWS的宽表。
选取业务关注的核心维度来做聚合操作,比如只保留人、商品、设备和页面区域维度。类似的,我们这样做了很多个DWM的中间表。
注意:由于宽和窄的界限不易界定,也可以去掉DWM这一层,只留DWS层,将所有的数据在放在DWS也可以。(图一的架构设计来源于阿里巴巴大数据领域建模综述,是没有该层设计。笔者目前所在的公司也是没有做这一层设计的,均是根据判断将表归纳到DWD或者DWS)
又被称做数据服务层,数据集市或者宽表。在该层会加强指标的维度退化,采取更多的宽表化手段构建公共指标数据层,提升公共指标的复用性,减少重复加工。
一般来讲,该层的数据表会相对比较少,一张表会涵盖比较多的业务内容,由于其字段较多,因此一般也会称该层的表为宽表。
按照业务划分,如流量、订单、用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP分析,数据分发等。
注意:该层的数据普遍呈现出星状结构和高度索引化的。
业务场景:以订单表为例,需要在数据分析平台上体现出“不同商品在不同区域不同客户的热销情况”
需求分析:每个区域每个商品每个客户对应一行销售数据,根据这份数据汇总出一个按区域+商品+客户特征的模型,输出到数据分析平台,展示出不同区域,不同商品的客户特征是怎样的。
解决方案:需要以订单表作为最基础的表,关联上区域表、客户表、商品表,关联出一个以区域+商品+客户特征维度划分的明细数据。
存放数据产品个性化的统计指标数据,根据CDM层与ODS层加工生成。主要是提供给数据产品和数据分析使用的数据。
设计理念:
补充一个维表层,维表层主要包含两部分数据:
笔者目前所在的公司抽象出来了一层视图层,该层数据类似ADS层的理念,主要用来给外部门做分析或者搭建自己的数据集市所用。在该层会着重抽离出用户的PII信息,做一个没有PII信息的视图层。
数据分层的设计,在某种程度上是通过数据命名来体现。数据如何去抽象到不同的层,表如何去设计可以参考如下的设计理念。
一个逻辑或者物理模型由哪些记录和字段组成,应该遵循最基本的软件设计方法论的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑:将业务相近或者相关,粒度相同的数据设计为一个逻辑或者物理模型;将高概率相同访问的数据放在一起,将低概率同时访问的数据分开存储。
建立核心模型与扩展模型体系,核心模型包括的字段支持常用的核心业务,扩展模型包括的字段支持个性化或者少量应用的需要,不能让扩展模型的字段过度侵入核心模型,以免破坏核心模型的架构简洁性与可维护性。
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现,不要让公用的数据处理逻辑暴露给应用层实现,不要让公共逻辑多处同时存在。
适当的数据冗余可换取查询和刷新性能,不宜过度冗余与数据复杂
处理逻辑不变,在不同时间多次运行数据结果确定不变。
具有相同含义的字段在不用表中的命名必须相同,必须使用规范定义中的名称。
表命名需清晰,一致,表名需易于消费者理解和使用。
下图是阿里巴巴构建的全域的公共层数据模型架构图。来源自(阿里巴巴大数据领域建模综述)
阿里巴巴大数据领域建模综述
一种通用的数据仓库分层方法
大数据时代:数据仓库搭建之路