数仓模型设计方法论

大数据_苡~

已于 2024-02-29 00:15:51 修改

阅读量1.4k

点赞数 25

分类专栏： 002-数据仓库文章标签：数据仓库模型设计维度表事实表数仓分层

于 2024-02-28 14:49:37 首次发布

伟绩平凡起，才子复诗流

本文链接：https://blog.csdn.net/weixin_44586883/article/details/136345370

版权

002-数据仓库专栏收录该内容

5 篇文章 1 订阅

订阅专栏

在当今大数据时代，数据已经成为企业最重要的资产之一。而数据仓库作为企业数据管理和分析的核心基础设施，其设计方法论对于企业的数据治理和决策分析至关重要。本文将探索数仓模型设计的方法论，帮助读者更好地理解和应用数仓模型设计。

一、模型规划

1、模型层次规划

分层是以解决当前业务快速的数据支撑为目的，为未来抽象出共性的框架并能够赋能给其他业务线，同时为业务发展提供稳定、准确的数据支撑，并能够按照已有的模型为新业务发展提供方向，也就是数据驱动和赋能。

数仓分层要结合公司业务进行，并且需要清晰明确各层职责，一般采用如下分层结构：

ODS：Operational Data Store，操作数据层，在结构上其与源系统的增量或者全量数据基本保持一致。它相当于一个数据准备区，同时又承担着基础数据的记录以及历史变化。

CDM：Common Data Model，公共维度模型层，又细分为DWD明细粒度事实层、DWS公共汇总粒度事实层和DIM公共维度层。它的主要作用是完成数据加工与整合、建立一致性的维度、构建可复用的面向分析和统计的明细事实表以及汇总公共粒度的指标。

DIM公共维度层：可基于实际业务，存放逻辑模型的维度表；或存放概念模型的维度定义，通过定义维度，确定维度主键，添加维度属性，关联不同维度等操作，建立整个企业的一致性数据分析维表。维度表推荐表名规范：dim_{业务分类}_{数据域}_{自定义内容}_{存储策略}。
DWD明细粒度事实层：以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。您可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当的冗余，即宽表化处理。推荐表名规范：dwd_{业务分类}_{数据域}_{业务过程}_{自定义内容}_{存储策略}。
DWS公共汇总粒度事实层：以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段来物理化模型。推荐表名规范：dws_{业务分类}_{数据域}_{自定义内容}_{时间周期}。

ADS：Application Data Service，应用数据层，以分析的主题对象作为建模驱动，基于公共粒度的汇总指标表，构建直接面向业务分析需求的业务分析指标表。推荐表名规范：ads_{业务分类}_{数据集市}_{主题域}_{自定义内容}_{时间周期}。

2、模型设计原则

高内聚和低耦合

一个逻辑和物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论中的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑：将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。

核心模型与扩展模型分离

建立核心模型与扩展模型体系，核心模型包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化或是少量应用的需要。在必须让核心模型与扩展模型做关联时，不能让扩展字段过度侵入核心模型，以免破坏了核心模型的架构简洁性与可维护性。

公共处理逻辑下沉及单一

底层公用的处理逻辑应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑在多处同时存在。

成本与性能平衡

适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。

数据可回滚

处理逻辑不变，在不同时间多次运行数据的结果需确定不变。

一致性

相同的字段在不同表中的字段名必须相同。

命名清晰可理解

表命名规范需清晰、一致，表命名需易于下游的理解和使用。

二、维度建模方法论

1、维度表

维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实”，将环境描述为“维度”，维度是用于分析事实所需要的多样环境。

维度表的基本设计方法

第一步：选择维度或者新建维度。作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。
第二步：确定主维度。主维表一般是ODS表，直接与业务系统同步。
第三步：确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。
第四步：确定维度属性。本步骤主要包括两个阶段，其中第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。

2、事实表

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。

事实表有三种类型：事务事实表、周期快照事实表和累积快照事实表。事务事实表用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为“原子事实表”。周期快照事实表以具有规律性的、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。

事实表设计原则

需统一规定不同的数据的数据类型，严格按照规定的数据类型执行：

事实表设计方法

第一步：选择业务过程及确定事实表类型。在明确了业务需求以后，接下来需要进行详细的需求分析，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求有关的业务过程。
第二步：声明粒度。粒度的声明是事实表建模非常重要的一步，意味着精确定义事实表的每一行所表示的业务含义，粒度传递的是与事实表度量有关的细节层次。明确的粒度能确保对事实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录。应该尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。同时对于订单过程而言，粒度可以被定义为最细的订单级别。
第三步：确定维度。完成粒度声明以后，也就意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了，应该选择能够描述清楚业务过程所处的环境的维度信息。
第四步：确定事实。事实可以通过回答“过程的度量是什么”来确定。应该选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致。事实有可加性、半可加性、非可加性三种类型，需要将不可加性事实分解为可加的组件。
第五步：冗余维度。在大数据的事实表模型设计中，考虑更多的是提高下游用户的使用效率，降低数据获取的复杂性，减少关联的表数量。所以通常事实表中会冗余方便下游用户使用的常用维度，以实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等操作。

事务性事实表

事务性事实表可分为单事务事实表和多事务事实表。

单事务事实表，顾名思义，即针对每个业务过程设计一个事实表。这样设计的优点不言而喻，可以方便地对每个业务过程进行独立的分析研究。

多事务事实表，将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程。多事务事实表在设计时有两种方法进行事实的处理：①不同业务过程的事实使用不同的事实字段进行存放；②不同业务过程的事实使用同一个事实字段进行存放，但增加一个业务过程标签。

当不同业务过程的度量比较相似、差异不大时，可以采用第二种多事务事实表的设计方式，使用同一个字段来表示度量数据。但这种方式存在一个问题——在同一个周期内会存在多条记录。
当不同业务过程的度量差异较大时，可以选择第一种多事务事实表的设计方式，将不同业务过程的度量使用不同字段冗余到表中，非当前业务过程则置零表示。这种方式所存在的问题是度量字段零值较多。

周期快照事实表

周期快照事实表，简称“快照事实表”。快照事实表在确定的间隔内对实体的度量进行抽样，这样可以很容易地研究实体的度量值，而不需要聚集长期的事务历史。

快照事实表的设计有一些区别于事务事实表设计的性质。事务事实表的粒度能以多种方式表达，但快照事实表的粒度通常以维度形式声明；事务事实表是稀疏的，但快照事实表是稠密的；事务事实表中的事实是完全可加的，但快照模型将至少包含一个用来展示半可加性质的事实。

累计快照事实表

对于类似于研究事件之间时间间隔的需求，采用累积快照事实表可以很好地解决。

三种事实表对比

事务事实表记录的事务层面的事实，用于跟踪业务过程的行为，并支持几种描述行为的事实，保存的是最原子的数据，也称为“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不能更改，其更新方式为增量更新。

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，如余额、库存、层级、温度等，时间间隔为每天、每月、每年等，典型的例子如库存日快照表等。周期快照事实表的日期维度通常记录时间段的终止日，记录的事实是这个时间段内一些聚集事实值或状态度量。事实表的数据一旦插入就不能更改，其更新方式为增量更新。

累积快照事实表被用来跟踪实体的一系列业务过程的进展情况，它通常具有多个日期字段，用于研究业务过程中的里程碑过程的时间间隔。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，而且这类事实表在数据加载完成后，可以对其数据进行更新，来补充业务状态变更时的日期信息和事实。

三、实施方法论

1、业务调研

业务调研是了解企业当前业务运作情况、业务目标和业务流程的过程。在数据仓库建设过程中，业务调研有助于确立数据仓库的定位和目标，为后续的数据建模和ETL开发提供指导。

确定调研范围：明确调研的具体范围和目的，包括调研的业务部门、业务流程和关键业务指标等。
收集业务信息：与业务部门的相关人员进行沟通，了解他们的工作内容、业务需求和数据使用情况，同时收集相关的业务文档和报表等资料。
分析业务流程：分析企业的业务流程，了解数据产生和流转的路径，找出数据仓库需要涵盖的业务过程和环节。
识别关键业务指标：确定关键的业务指标和业绩考核指标，明确数据仓库需要支持的业务分析需求，为后续的数据建模和报表设计奠定基础。

2、数据域划分

划分数据域可以更好地管理数据，提高数据的利用率，降低数据冗余度、帮助企业更好地了解自己的业务。数据域面向业务分析，可以概括为一个个不可拆分的行为事件。在划分数据域时，既能涵盖当前所有业务需求，又能在新业务拓展时无影响的被包含进已有的数据域中和扩展新的数据域。

数据域示例：

数据域	说明
消费者域	包含访客注册、会员登录等相关行为的数据。
商品域	包含商家对商品进行入库、上架、下架等相关行为的数据。
交易域	包含所有消费者和商家之间的交易行为如加购、下单、支付等相关的数据。