【数据中台】维度建模指北

1. 建模流程

1. 确认主题域边界，明确业务范围。
2. 根据业务范围，拆分由业务专家认可的最细粒度业务过程（比如投保->承保->…）
3. 识别业务过程中的实体，可以结合人货场与实体建模法的方法，确定其流程中的主实体和其他实体。
4. 确定粒度（粒度，一行数据代表：一条保单？一条批单？一天的保费？），将主实体相关属性作为设计事实表（单/多事务事实表、单维度/混合维度/全量周期快照事实表，累积快照事实表） 度量的依据。
5. 确定维度，将其他实体作为维度，如who？when？where？
6. 将常用维度退化至事实表中

2. 迭代流程

根据需求迭代:

1. 事实表关联实体清单:按需添加相关的实体;
2. 在事实表中按需添加属性和维度;

3. 主题域划分

主题域划分具体分为4步：

1. 业务系统功能模块梳理
   为了建设比较全面的调研框架，需要基于已经沉淀的业务系统，来设计调研内容。理论上一个业务系统中所有的功能模块肯定是业务运行过程中需要使用的或者说曾经需要使用的，而且功能模块设计就能够串起整个主线流程，将每个模块下支持的哪些功能梳理清楚，通过功能模块先建立其骨架。
2. 业务动作梳理
   了解维持正常业务运行时，是哪些人需要展开哪些业务活动，存在哪些度量和需要量化的数据，其业务活动的粒度要到最细不可拆分的粒度，串起整个业务运行的全景图。
3. 业务调研
   有了全业务流程图，还需要明确业务方期望了解哪些信息，同时需要明确最细粒度的业务动作，业务动作的组合，业务动作发生后的状态，汇聚成最终的业务过程。
4. 划分数据域
   按照两个原则一个思想来设计数据域，将所有的业务过程进行聚类，高度抽象后形成数据域。
   • 第一原则：高内聚低耦合，将概念接近，关联度高的放在一类。
   • 第二原则：保证抽象逻辑的一致性，形成最终的数据域和相关业务过程。
   • 一个思想：螺旋递进，数据域的划分没有完美的状态，只有接近完美，在实践过程中以螺旋递进的方式记性迭代优化。
     注：
     常见的抽象方法：
   1. 按照业务或业务过程划分：比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题。
   2. 根据需求方划分：比如需求方为财务部，就可以设定对应的财务主题域，而财务主题域里面可能就会有员工工资分析，投资回报比分析等主题；
   3. 按照功能或应用划分：比如微信中的朋友圈数据域、群聊数据域等，而朋友圈数据域可能就会有用户动态信息主题、广告主题等；
   4. 按照部门划分：比如可能会有运营域、技术域等，运营域中可能会有工资支出分析、活动宣传效果分析等主题。

4. 业务建模

在梳理业务过程中，我们如何快速的去理解业务，构建领域概念模型。通常我们采用实体建模法。

4.1 实体建模法

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

虽然实体法看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成3个部分，实体，事件和说明。举个栗子，小明早上骑自行车去上学校。其中实体：小明，学校，存在的关系为：小明是学校的学生，说明：小明是在早上通过骑行车去上的学。

5. 维度表

5.1 维度表的定义

• 维度表定义：一般是对事实的描述信息，每一张维度表对应现实世界中的一个对象或者概念。例如:用户、商品、日期、地区等。

注意：如果属性值是离散的，用于过滤和标记的，就放到维度表里，如果是属性值是连续取值，可用于计算的，就放到事实表中。

• 维度表的特征：

1. 维度表的范围很宽（具有多个属性、列比较多）
2. 跟事实表相比，行数较少，（通常小于10万条）
3. 内容相对固定

5.2 维表的类型

1. 缓慢变化维

   • 类型一：字段值发生变化时覆盖原来的值。
   • 类型二：字段值发生变化时会新增一行，重新分配代理键。
   • 类型三：每条记录会新增一列来标识变化前的值，发生变化时，把旧值放到新增的列中，把新值覆盖旧值。

2. 日期维

   • 它是数据仓库必须有的维度，包含日期，日期所属的周，月，季度，年等信息。

3. 角色维

   • 相同的维度表在维度模型中扮演不同的逻辑角色，一般通过创建视图来表示。

4. 杂项维

   • 如果每个属性值都很少，可以把这些维度组合起来，生成一个维度表。

5. 支架维

   • 如果维度之间是一对多的关系或区别于原维度的多个描述性维度属性，可以建立雪花支架维度
     

6. 多值维度桥接维

   • 如果两个维度表是多对多的关系，可以使用多值维度设计。
     

7. 微型维

   • 一个大型维有些属性变化比较频繁，把这些属性单独生成一个微型维度表。
     

8. 缩小维

   • 它是维度表的一个子集或部分属性

9. 查找维

   • 系统代码表里维度的信息

10. 层级维

    • 有些维度表是有层级结构的，可以通过视图生成树形结构的维度表
      

11. 手工维护的维表

    • 有些数据不再业务系统里，需要业务用户手工维护的维度表。

5.3 维度表设计原则

• 一致性维度

数据仓库中维度表的一致性，其实一致性维度在表结构和属性都没有本质的区别，有一点的差异是数据仓库的星型模型会使得维度表有一定的冗余。那么一致性体现在哪里呢：维度共享性。共享性体现在整个平台或整个部门共用维度，而不仅仅只是单纯某个业务单独使用。

一般的维度并没有把共享性作为一个共性的标准。然而在维度建模中，一致性维度将作为重心来做。数据仓库70%的工作量和复杂度是用在构建一致性维度。

6. 事实表

• 事实表定义：表中的每行数据代表一个业务事件（如投保，理赔），事实表示的是业务事件的度量值（可以统计次数、个数、金额等），例如缴费事件中的支付金额。
  每一行事实表的数据包括：具有可加性的数值型的度量值、与维度表相连接的外键，通常具有两个及以上的外键。

• 事实表的特征：
  1.行多列少
  2.经常发生变化，每天新增很多

• 一致性事实

指每个度量在整个数据仓库中都是唯一的统计口径，为了避免歧义，一个度量只有唯一的业务术语。一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台，发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查来实现。为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点。第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。

• 事实表分类:

在Kimball的维度建模理论中主要定义了事务事实表、周期快照事实表、累积快照事实表三种类型的事实表

1. 事务事实表: 描述业务过程事务层面的事实，每条记录代表一个事务事件，保留事务事件活动的原始内容

   事务事实表中的数据在事务事件发生后记录，一般记录后数据就不再进行更改，其更新方式为增量更新;

2. 周期快照事实表:以具有规律性时间间隔生成快照来记录事实，每行代表某个时间周期的一条记录，记录的事实是时间周期内的汇总度量值。
   周期快照事实表的内容一般在所表达的时间周期结束后才会产生， 一般记录后数据就不再更改，其更新方式为增量更新。周期快照事实表一般是建立在事务事实表之上的汇聚,维度比事务事实表少，粒度比事务事实表粗，不同时间周期的也会生成多个周期快照事实表。如月（季）度销售报表。

3. 累计快照事实表: 每行记录一个流程从开始到结束、全生命周期的所有关键节点，通常具有多个日期字段来记录关键事件时间点。

   对于不同过程，要设计统一的结束标志，没有的业务时间置空。有时需要将每个过程时间间隔作为事实放在表中，如：报案至查勘时间间隔等。

   累计快照事实表涉及的多个度量中任意一个的变化都要做记录， 由于周期快照事实表涉及的多个事件的首次加载和后续更新时间是不确定的，因此在首次加载后允许对记录进行更新。这里分三种情况：

   1. 全量表：一般是日分区，每天存储前一天的全量数据和当天增量(更新)数据进行合并，保证每条数据的最新状态，此方式适用于数据量不大的情况。
   2. 全量变化表：累积事实表用于保存生命周期短的实例，所以可以根据业务实体从开始到结束的最大时间间隔，如交易业务最大时间跨度200天，每天保存的是过去200天的全量数据，200天之前的数据存储在归档表中。适用于数据量大的场景。
   3. 以业务结束时间分区：每天分区中存放的是当天结束的业务，然后用一个非常大的分区（如 3000-12-31）保存所有至今未结束的记录，这种方式不会浪费存储资源。

比较项	事务事实表	周期快照事实表	累积快照事实表
代表的时间段	离散的时间点记录事务	规律性的间隔	不确定时间跨度且不断变化的业务事实
粒度	每行代表一个事务	每行代表周期时间内的聚集事务值	每行代表一个流程的全生命周期
事实表加载	insert	insert	insert & update
事实表更新	不重新加载	不重新加载	行为发生任何时候都要重新加载
日期维度	事务日期	时间段终止日期	关键节点的多个日期

6.1 事实表设计原则

1. 尽可能包含所有与业务过程相关的事实

事实表设计的目的是为了度量业务过程，所以分析哪些事实与业务过程有关是设计中非常重要的关注点。在事实表中应该尽量包含所有与业务过程相关的事实，即使存在冗余，但是因为事实通常为数字型，带来的存储开销也不会很大。

2. 只选择与业务过程相关的事实

在选择事实，应该注意只选择与业务过程有关的事实。比如在订单的下单这个业务过程的事实表设计中 ，不应该存在支付金额这个表示支付业务过程的事实。

3. 分解不可加事实为可加的组件

对于不具备可加性条件的度量，需要分解为可加的度量。比如订单的优惠率，应该分解为订单原价金额与订单优惠金额两个事实存储在事实表中。

4. 在选择维度和事实之前必须先生声明粒度

粒度的声明是事实表设计中不可忽视的重要一步，粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性，在选择维度和事实之前必须先声明粒度，且每个维度和事实必须与所定义的粒度保持一致。在设计事实表的过程中，粒度定义得越细越好，建议从最低级别的原子粒度开始，因为原子粒度提供了最大限度的灵活性（比如订单粒度无法统计商品粒度的值），可以支持无法预期的各种细节层次的用户需求。在事实表中，通常通过业务描述来表述粒度，但对于聚集性事实表的粒度描述，可采用维度或维度属性组合的方式。

5. 在同一个事实表中不能同时存在多种不同粒度的事实

事实表中的所有事实需要与表定义的粒度保持一致，在同个事务表中不能有多种不同粒度的事实。不然对不同粒度的事实进行累加时，其实是会出现很大问题的。

6. 事实的单位要保持一致

对于同 个事实表中事实的单位，应该保持一致。比如原订单金额、订单优惠金额、订单运费金额这三个事实，应该采用一致的计量单位，统一为元或分，以方便使用。

7. 对事实的null值要处理

对于事实表中事实度量为 null 值的处理，因为在数据库中null对常用数字型字段的 SQL 过滤条件都不生效，比如大于、小于、等于、大于或等于、小于或等于，建议用-9999填充。

8. 使用退化维度提高事实表的易用性

在Kimball的维度建模中，通常按照星形模型的方式来设计，对于维度的获取采用的是通过事实表的外键关联专门的维表的方式，谨慎使用退化维度。而在大数据领域的事实表设计中，则大量采用退化维度的方式，在事实表中存储各种类型的常用维度信息。这样设计的目的主要是为了减少下游用户使用时关联多个表的操作，直接通过退化维度实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等。 通过增加冗余存储的方式减少计算开销，提高使用效率。

7. 维度建模的缺点

• 维度建模之前需要进行大量的数据预处理，因此会导致大量的数据处理工作（ETL）。
• 当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。
• 如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，还需要对业务元数据，技术元数据进行口径统一，才可保证一致性和准确性，
• 而且在数据仓库的底层，不是特别适用于维度建模的方法。

8.维度建模和宽表的适用場景

8.1 维度建模

维度建模主要适用于dwd层的建设，它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。

8.2 宽表

宽表的使用主要适用于数据集市层的建设，

1. 根据主题域和业务域，将某个业务线的所有业务过程梳理清楚；

2. 将被业务认可的最细粒度的业务过程的数据作为事实表依据，然后横向扩充其他事实表上卷数据（包含一些统计指标），同时纵向的添加该业务过程中一些主键对应的维度；

3. 宽表的设计不依赖具体的业务需求而是根据整体业务线相匹配；

4. 维度模型可以作为宽表的基础，一旦确定全部的数据链路，可以通过维度模型再生成对应宽表进行快速的业务支撑；

比较项	维度建模	宽表
扩展性	维度表变更，事实表可能不影响	维度变更可能导致很多宽表都要调整
耦合度	事实表和维度表解藕，某些粒度上不会因为维度表失败而影响聚合表的产出	一个非重要任务失败会导致整个宽表无法产出
组织方式	任务及工作流易组织	因高耦合导致任务之间盘根错节，不利于组织任务和工作流
数据一致性	企业级数据仓库总线架构的基石	底层如果没有维度建模支撑，容易陷入混乱
易用性	事务日期	时间段终止日期

9. 数仓经验

数仓设计是有别于传统的业务系统的三范式设计方法的。这里暂时不讨论Inmon和Kimball两位大神设计理念的异同，只从实际工作中来讲。

• 针对主数据，核心维度，是用缓慢变化维中的哪种设计方法。
  请避免使用拉链表，建议改成全量快照表，主要原因在于很多时候需要回刷历史数据。

• 如何规避上游模型完成过晚问题？
  如果对数据准确度要求没有特别高，请使用T-2分区数据
  如果对数据准确度较高，请先建一张未来分区的全量快照表（如3000-12-31），下游应用直接定点依赖该表。这样的好处在于如果到点，当天的数据已经跑完，则用当前分区数据，反之用T-2数据。

• 维度过多，算不出来
  用好 grouping sets。多维分析的基础，极大的节省olap工具的算力，代码简洁了很多，并且生成的job数也变少且计算的效率提高了（UNION ALL是多次扫描表）

• 数据变化过快
  用好复杂结构，尤其是map，尤其是在对大量页面的PV，UV计算中，因为业务发展太快，页面上了一个又一个，其变化速度远大于模型修改的速度，因为要把模型设计的更灵活。