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