数仓建模的4种方法论

1、数据仓库建模的目的？

大数据的数仓建模，是通过建模的方法，从业务和数据分析使用的角度出发，更合理的、高效的组织和存储数据。同时分层后的数据，拥有更加完整的数据体系，清晰的数据结构。能够有效提高数据获取、统计和分析的效率，进一步为业务发挥出数据的价值。

每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。具体可以从以下几个方面体现：
1、DWD明细层：
1）解决数据集成和数据质量问题：集成不同源系统的数据，并将其进行整合，消除异构性和冗余性，提供一致的数据；对数据进行统一清洗、转换和加工，屏蔽脏数据；字段命名的统一规范化；
2）支持决策分析：原子级别的明细数据，可以支持更深入和准确的决策分析。通过明细层校验应用层的指标准确性。
2、DWS轻度汇总层：
1）沉淀常用的数据加工和复杂计算的处理逻辑，减少重复开发，提升公共指标的复用性，提高资源利用率；
2）统一指标开发的数据口径，避免数据指标的二义性；
3、ADS数据应用层
1）根据业务具体需求，做对应的统计分析指标；
4、沉淀优质的数据产品
通过前面的数据分层和加工数据指标，沉淀优质的对外数据产品，进一步发挥数据价值。这里优质的数据产品：指标复用率高，数据质量、数据时效和准确性能够得到保障。

2、常见的数据建模方法

数据仓库本质是从数据库衍生出来的，所以数据仓库的建模也是不断衍生发展的。从最早的借鉴数据库的范式建模，到逐渐提出维度建模，Data Vault模型，Anchor模型等等，越往后建模的要求越高，越需满足3NF，4NF等。但是对于数据仓库来说，目前主流还是维度建模，会夹杂着范式建模。
推荐文章，推荐文章

数据库和数据仓库的区别：
1）数据库中主要存放的是一些在线的数据，数据仓库中主要存放的是历史数据，并且存放的数据要比数据库多；
2）数据库主要用于业务处理（比如交易系统），数据仓库主要用于数据分析；
3）数据库的设计就是要避免冗余，而数据仓库通常会专门引入冗余，减少后面进行分析时大量的join操作。

2.1、数据仓库建模方法

数据仓库建模方法论可分为：范式建模、维度建模、Data Vault模型、Anchor模型。

2.2、范式建模（E-R模型）

将事物抽象为“实体”、“属性”、“关系”来表示数 据关联和事物描述；实体：Entity，关系：Relationship，这种对数据的抽象，建模通常被称为ER实体关系模型 。

ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式，且该建模方法需要满足3NF。Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模，BI架构提出分层架构，数仓底层ods、dwd也多采用ER关系模型就行设计。

但是逐渐随着企业数据的高增长，复杂化，数仓全部使用ER模型建模显得越来越不合时宜。为什么呢，因为其按部就班的步骤，三范式等，不适合现代化复杂，多变的业务组织。

E-R模型建模的步骤（满足3NF）如下：
1）出主体 （教师，课程）
2）梳理主体之间的关系 （一个老师可以教多门课，一门课可以被多个老师教）
3）梳理主体的属性 （教师：教师名称，性别，学历等）
4）画出E-R关系图

2.3、维度建模

维度建模，是数据仓库大师Ralph Kimball提出的，是数据仓库工程领域最流行的数仓建模经典。

维度建模从数据分析和使用的角度出发构建模型，因此它重点解决用户如何快速完成分析需求，同时满足的大规模复杂查询的响应性能。维度建模是面向分析的，为了提高查询性能可以增加数据冗余，反规范化的设计技术。

维度建模，将数据仓库中的表划分为事实表、维度表两种类型。

2.3.1、事实表

事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累积快照事实表。注意：这里需要值得注意的是，在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。

1）事务事实表，用于承载事务数据，通常粒度比较低，它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表，例如产品交易事务事实、ATM交易事务事实。

2）周期快照事实表，按照一定的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充。用来记录有规律的、固定时间间隔的业务累计数据，通常粒度比较高，例如账户月平均余额事实表。

3）累积快照事实表，用来记录具有时间跨度的业务处理过程的整个过程的信息，每个生命周期一行，通常这类事实表比较少见。

2.3.2、维度表

维度，顾名思义，业务过程的分析角度。维度表一般为单一主键，属性一般为文本性、描述性的，这些描述被称为维度。

案例：某电商平台，经常需要对订单进行分析，以某宝的购物订单为例，以维度建模的方式设计该模型，涉及到事实表为订单表、订单明细表，维度包括商品维度、用户维度、商家维度、区域维 度、时间维度。

商品维度：商品ID、商品名称、商品种类、单价、产地等。

用户维度：用户ID、姓名、性别、年龄、常住地、职业、学历等。

时间维度：日期ID、日期、周几、上/中/下旬、是否周末、是否假期等图片。

维度分为：
1）退化维度（DegenerateDimension）
在维度类型中，有一种重要的维度称作为退化维度，亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。

2）缓慢变化维（Slowly Changing Dimensions）
维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD）。比如员工表中的部门维度，员工的所在部门有可能两年后调整一次。

2.3.3、维度建模模型的分类

1）星型模型
星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。

可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
a. 维表只和事实表关联，维表之间没有关联；
b. 每个维表的主键为单列，且该主键放置在事实表中，作为两边连接的外键；
c. 以事实表为核心，维表围绕核心呈星形分布。

2）雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构：

星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见。尤其是基于hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。

提示，由上可以看出：
1、星型模型和雪花模型主要区别就是对维度表的拆分；
2、对于雪花模型，维度表的涉及更加规范，一般符合3NF，有效降低数据冗余，维度表之间不会相互关联；
3、星型模型，一般采用降维的操作，反规范化，不符合3NF，利用冗余来避免模型过于复杂，提高易用性和分析效率，效率相对较高。

3）星座模型
星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。数仓模型建设后期，大部分维度建模都是星座模型。

2.3.4、维度建模步骤

1、常见名词解释

2、模型设计的基本原则

1）高内聚和低耦合：将业务相关、粒度相同的数据设计为同一个物理模型，将高频率同时访问的数据放一起，将低频率同时访问的数据分开存储；
2）核心模型与扩展模型分离：核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要；
3）公共处理逻辑下沉：越是公用的处理逻辑，越应该在数据调度依赖的底层进行封装与实现，不要让公共逻辑多处同时存在；
4）成本与性能平衡：适当的数据冗余可以换取查询和刷新性能，但不要过度冗余；
5）数据可回滚：处理逻辑不变，在不同时间多次运行，数据结果确定不变；
6）一致性：具有相同含义的字段在不同的表中命名必须相同；
7）命名清晰可理解：表名需易于消费者理解和使用。

3、模型实施的具体步骤

在数据仓库中，数据域的划分可以使用多种方法。以下是几种常见的数据域划分方法：
1、主题划分：按照不同的主题或业务功能将数据划分为不同的数据域。每个数据域包含特定主题的相关数据。例如，可以将销售、客户、产品等主题分别划分为不同的数据域。
2、维度划分：按照数据仓库中所使用的维度来对数据进行划分。维度是描述业务过程的特定属性，例如时间、地理位置、产品类别等。可以将数据根据维度的不同划分为不同的数据域，使得每个数据域包含特定维度的数据。
3、时态划分：按照数据的时间属性对数据进行划分。可以将数据划分为历史数据、当前数据和未来数据等不同的时间划分，以满足不同时间范围内的数据分析需求。
4、功能/需求划分：根据不同的功能需求将数据划分为不同的数据域。例如，可以将事务处理数据、分析型数据、报表数据等根据其功能划分为不同的数据域。
5、安全和权限划分：根据数据的敏感性和访问权限的需求将数据划分为不同的数据域。这种划分可以确保敏感数据只能由授权的用户或角色访问。

这些划分方法可以单独使用，也可以结合使用，根据具体业务需求和数据特征来确定适合的数据域划分策略。数据域的划分有助于提高数据仓库的可管理性、性能和安全性，同时也为不同业务场景提供了灵活的数据访问能力。

1、数据调研
a、业务调研：了解数据建模场景的业务过程，并选择业务过程。如蚂蚁信贷包括了贷前、贷中、贷后等。那么是各个业务领域单独建设数仓还是一起建设需求讨论，一般业务领域内的业务线由于业务相似、业务相关性较大，可进行统一集中建设。
b、需求调研：通常包括两种途径，一是根据与分析师、业务运营人员沟通获知需求；二是对报表系统中的现有报表进行分析。比如分析师需要了解信贷一级类目(花/借)的成交金额。当获知这个指标后，我们需要分析根据什么汇总（维度），以及汇总什么（度量），这里类目是维度，成交金额是度量；明细数据和汇总数据应该怎么设计？这是一个公用的报表吗？是需要沉淀到汇总表里面，还是在报表工具中进行汇总？

2、架构设计
a、数据域划分：数据域需要抽象提炼，并且长期维护和更新，但不经常变动。在划分数据域的时候，既能涵盖当前所有的业务需求，又能在新业务进入的时候无影响地被包含进已有的数据域中或者扩展新的数据域。比如会员域、商品域、店铺域、日志域、交易域等
b、构建总线矩阵：需要做两件事情，一是明确每个数据域下有哪些业务过程，二是确定业务过程与哪些维度相关。

3、规范定义：定义指标体系，包括原子指标和派生指标
4、模型设计：包括明细事实表、维度表以及汇总事实表的模型设计
5、代码开发
6、部署运维

2.3.5、维度表的设计过程

以蚂蚁信贷的产品维度为例来对维度设计方法进行详细说明
第一步：选择维度。作为维度建模的核心，在企业级数仓中必须保证维度的唯一性，即为产品维度；
第二步：确定主维表。一般是ODS表，直接与业务系统同步；
第三步：确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表与主维表相关联。以信贷产品维度为例，与类目、机构等维度存在关联；
第四步：确定维度属性。包括两个步骤，一是从主维表中选择维度属性或者生成新的维度属性，二是从相关维表中选择维度属性或者生成新的维度属性。

维度表的设计中有哪些值得注意的地方：
1）尽可能生成丰富的维度属性
2）尽可能详细的对维度属性进行文字解释
3）区分数值型属性和事实
数值型字段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或者分组统计，则是作为维度属性；如果通常用于参与度量的计算，则是作为事实。
4）尽量沉淀通用的维度属性
例如，淘宝商品中的property字段，使用k:v存储了多个商品属性。商品品牌就存放在该字段中，而商品品牌是重要的分组统计和查询约束的条件，所以需要将该字段解析出来；
例如，商品是否在线，是重要的查询约束条件，但是无法直接获取，需要进行加工，所以需要封装商品是否在线的逻辑作为一个单独的属性字段。

维度规范化和反规范化如何理解：
1）对于淘系商品维度，如果采用雪花模式进行规范化处理，维度表拆解；
2）将维度的属性层次合并到单个维度中的操作称为反规范化；

如何处理维度的变化：
在现实中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化，与数据增长较为快速的事实表相比，维度变化相对缓慢，所以将这类维度叫做缓慢变化维。

处理缓慢变化维的方式：
1）重写维度值。无法保留历史数据
2）插入新的维度行。虽然能够保留历史数据，但是不能将变化前后的事实归一统计为变化前的维度或者变化后的维度。比如根据业务需求，需要将11月份的交易额全部统计到类目2上，该方式无法实现。
3）添加维度列，保留历史数据
4）快照维表。每天保存一份全量的快照数据。
a、优点：简单有效，开发和维护成本低；使用方便，理解性好，数据使用方只需要限定日期，即可获取到当天的快照数据。任意一天的事实快照和维度快照通过维度的自然键进行关联即可。
b、缺点：存储的浪费。比如某维度，每天的变化量占总体数据量比例很低，甚至无变化，那么全量保存就非常浪费存储空间。
5）拉链表。通过新增两个时间戳字段（start_dt和end_dt），将所有以天为粒度的变更数据记录下来。
优点：极限存储，对于不变的数据，不再重复存储，节省成本。
缺点：理解性较差，使用不方便。

2.3.6、事实表设计

事实表设计的八大原则：
1）尽可能包含所有与业务过程相关的事实；
2）只选择与业务过程相关的事实；
3）分解不可加事实为可加事实；
4）在选择维度和事实之前必须先声明粒度；
5）在同一个事实表中不能有不同粒度的事实；
6）事实的单位要保持一致；
7）对事实的null值要处理；
8）使用退化维度提高事实表的易用性（尽可能多使用）；

事实表的设计过程：
第一步：选择业务过程以及确定事实表类型
交易的过程分为：下单、支付、发货和完结四个业务过程。
Kimball维度建模理论认为，为了便于进行独立的分析研究，应该为每一个业务过程建立一个事实表。

在明确了流程所包含的业务过程之后，需要根据具体的业务需求来选择与维度建模有关的业务过程。

在选择了业务过程以后，相应的事实表类型也随之确定了。比如选择买家付款这个业务过程，那么事实表为，只包含买家付款这一业务过程的单事务事实表；如果选择的是所有四个业务过程，并且需要分析各个业务过程之间的时间间隔，那么事实表为，包含四个业务过程的累计快照事实表。

第二步：声明粒度
明确的粒度能确保对事实表中行数据的理解不会产生混淆，保证所有的事实按照同样的细节层次记录。尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。
第三步：确定维度
完成粒度声明以后，也就意味着确定了主键。对应的维度组合以及相关的维度字段就可以确定了，应该选择能够描述清楚业务过程所处的环境的维度信息。比如在淘宝订单付款事务事实表中，粒度为子订单，相关的维度有，买家、卖家、商品、收货人信息、业务类型、订单时间等
第四步：确定事实
事实可以通过回答"过程的度量是什么"来确定。比如在淘宝订单付款事务事实表中，同粒度的事实有，子订单分摊的支付金额、邮费、优惠金额等
第五步：冗余维度
在传统维度建模的星型模型中，对维度的处理是需要单独存放在专门的维表中的，通过事实表外键获取维度。这样做的目的是为了减少冗余，从而减少存储消耗。而在大数据的事实表模型设计中，考虑更多的是下游用户的使用效率，降低数据获取的复杂性，减少关联的表数量。所以通常会在事实表中冗余下游用户经常使用的维度。比如在淘宝订单付款事实表中，通常冗余的大量常用维度字段有，商品类目、卖家店铺等。

2.3.6.1、事实表有哪几种类型

事务事实表：
用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据

周期快照事实表：
以具有规律性的、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。当需要一些状态变量时，比如账户金额、买卖家星级、商品库存、卖家累计交易额等，则需要聚集与之相关的事务才能进行识别计算，往往和事务事实表成对出现。

累计快照事实表：
用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而修改。

2.3.6.2、多事务事实表如何对事实进行处理

主要有两种方法对事实进行处理：
1、不同业务过程的事实使用不同的事实字段进行存放。比如淘宝交易事务事实表，表中会设置下单度量，支付度量，完结度量等字段。
2、不同业务过程的事实使用同一个事实字段进行存放，但增加一个业务过程标签。比如收藏事务事实表，表中会设置收藏删除类型，以及收藏删除度量等字段。

关于上述两种方法如何选择呢？
当不同业务过程的度量比较相似时，采用第二种方式；反之，当不同业务过程的度量差异比较大时，采用第一种方式

2.3.6.3、单事务事实表和多事务事实表哪种设计更好

主要从五个方面来进行分析：
1）业务过程
对于单事务事实表，一个业务过程建议一张事实表，只反映一个业务过程的事实；对于多事务事实表，在同一个事实表中反映多个业务过程的事实。多个业务过程是否放到同一张事实表中，首先需要分析不同业务过程之间的相似性。
2）粒度和维度
在确定好业务过程后，需要基于不同的业务过程确定粒度和维度，当不同业务过程的粒度相同，同时拥有相似的维度时，此时就可以考虑采用多事务事实表。如果粒度不同，则必定是不同的事实表。比如交易中 支付和发货有不同的粒度，则无法将发货业务过程放到淘宝交易事务事实表中。
3）事实
如果单一业务过程的事实较多，同时不同业务过程的事实又不相同，则可以考虑单事务事实表，处理更加清晰；若使用多事务事实表，则会导致事实表零值或空值较多
4）下游业务使用
单事务事实表对于下游用户更容易理解，关注哪个业务过程就使用哪张事实表；而多事务事实表包含多个业务过程，用户使用往往较为困惑。
5）计算存储成本
当业务过程数据来源于同一个业务系统，具有相同的粒度和维度，且维度较多而事实不多时，此时可以考虑多事务事实表，不仅其加工计算成本较低，同时在存储上也相对节省。

2.3.6.4、周期快照事实表的设计过程

第一步，确定粒度。采样周期为每天，针对卖家、买家、商品、类目 、地区等维度的快照事实表 ，比如淘宝卖家历史至今汇总事实表、淘宝商品自然月至今汇总事实，不同的采样粒度确定了不同的快照事实表。
第二步，确定状态度量。确定好粒度以后，就要针对这个粒度确定需要采样的状态度量。比如淘宝卖家历史至今汇总事实表，包含了历史截至当日的下单金额、历史截至当日的支付金额等度量。

2.3.6.5、累计快照事实表的设计过程

第一步，选择业务过程。淘宝交易订单的流转主要包括 下单，支付，发货，完成这四个业务过程，在事务统计中，只关注了下单、支付、完成这三个业务过程，而在统计事件时间间隔的需求中，卖家发货也是关键环节。所以在针对淘宝交易累计快照事实表，我们选择这四个业务过程

第二步，确定粒度。子订单在此表中只记录一行，事件发生时，对此实例进行更新

第三步，确定维度。与事务事实表相同，维度主要有买家、卖家、店铺、商品、类目、地区等。四个业务过程对应的时间字段，分别为下单时间、支付事件、发货时间、确认收货时间。

第四步，确定事实。对于累计快照事实表，需要将各个业务过程的事实均放入事实表中。比如淘宝交易累计快照事实表，包含了各业务过程对应的事实，如下单金额、支付对应的折扣、邮费和支付金额、确认收货对应的金额等。累计快照事实表解决的最重要的问题是 统计不同业务过程之间的时间间隔，建议将每个过程的时间间隔作为事实放在事实表中。

第五步，退化维度。与事务事实表相同。

累计快照事实表的特点：
1、数据不断更新
事务事实表记录事务发生时的状态，对于实体的某一实例不再更新；而累积快照事实表则对实体的某一实例定期更新。
2、多业务过程日期
1）累计快照事实表适用于具有明确起止时间的短生命周期的实体，比如交易订单、物流订单等，对于实体的每一个实例，都会经历从诞生到消亡等一系列步骤。对于商品、用户等具有长生命周期的实体，一般采用周期快照事实表更合适；
2）累计快照事实表的典型特征就是多业务过程日期，用于计算业务过程之间的时间间隔。还有一个重要作用是保存全量数据。

2.4、DataVault模型

Data Vault是Dan Linstedt发起创建的一种模型方法论，Data Vault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展、灵活的应对业务的变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理。同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。

Data Vault模型是一种中心辐射式模型，其设计重点围绕着业务键的集成模式。这些业务键是存储在多个系统中的、针对各种信息的键，用于定位和唯一标识记录或数据。

Data Vault模型包含三种基本结构 ：
中心表-Hub ：唯一业务键的列表，唯一标识企业实际业务，企业的业务主体集合。
链接表-Link：表示中心表之间的关系，通过链接表串联整个企业的业务关联关系。
卫星表- Satellite：历史的描述性数据，数据仓库中数据的真正载体。

Data Vault模型建模流程：
1、梳理所有主要实体
2、将有入边的实体定义为中心表
3、将没有入边切仅有一个出边的表定义为中心表
4、源苦衷没有入边且有两条或以上出边的表定义为连接表
5、将外键关系定义为链接表

提示：Hub想像成人体的骨架，那么Link就是连接骨架的韧带组织， 而satelite就是骨架上的血肉。Data Vault是对ER模型更近一步的规范化，由于对数据的拆解和更偏向于基础数据组织，在处理分析类场景时相对复杂， 适合数仓低层构建，目前实际应用场景较少。

2.5、Anchor模型

Anchor是对Data Vault模型做了更近一步的规范会处理，初衷是为了设计高度可扩展的模型，核心思想是所有的扩张只添加而不修改，于是设计出的模型基本变成了k-v结构的模型，模型范式达到了6NF。

由于过度规范化，使用中牵涉到太多的join操作，仅作了解。

2.6、四种模型总结

以上为四种基本的建模方法，当前主流建模方法为：ER模型、维度模型。

1）ER模型常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。
缺陷：需要全面梳理企业所有的业务和数据流，周期长，人员要求高。

2）维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型。
优点：不需要完整的梳理企业业务流程和数据，实施周期根据主题边界而定，容易快速实现demo。
3）数仓模型的选择是灵活的，不局限于某一种模型方法。
4）数仓模型的设计也是灵活的，以实际需求场景为导向。
5）模型设计要兼顾灵活性、可扩展，而对终端用户透明性。
6）模型设计要考虑技术可靠性和实现成本。

2.7、常用建模工具

建模工具，一般企业以Erwin、powerdesigner、visio，甚至Excel等为主。也有些企业自行研发工具，或使用阿里等成熟套装组件产品。