数仓模型设计规则

一、名词定义

1. 指标/度量：具体要分析的对象、分析的数据。例如：满意度、美誉度等数值类型的就是指标。

2. 维度/粒度：观察数据的角度。提供某一业务过程事件涉及用什么过滤和分类的描述属性

3. 维度：按分类区分，横向。如：客户、渠道

4. 粒度：纵向，有大小区分。

5. 模型架构：数仓中维度表与事实表的模型设计。如：星型模型或雪花模型。

6. 数据仓库：决策支持系统和联机分析应用数据源的结构化数据环境。

二、整体架构

整体设计架构图如下：

三、数据分层的意义

1）清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解，使得开发、维护的成本降低；

2）减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算和存储的资源浪费；

3）统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径；

4）复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题。可复用，通用，规模化

5）屏蔽原始数据的异常：屏蔽业务的影响，不必改一次业务就需要重新接入数据。

6）数据血缘追踪：简单来讲可以这样理解，我们最终给业务呈现的是一张能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围

总结：数仓层内部的划分不是为了分层而分层，分层是为了解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题

四、数仓模型设计

1.物理模型设计

数据仓库的物理分层模型设计如下表所示：

1. ODS层（贴源层）

ODS层是数据源中的数据，经过抽取、洗净、传输后装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。为了考虑后续可能追溯数据源问题，因此对这一层不能做数据清洗工作，原封不动接入源数据即可，至于数据的去噪，去重，异常值处理等过程可以放在后面的DW层

建模方式及原则：

• 从业务系统增量抽取；

• 保留时间由业务需求决定；

• 可分表进行周期存储；

• 数据不做清洗转换与业务系统数据模型保持一致；

• 按主题逻辑划分

1. DWD层（数据明细层）

DWD层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理。然后加工成面向数仓的基础明细表。以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可将某些重要属性字段做适当冗余，也即宽表化处理。

数据清洗：去除空值、脏数据、超过极限范围的等等。

建模方式及原则：

• 需要构建维度模型，一般采用星型模型，呈现的状态一般为星座模型（由多个事实表组合，维表是公共的，可被多个事实表共享）；

• 根据维度模型，设计事实表和维度表

例：数字化工厂DWD层

1. DWS层（数据服务层）

DWS层基于DWD上的基础数据，以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表事实表。

这一层会进行轻度汇总，粒度比明细数据稍粗，基于DWD层上的基础数据，整合汇总成分析某一个主题域的服务数据

建模方式及原则：

• 聚合、汇总增加派生事实；

• DWS层应覆盖80%的应用场景，这样我们才能快速响应数据需求

• DWS保持高粒度汇总数据；

• 数据模型可能采用反范式设计，合并信息等。

例：数字化工厂DWS层

1. ADS层（应用服务层）

ADS基于DWS上的数据统计，面向应用逻辑的数据加工。该层主要存放数据产品个性化的统计指标数据，这一层的数据直接对接数据的消费者，是产品、运营等角色可以直接感知理解的一层，大多数这一层的表都可以直接在BI上通过图表的形式直接透出。

分析：数据集市由需求场景驱动建设，方便需求快速查询，改善用户应用体验,提高使用数据的效率

建模方式及原则：

• 维度建模，星形模型；

• 各位维度代理键+度量；

• 增加数据业务日期字段，支持数据重跑；

• 不分表存储。

实现流程：

• 理清需求，了解业务方对数据内容、使用方式(怎么交互的，报表、接口、即席查询、在线查询、指标查询、搜索)、性能的要求。

• 盘点现有的数仓表是否可以支持，看以前有没有类似的需求，有没有可以复用的接口、报表什么的。

• 代码实现，选择合适的存储引擎和查询引擎，配置线上监控然后交付。

1. DIM层（维表层）

建立一致的数据分析维度表、降低数据计算口径和算法不统一的风险。维度表设计的核心是确定维度字段，维度字段是查询约束条件(where)、分组条件(group)、排序(order)，与报表标签的基本来源

DIM层分为两大类维度数据。

• 低基数维度数据：主要是配置表，比如枚举值对应的中文含义，或者日期维表；

• 高基数维度数据：主要是用户资料表、商品资料表类似的资料信息表。

设计原则：

• 维度表一般为单一主键

• 维度表通常比较宽，包含多个属性、是扁平的规范表，维度表应该包括一些有意义的描述，方便下游使用

• 维度表的维度属性，应该尽可能的丰富，所以维度表中，经常出现一些反范式的设计，把其他维度属性并到主维度属性中，达到易用少关联的效果

• 关联维度主要是不同业务系统或者同一业务系统的表之间存在关联性(范式建模)，根据对业务表的梳理，确定哪些表和主维度表之间存在关联关系，并选择其中的某些表用于生成维度属性

• 2、数据表命名规则

• 主要以结合小写的下划线命名法进行命名。

类型	规则	范例	说明
ODS层	(1) 来源系统：ods_ + 源系统+ _+ 源系统表名 (2) 来源填报：ods_ + office+ _+ 源系统表名	(1) ods_oms_productInfo (2) ods_offline_warehouse_rela	(1) OMS商品信息表 (2) OU与W仓库映射表
DWD层	DWD_+主题分类_+事实表名	dwd_fee_channel_recode	渠道费用记录表
DWS层	DWS_+主题分类_+事实表名	dws_fee_channel_day	渠道每日费用表
ADS层	ADS_+主题分类_+应用表名	ads_fee_channel_total	渠道费用汇总表
DIM层	Dim_+维度名称	dim_date	时间维表

如何主题分类？

按业务价值链去区分主题

五、维度模型设计

（维度建模的核心是数据可以抽象为事实和维度，维度即观察事物的角度，事实某一粒度下的度量词，维度一定是针对实体而言的）

维度模型基于Kimball理论。模型按照逻辑架构的不同，分为星型模型、雪花模型、星座模型等类型。根据项目业务场景下在设计逻辑型数据的模型的时候，考虑数据是按照星型模型还是雪花型模型进行组织。

星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余；因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。

雪花模型是对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表，相比星型模型，雪花模型的特点数据冗余较少，但由于表连接的增加，导致了效率相对星型模型来的要低一些。

1. 矩阵图设计

图4.1 主题总线矩阵图1

图4.2 主题总线矩阵图2

1. 多维模型结构设计

维度表和事实表相互独立，又相互关联并构成一个统一的架构。本设计的多维数据集构建的架构主要是星型架构模型，主要是以事实表为核心，各维度围绕这个核心分布。