大数据建模理论

文章目录

一、数仓概述
- 1、数据仓库概念
- - [1.1 概述](#1.1 概述)
  - [1.2 数据仓库与数据库的区别](#1.2 数据仓库与数据库的区别)
  - [1.3 技术选型和架构](#1.3 技术选型和架构)
- 2、数仓常见名词
- - [2.1 实体](#2.1 实体)
  - [2.2 维度](#2.2 维度)
  - [2.3 度量](#2.3 度量)
  - [2.4 粒度](#2.4 粒度)
  - [2.5 口径](#2.5 口径)
  - [2.6 指标](#2.6 指标)
  - [2.7 标签](#2.7 标签)
  - [2.8 自然键/持久键/代理键](#2.8 自然键/持久键/代理键)
  - [2.9 退化维度](#2.9 退化维度)
  - [2.10 下钻/上卷](#2.10 下钻/上卷)
  - [2.11 数据集市](#2.11 数据集市)
- 3、数仓名词之间关系
- - [3.1 实体表，事实表，维度表之间的关系](#3.1 实体表，事实表，维度表之间的关系)
  - [3.2 指标与标签的区别](#3.2 指标与标签的区别)
  - [3.3 维度和指标区别与联系](#3.3 维度和指标区别与联系)
  - [3.4 自然键与代理键在数仓的使用区别](#3.4 自然键与代理键在数仓的使用区别)
  - [3.5 数据集市和数据仓库的关系](#3.5 数据集市和数据仓库的关系)
二、离线数仓相关核心概念
- 1、数据仓库分层
- - [1.1 概述与原则](#1.1 概述与原则)
  - [1.2 数据源层：ODS（Operational Data Store）](#1.2 数据源层：ODS（Operational Data Store）)
  - [1.3 数据仓库层：DW（Data Warehouse）](#1.3 数据仓库层：DW（Data Warehouse）)
  - [1.4 维表层：DIM（Dimension）](#1.4 维表层：DIM（Dimension）)
  - [1.5 数据应用层：ADS（Application Data Services）](#1.5 数据应用层：ADS（Application Data Services）)
- 2、数仓建模方法概述
- - [2.1 范式建模法（Third Normal Form，3NF）](#2.1 范式建模法（Third Normal Form，3NF）)
  - [2.2 维度建模法（Dimensional Modeling）](#2.2 维度建模法（Dimensional Modeling）)
  - [2.3 实体建模法（Entity Modeling）](#2.3 实体建模法（Entity Modeling）)
- 3、维度建模详解
- - [3.1 概述](#3.1 概述)
  - [3.2 事实表详解](#3.2 事实表详解)
  - [3.3 维度表](#3.3 维度表)
  - [3.5 维度建模三种模式](#3.5 维度建模三种模式)
  - [3.6 维度建模过程](#3.6 维度建模过程)
- 4、维度建模理论之维度表
- - [4.1 维度表设计步骤](#4.1 维度表设计步骤)
  - [4.2 维度变化](#4.2 维度变化)
  - [4.3 多值维度](#4.3 多值维度)
  - [4.4 多值属性](#4.4 多值属性)
- 5、数据仓库设计
- - [5.1 数据仓库构建流程](#5.1 数据仓库构建流程)
  - [5.2 数据调研](#5.2 数据调研)
  - [5.3 明确数据域](#5.3 明确数据域)
  - [5.4 构建业务总线矩阵](#5.4 构建业务总线矩阵)
  - [5.5 明确统计指标](#5.5 明确统计指标)
  - [5.6 维度模型设计](#5.6 维度模型设计)
  - [5.7 汇总模型设计](#5.7 汇总模型设计)

一、数仓概述

1、数据仓库概念

1.1 概述

通常数据仓库的数据来自各个业务应用系统。业务系统中的数据形式多种多样，可能是 Oracle、MySQL、SQL Server等关系数据库里的结构化数据，可能是文本、CSV等平面文件或Word、Excel文档中的数据，还可能是HTML、XML等自描述的半结构化数据。这些业务数据经过一系列的数据抽取、转换、清洗，最终以一种统一的格式装载进数据仓库。数据仓库里的数据作为分析用的数据源，提供给后面的即席查询、分析系统、数据集市、报表系统、数据挖掘系统等。

1.2 数据仓库与数据库的区别

数据仓库在设计是有意引入冗余，依照分析需求，分析维度、分析指标进行设计
数据库是为捕获数据而设计，数据仓库是为分析数据而设计

数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的"大型数据库"

1.3 技术选型和架构

离线和实时数仓一般架构

2、数仓常见名词

2.1 实体

实体是指依附的主体，就是我们分析的一个对象，比如我们分析商品的销售情况，如华为手机近半年的销售量是多少，那华为手机就是一个实体；我们分析用户的活跃度，用户就是一个实体。当然实体也可以现实中不存在的，比如虚拟的业务对象，活动，会员等都可看做一个实体。

实体的存在是为了业务分析，作为分析的一个筛选的维度，拥有描述自己的属性，本身具有可分析的价值

2.2 维度

维度就是看待问题的角度，分析业务数据，从什么角度分析，就建立什么样的维度。所以维度就是要对数据进行分析时所用的一个量，比如你要分析产品销售情况，你可以选择按商品类别来进行分析，这就构成一个维度，把所有商品类别集合在一起，就构成了维度表

2.3 度量

度量是业务流程节点上的一个数值。比如销量，价格，成本等等。事实表中的度量可分为三类：完全可加，半可加，不可加。

完全可加的度量是最灵活，最有用的，比如说销量，销售额等，可进行任意维度汇总；
半可加的度量可以对某些维度汇总，但不能对所有维度汇总，差额是常见的半可加度量，它除了时间维度外，可以跨所有维度进行加法操作；
还有一种是完全不可加的，例如：比率。对于这类非可加度量，一种好的方法是，尽可能存储非可加度量的完全可加分量，并在计算出最终的非可加事实前，将这些分量汇总到最终的结果集中。

2.4 粒度

粒度就是业务流程中对度量的单位，比如商品是按件记录度量，还是按批记录度量。在数仓建设中，我们说这是用户粒度的事实表，那么表中每行数据都是一个用户，无重复用户；例如还有销售粒度的表，那么表中每行都是一条销售记录。

选择合适的粒度级别是数据仓库建设好坏的重要关键内容，在设计数据粒度时，通常需重点考虑以下因素：

要接受的分析类型、可接受的数据最低粒度和能存储的数据量；
粒度的层次定义越高，就越不能在该仓库中进行更细致的分析；
如果存储资源有一定的限制，就只能采用较高的数据粒度划分；
数据粒度划分策略一定要保证：数据的粒度确实能够满足用户的决策分析需要，这是数据粒度划分策略中最重要的一个准则。

2.5 口径

口径就是取数逻辑（如何取数的） ，比如要取的数是10岁以下儿童中男孩的平均身高，这就是统计的口径。

2.6 指标

指标是口径的衡量值，也就是最后的结果。比如最近七天的订单量，一个促销活动的购买转化率等。一个指标具体到计算实施，主要有以下几部分组成：

指标加工逻辑，比如count ,sum, avg
维度，比如按部门、地域进行指标统计，对应sql中的group by
业务限定/修饰词，比如以不同的支付渠道来算对应的指标，微信支付的订单退款率，支付宝支付的订单退款率。对应sql中的where。

除此之外，指标本身还可以衍生、派生出更多的指标，基于这些特点，可以将指标进行分类：

原子指标：基本业务事实，没有业务限定、没有维度。比如订单表中的订单量、订单总金额都算原子指标；

业务方更关心的指标，是有实际业务含义，可以直接取数据的指标。比如店铺近1天订单支付金额就是一个派生指标，会被直接在产品上展示给商家看。但是这个指标却不能直接从数仓的统一中间层里取数（因为没有现成的事实字段，数仓提供的一般都是大宽表）。需要有一个桥梁连接数仓中间层和业务方的指标需求，于是便有了派生指标
派生指标 ：维度+修饰词+原子指标。店铺近1天订单支付金额中店铺是维度，近1天是一个时间类型的修饰词，支付金额是一个原子指标；

维度：观察各项指标的角度；修饰词：维度的一个或某些值，比如维度性别下，男和女就是2种修饰词。
衍生指标 ：比如某一个促销活动的转化率就是衍生指标，因为需要促销投放人数指标和促销订单数指标进行计算得出

2.7 标签

标签是人为设定的、根据业务场景需求，对目标对象运用一定的算法得到的高度精炼的特征标识。可见标签是经过人为再加工后的结果，如网红、白富美、萝莉。对于有歧义的标签，我们内部可进行标签区分，比如：苹果，我们可以定义苹果指的是水果，苹果手机才指的是手机

2.8 自然键/持久键/代理键

自然键：由现实中已经存在的属性组成的键，它在业务概念中是唯一的，并具有一定的业务含义，比如商品ID，员工ID。以数仓角度看，来自于业务系统的标识符就是自然键，比如业务库中员工的编号
持久键：保持永久性不会发生变化。有时也被叫做超自然持久键。比如身份证号属于持久键

自然键和持久键区别：比如说公司员工离职之后又重新入职，他的自然键也就是员工编号发生了变化，但是他的持久键身份证号是不变的。

代理键 ：就是不具有业务含义的键。代理键有许多其他的称呼：无意义键、整数键、非自然键、人工键、合成键等。代理键就是简单的以按照顺序序列生产的整数表示。产品行的第1行代理键为1，则下一行的代理键为2，如此进行。代理键的作用仅仅是连接维度表和事实表。

2.9 退化维度

退化维度，就是那些看起来像是事实表的一个维度关键字，但实际上并没有对应的维度表，就是维度属性存储到事实表中，这种存储到事实表中的维度列被称为退化维度。与其他存储在维表中的维度一样，退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。

那么究竟怎么定义退化维度呢？比如说订单id，这种量级很大的维度，没必要用一张维度表来进行存储，而我们进行数据查询或者数据过滤的时候又非常需要，所以这种就冗余在事实表里面，这种就叫退化维度，citycode这种我们也会冗余在事实表里面，但是它有对应的维度表，所以它不是退化维度

2.10 下钻/上卷

下钻：这是在数据分析中常见的概念，下钻可以理解成增加维的层次，从而可以由粗粒度到细粒度来观察数据，比如对产品销售情况分析时，可以沿着时间维从年到月到日更细粒度的观察数据。从年的维度可以下钻到月的维度、日的维度等

知道了下钻，上卷就容易理解了，它俩是相逆的操作，所以上卷可以理解为删掉维的某些层，由细粒度到粗粒度观察数据的操作或沿着维的层次向上聚合汇总数据。

2.11 数据集市

数据集市（Data Mart），也叫数据市场，数据集市就是满足特定的部门或者用户的需求，按照多维的方式进行存储，包括定义维度、需要计算的指标、维度的层次等，生成面向决策分析需求的数据立方体。其实就是从数据仓库中抽取出来的一个小合集。

3、数仓名词之间关系

3.1 实体表，事实表，维度表之间的关系

维度表：维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述，比如时间维度表，地域维度表，维度表是事实表的一个分析角度
事实表：事实表其实就是通过各种维度和一些指标值的组合来确定一个事实的，比如通过时间维度，地域组织维度，指标值可以去确定在某时某地的一些指标值怎么样的事实。事实表的每一条数据都是几条维度表的数据和指标值交汇而得到的。
实体表：实体表就是一个实际对象的表，实体表放的数据一定是一条条客观存在的事物数据，比如说各种商品，它就是客观存在的，所以可以将其设计一个实体表。实时表只描述各个事物，并不存在具体的事实，所以也有人称实体表是无事实的事实表。

举个例子：比如说手机商场中有苹果手机，华为手机等各品牌各型号的手机，这些数据可以组成一个手机实体表 ，但是表中没有可度量的数据。某天苹果手机卖了15台，华为手机卖了20台，这些手机销售数据属于事实，组成一个事实表 。这样就可以使用日期维度表 和地域维度表对这个事实表进行各种维度分析。

3.2 指标与标签的区别

概念不同

指标是用来定义、评价和描述特定事物的一种标准或方式。比如：新增用户数、累计用户数、用户活跃率等是衡量用户发展情况的指标；

标签是人为设定的、根据业务场景需求，对目标对象运用一定的算法得到的高度精炼的特征标识。可见标签是经过人为再加工后的结果，如网红、白富美、萝莉。

构成不同

指标名称是对事物质与量两方面特点的命名；指标取值是指标在具体时间、地域、条件下的数量表现，如人的体重，指标名称是体重，指标的取值就是120斤；

标签名称通常都是形容词或形容词+名词的结构，标签一般是不可量化的，通常是孤立的，除了基础类标签，通过一定算法加工出来的标签一般都没有单位和量纲。如将超过200斤的称为大胖子。

分类不同

对指标的分类：按照指标计算逻辑，可以将指标分为原子指标、派生指标、衍生指标三种类型；按照对事件描述内容的不同，分为过程性指标和结果性指标；

对标签的分类：按照标签的变化性分为静态标签和动态标签；按照标签的指代和评估指标的不同，可分为定性标签和定量标签；

指标最擅长的应用是监测、分析、评价和建模。标签最擅长的应用是标注、刻画、分类和特征提取。特别需要指出的是，由于对结果的标注也是一种标签，所以在自然语言处理和机器学习相关的算法应用场景下，标签对于监督式学习有重要价值，只是单纯的指标难以做到的。而指标在任务分配、绩效管理等领域的作用，也是标签无法做到的。

3.3 维度和指标区别与联系

维度就是数据的观察角度，即从哪个角度去分析问题，看待问题。指标就是从维度的基础上去衡算这个结果的值。

维度一般是一个离散的值，比如时间维度上每一个独立的日期或地域，因此统计时，可以把维度相同记录的聚合在一起，应用聚合函数做累加、均值、最大值、最小值等聚合计算。指标就是被聚合的通计算，即聚合运算的结果，一般是一个连续的值

3.4 自然键与代理键在数仓的使用区别

数仓工具箱中说维度表的唯一主键应该是代理键而不应该是自然键。有时建模人员不愿意放弃使用自然键，因为他们希望与操作型代码查询事实表，而不希望与维度表做连接操作。然而，应该避免使用包含业务含义的多维键，因为不管我们做出任何假设最终都可能变得无效，因为我们控制不了业务库的变动。

所以数据仓库中维度表与事实表的每个连接应该基于无实际含义的整数代理键。避免使用自然键作为维度表的主键。

3.5 数据集市和数据仓库的关系

数据集市是企业级数据仓库的一个子集，他主要面向部门级业务，并且只面向某个特定的主题。为了解决灵活性和性能之间的矛盾，数据集市就是数据仓库体系结构中增加的一种小型的部门或工作组级别的数据仓库。数据集市存储为特定用户预先计算好的数据，从而满足用户对性能的需求。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。

数据集市和数据仓库的主要区别：数据仓库是企业级的，能为整个企业各个部门的运行提供决策支持手段；而数据集市则是一种微型的数据仓库,它通常有更少的数据,更少的主题区域,以及更少的历史数据,因此是部门级的，一般只能为某个局部范围内的管理人员服务，因此也称之为部门级数据仓库。

二、离线数仓相关核心概念

1、数据仓库分层

1.1 概述与原则

为便于数据分析，要屏蔽底层复杂业务，简单、完整、集成的将数据暴露给分析层
底层业务变动与上层需求变动对模型冲击最小化，业务系统变化影响削弱在基础数据层，结合自上而下的建设方法削弱需求变动对模型的影响
高内聚松耦合，即主题之内或各个完整意义的系统内数据的高内聚，主题之间或各个完整意义的系统间数据的松耦合
构建仓库基础数据层，使底层业务数据整合工作与上层应用开发工作相隔离，为仓库大规模开发奠定基础仓库层次更加清晰，对外暴露数据更加统一

1.2 数据源层：ODS（Operational Data Store）

ODS 层，是最接近数据源中数据的一层，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的 DWD 层来做

1.3 数据仓库层：DW（Data Warehouse）

数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。DW 层又细分为 DWD （Data Warehouse Detail）层、DWM （Data WareHouse Middle）层和 DWS（Data WareHouse Servce）层

数据明细层：DWD（Data Warehouse Detail）

该层一般保持和 ODS 层一样的数据粒度，并且提供一定的数据质量保证。DWD 层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理 。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性

数据中间层：DWM（Data WareHouse Middle）

该层会在 DWD 层的数据基础上，数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。

在实际计算中，如果直接从 DWD 或者 ODS 计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在 DWM 层先计算出多个小的中间表，然后再拼接成一张 DWS 的宽表。由于宽和窄的界限不易界定，也可以去掉 DWM 这一层，只留 DWS 层，将所有的数据再放在 DWS 亦可

数据服务层：DWS（Data WareHouse Servce）

DWS 层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，基于 DWD 层上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是宽表。DWS 层应覆盖 80% 的应用场景。又称数据集市或宽表。按照业务划分，如主题域流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP 分析，数据分发等。

一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表

1.4 维表层：DIM（Dimension）

如果维表过多，也可针对维表设计单独一层，维表层主要包含两部分数据：

高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万

1.5 数据应用层：ADS（Application Data Services）

主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、 PostgreSql、Redis 等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

2、数仓建模方法概述

2.1 范式建模法（Third Normal Form，3NF）

范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库的数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。

范式是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则，而在关系型数据库中这种规则就是范式，这一过程也被称为规范化。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF）。在数据仓库的模型设计中，一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件 :

每个属性值唯一，不具有多义性 ;
每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。

2.2 维度建模法（Dimensional Modeling）

维度模型是数据仓库领域另一位大师Ralph Kimall所倡导，他的《数据仓库工具箱》是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。

典型的代表是我们比较熟知的星形模型（Star-schema） ，以及在一些特殊场景下适用的雪花模型（Snow-schema） 。维度建模中比较重要的概念就是 事实表（Fact table）和维度表（Dimension table）。其最简单的描述就是，按照事实表、维度表来构建数据仓库、数据集市。

2.3 实体建模法（Entity Modeling）

实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。

虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分，实体，事件，说明

3、维度建模详解

3.1 概述

维度建模分为两种表：事实表和维度表：

事实表：必然存在的一些数据，像采集的日志文件，订单表，都可以作为事实表。

特征：是一堆主键的集合，每个主键对应维度表中的一条记录，客观存在的，根据主题确定出需要使用的数据
维度表：维度就是所分析的数据的一个量，维度表就是以合适的角度来创建的表，分析问题的一个角度：时间、地域、终端、用户等角度

3.2 事实表详解

发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表行对应一个度量事件，反之亦然。事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实

图中的订单表就是一个事实表，你可以理解他就是在现实中发生的一次操作型事件，我们每完成一个订单，就会在订单中增加一条记录。事实表的特征：表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录。事实表包含了与各维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表数据规模迅速增长

明细表（宽表）

事实表的数据中，有些属性共同组成了一个字段（糅合在一起），比如年月日时分秒构成了时间,当需要根据某一属性进行分组统计的时候，需要截取拼接之类的操作，效率极低。为了分析方便，可以事实表中的一个字段切割提取多个属性出来构成新的字段，因为字段变多了，所以称为宽表，原来的成为窄表；又因为宽表的信息更加清晰明细，所以也可以称之为明细表

事实表种类分为六类

事务事实表

表中的一行对应空间或时间上某点的度量事件。就是一行数据中必须有度量字段，什么是度量，就是指标，比如说销售金额，销售数量等这些可加的或者半可加就是度量值。另一点就是事务事实表都包含一个与维度表关联的外键。并且度量值必须和事务粒度保持一致

周期快照事实表

顾名思义，周期事实表就是每行都带有时间值字段，代表周期，通常时间值都是标准周期，如某一天，某周，某月等。粒度是周期，而不是个体的事务，也就是说一个周期快照事实表中数据可以是多个事实，但是它们都属于某个周期内

累计快照事实表

周期快照事实表是单个周期内数据，而累计快照事实表是由多个周期数据组成，每行汇总了过程开始到结束之间的度量。每行数据相当于管道或工作流，有事件的起点，过程，终点，并且每个关键步骤都包含日期字段。如订单数据，累计快照事实表的一行就是一个订单，当订单产生时插入一行，当订单发生变化时，这行就被修改

无事实的事实表

我们以上讨论的事实表度量都是数字化的，当然实际应用中绝大多数都是数字化的度量，但是也可能会有少量的没有数字化的值但是还很有价值的字段，无事实的事实表就是为这种数据准备的，利用这种事实表可以分析发生了什么。

聚集事实表

聚集，就是对原子粒度的数据进行简单的聚合操作，目的就是为了提高查询性能。如我们需求是查询全国所有门店的总销售额，我们原子粒度的事实表中每行是每个分店每个商品的销售额，聚集事实表就可以先聚合每个分店的总销售额，这样汇总所有门店的销售额时计算的数据量就会小很多。

合并事实表

这种事实表遵循一个原则，就是相同粒度，数据可以来自多个过程，但是只要它们属于相同粒度，就可以合并为一个事实表，这类事实表特别适合经常需要共同分析的多过程度量

3.3 维度表

每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。维度表示你要对数据进行分析时所用的一个量，比如你要分析产品销售情况，你可以选择按类别来进行分析，或按区域来分析。每个类别就构成一个维度。上图中的用户表、商家表、时间表这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。

总的说来，在数据仓库中不需要严格遵守规范化设计原则。因为数据仓库的主导功能就是面向分析，以查询为主，不涉及数据更新操作。事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。

维度表结构

维度表谨记一条原则，包含单一主键列，但有时因业务复杂，也可能出现联合主键，请尽量避免，如果无法避免，也要确保必须是单一的，这很重要，如果维表主键不是单一，和事实表关联时会出现数据发散，导致最后结果可能出现错误。维度表通常比较宽，包含大量的低粒度的文本属性。

跨表钻取

跨表钻取意思是当每个查询的行头都包含相同的一致性属性时，使不同的查询能够针对两个或更多的事实表进行查询，钻取可以改变维的层次，变换分析的粒度。它包括上钻/下钻：

上钻（roll-up）：上卷是沿着维的层次向上聚集汇总数据。例如，对产品销售数据，沿着时间维上卷，可以求出所有产品在所有地区每月（或季度或年或全部）的销售额。

下钻（drill-down）：下钻是上钻的逆操作，它是沿着维的层次向下，查看更详细的数据。

退化维度

退化维度就是将维度退回到事实表中。因为有时维度除了主键没有其他内容，虽然也是合法维度键，但是一般都会退回到事实表中，减少关联次数，提高查询性能

多层次维度

多数维度包含不止一个自然层次，如日期维度可以从天的层次到周到月到年的层次。所以在有些情况下，在同一维度中存在不同的层次。

维度表空值属性

当给定维度行没有被全部填充时，或者当存在属性没有被应用到所有维度行时，将产生空值维度属性。上述两种情况，推荐采用描述性字符串代替空值，如使用 unknown 或 not applicable 替换空值。

日历日期维度

在日期维度表中，主键的设置不要使用顺序生成的id来表示，可以使用更有意义的数据表示，比如将年月日合并起来表示，即YYYYMMDD，或者更加详细的精度

3.5 维度建模三种模式

规范化是指使用一系列范式设计数据库的过程，其目的是减少数据冗余，增强数据的一致性。通常情况下，规范化之后，一张表的字段会拆分到多张表。

反规范化是指将多张表的数据冗余到一张表，其目的是减少join操作，提高查询性能。在设计维度表时，如果对其进行规范化，得到的维度模型称为雪花模型，如果对其进行反规范化，得到的模型称为星型模型

星型模式

星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点： a. 维表只和事实表关联，维表之间没有关联； b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键； c. 以事实表为核心，维表围绕核心呈星形

雪花模式

雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用

星座模式

星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在_业务发展后期，绝大部分维度建模都采用的是星座模式_

3.6 维度建模过程

1、选择业务过程

维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取我们需要建模的业务，根据运营提供的需求及日后的易扩展性等进行选择业务。比如商城，整个商城流程分为商家端，用户端，平台端，运营需求是总订单量，订单人数，及用户的购买情况等，我们选择业务过程就选择用户端的数据，商家及平台端暂不考虑。业务选择非常重要，因为后面所有的步骤都是基于此业务数据展开的。

2、声明粒度

先举个例子：对于用户来说，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡，那么与用户粒度相同的粒度属性有身份证粒度，户籍地址粒度，比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是相同粒度。为什么要提相同粒度呢，因为维度建模中要求我们，在同一事实表 中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始设计，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要的，所以对于有明确需求的数据，我们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。

3、确认维度

维度表是作为业务分析的入口和描述性标识，所以也被称为数据仓库的"灵魂"。在一堆的数据中怎么确认哪些是维度属性呢，如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性，数仓工具箱中告诉我们牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开 ，并且要确保维度表中不能出现重复数据，应使维度主键唯一

4、确认事实

事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度 。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。

4、维度建模理论之维度表

4.1 维度表设计步骤

确定维度（表）

在设计事实表时，已经确定了与每个事实表相关的维度，理论上每个相关维度均需对应一张维度表。需要注意到，可能存在多个事实表与同一个维度都相关的情况，这种情况需保证维度的唯一性，即只创建一张维度表。另外，如果某些维度表的维度属性很少，例如只有一个名称，则可不创建该维度表，而把该表的维度属性直接增加到与之相关的事实表中，这个操作称为维度退化

确定主维表和相关维表

此处的主维表和相关维表均指业务系统中与某维度相关的表。例如业务系统中与商品相关的表有sku_info，spu_info，base_trademark，base_category3，base_category2，base_category1等，其中sku_info就称为商品维度的主维表，其余表称为商品维度的相关维表。维度表的粒度通常与主维表相同。

确定维度属性

确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表。维度属性可直接从主维表或相关维表中选择，也可通过进一步加工得到。确定维度属性时，需要遵循以下要求：

（1）尽可能生成丰富的维度属性。维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源，是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。

（2）尽量不使用编码，而使用明确的文字说明，一般可以编码和文字共存。

**（3）尽量沉淀出通用的维度属性。**有些维度属性的获取需要进行比较复杂的逻辑处理，例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理，可将这些维度属性沉淀到维度表中

4.2 维度变化

维度属性通常不是静态的，而是会随时间变化的，数据仓库的一个重要特点就是反映历史的变化，所以如何保存维度的历史状态是维度设计的重要工作之一。保存维度数据的历史状态，通常有以下两种做法，分别是全量快照表和拉链表。

1）全量快照表

离线数据仓库的计算周期通常为每天一次，所以可以每天保存一份全量的维度数据。这种方式的优点和缺点都很明显。

优点是简单而有效，开发和维护成本低，且方便理解和使用。

缺点是浪费存储空间，尤其是当数据的变化比例比较低时。

2）拉链表

拉链表的意义就在于能够更加高效的保存维度信息的历史状态。拉链表，记录每条信息的生命周期 ，一旦一条记录的生命周期结束，就重新开始一条新的记录，并把当前日期放入生效开始日期。如果当前信息至今有效，在生效结束日期中填入一个极大值（如9999-12-31 )。

4.3 多值维度

如果事实表中一条记录在某个维度表中有多条记录与之对应，称为多值维度。例如，下单事实表中的一条记录为一个订单，一个订单可能包含多个商品，所会商品维度表中就可能有多条数据与之对应。针对这种情况，通常采用以下两种方案解决。

第一种：降低事实表的粒度，例如将订单事实表的粒度由一个订单降低为一个订单中的一个商品项。

第二种：在事实表中采用多字段保存多个维度值，每个字段保存一个维度id。这种方案只适用于多值维度个数固定的情况。

建议尽量采用第一种方案解决多值维度问题。

4.4 多值属性

维表中的某个属性同时有多个值，称之为"多值属性"，例如商品维度的平台属性和销售属性，每个商品均有多个属性值。针对这种情况，通常有可以采用以下两种方案。

第一种：将多值属性放到一个字段，该字段内容为key1:value1，key2:value2的形式，例如一个手机商品的平台属性值为"品牌:华为，系统:鸿蒙，CPU:麒麟990"。

第二种：将多值属性放到多个字段，每个字段对应一个属性。这种方案只适用于多值属性个数固定的情况

5、数据仓库设计

5.1 数据仓库构建流程

5.2 数据调研

业务调研的主要目标是熟悉业务流程 、熟悉业务数据，例如

分析需求时，需要明确需求所需的业务过程 及维度，例如该需求所需的业务过程就是买家下单，所需的维度有日期，省份，商品品类。做完业务分析和需求分析之后，要保证每个需求都能找到与之对应的业务过程及维度。若现有数据无法满足需求，则需要和业务方进行沟通，例如某个页面需要新增某个行为的埋点

5.3 明确数据域

数据仓库模型设计除横向的分层外，通常也需要根据业务情况进行纵向划分数据域。划分数据域的意义是便于数据的管理和应用。通常可以根据业务过程或者部门进行划分，本项目根据业务过程进行划分，需要注意的是一个业务过程只能属于一个数据域。下面是本数仓项目所需的所有业务过程及数据域划分详情

数据域	业务过程
交易域	加购、下单、取消订单、支付成功、退单、退款成功
流量域	页面浏览、启动应用、动作、曝光、错误
用户域	注册、登录
互动域	收藏、评价
工具域	优惠券领取、优惠券使用（下单）、优惠券使用（支付）

5.4 构建业务总线矩阵

业务总线矩阵中包含维度模型所需的所有事实（业务过程）以及维度，以及各业务过程与各维度的关系。矩阵的行是一个个业务过程，矩阵的列是一个个的维度，行列的交点表示业务过程与维度的关系

一个业务过程对应维度模型中一张事务型事实表，一个维度则对应维度模型中的一张维度表。所以构建业务总线矩阵的过程就是设计维度模型的过程。但是需要注意的是，总线矩阵中通常只包含事务型事实表，另外两种类型的事实表需单独设计。按照事务型事实表的设计流程，选择业务过程à 声明粒度à 确认维度à确认事实

5.5 明确统计指标

原子指标

原子指标基于某一业务过程 的度量值 ，是业务定义中不可再拆解的指标，原子指标的核心功能就是对指标的聚合逻辑进行了定义。我们可以得出结论，原子指标包含三要素，分别是业务过程、度量值和聚合逻辑。

例如订单总额就是一个典型的原子指标，其中的业务过程为用户下单、度量值为订单金额，聚合逻辑为sum()求和。需要注意的是原子指标只是用来辅助定义指标一个概念，通常不会对应有实际统计需求与之对应。

派生指标

衍生指标

衍生指标是在一个或多个派生指标的基础上，通过各种逻辑运算复合而成的。例如比率、比例等类型的指标。衍生指标也会对应实际的统计需求

当统计需求足够多时，必然会出现部分统计需求对应的派生指标相同的情况。这种情况下，我们就可以考虑将这些公共的派生指标保存下来，这样做的主要目的就是减少重复计算，提高数据的复用性。这些公共的派生指标统一保存在数据仓库的DWS层。因此DWS层设计，就可以参考我们根据现有的统计需求整理出的派生指标

5.6 维度模型设计

维度模型的设计参照上述得到的业务总线矩阵即可。事实表存储在DWD层，维度表存储在DIM层

5.7 汇总模型设计

汇总模型的设计参考上述整理出的指标体系（主要是派生指标）即可。汇总表与派生指标的对应关系是，一张汇总 表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标