一、概念解读
业务板块
业务板块是逻辑空间的定义，是基于业务特征划分的命名空间
数据域
指面向业务分析，将业务过程或者维度进行抽象的集合。其中，业务过程可以概括为一个个不可拆分的行为事件。在业务过程之下，可以定义指标；维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。
业务过程
指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意，业务过程是一个不可拆分的行为事件，通俗地讲，业务过程就是企业活动中的事件。
维度
维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度（其中包括国家、地区、省以及城市等级别的内容）、时间维度（其中包括年、季、月、周、日等级别的内容）。
维度属性
维度属性隶属于一个维度，如地理维度里面的国家名称、国家ID、省份名称等都属于维度属性。
度量/原子指标
原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额。
派生指标
派生指标＝一个原子指标＋多个修饰词（可选）＋时间周期。可以理解为对原子指标业务统计范围的圈定。如原子指标：支付金额，最近l天海外买家支付金额则为派生指标（最近l天为时间周期，海外为修饰词，买家作为维度，而不作为修饰词）
时间周期
用来明确数据统计的时间范围或者时间点，如最近30天、自然周、截至当日等。
修饰类型
是对修饰词的一种抽象划分。修饰类型从属于某个业务域，如日志域的访问终端类型涵盖无线端、PC端等修饰词。
修饰词
指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于一种修饰类型，如在日志域的访问终端类型下，有修饰词PC端、无线端等。
维度提炼
在维度提炼的过程中，通常从业务过程或单据中相关的who、where、when、how、what、why的角度来提炼，详情参考《维度建模权威指南第3版》。
维度模型
维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。其典型的代表是星形模型，以及在一些特殊场景下使用的雪花模型。
二、建模步骤及规范
步骤
1、选择业务过程。
业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。
2、选择粒度。
在事件分析中，要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。
3、识别维表。
选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
4、选择事实。
确定分析需要衡量的指标。
维度建模规范
下面以维度建模作为理论基础，构建总线矩阵、划分和定义数据域、业务过程、维度、度量/原子指标、修饰类型、修饰词、时间周期、派生指标。整体遵循下面的建模规范。
1、概念层次
3、指标体系（指标组成体系之间关系）
原子指标
原子指标、修饰类型及修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域。
派生指标
- 派生指标由原子指标、时间周期修饰词、若干其他修饰词组合得到。
- 派生指标唯一归属一个原子指标 ，继承原子指标的数据域， 与修饰词的数据域无关。
- 派生指标可以选择多个修饰词，修饰词之间的关系为"或"或者"且"，由具体的派生指标语义决定。
- 派生指标要继承原子指标的英文名、数据类型和算法要求。
三、维度模型分层设计
1、模型架构图
操作数据层（ODS）
把操作系统数据几乎无处理地存放在数据仓库系统中。
- 同步：结构化数据增量或全量同步到底层存储。
- 结构化：非结构化（日志）结构化处理并存储至底层存储。
- 累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据。
公共数仓层（DW）
存放明细事实数据、维表数据及公共指标汇总数据。 采用维度模型方法作为理论基础，减少事实表和维表的关联，提高明细表的易用性
明细层（dwd）
理论上明细层数据是对ods层数据进行清洗加工，提高ods层数据的可用性，对于dwd层数据是否同层引用的观点需要权衡：
- 一般情况下dwd层不建议同层引用，这样做可以减少明细层任务之间的依赖，减少节点深度。
- 但是在某些场景下，ods层到dwd层数据加工逻辑复杂，计算开销大，这时可以权衡考虑适当复用dwd表来构建新的dwd表。
汇总层(dws)
这一层依赖我们的指标体系，将dwd层的数据按照各个维度进行聚合计算。
数据集市层(dwm)
当我们有一些跨业务域的聚合统计需求时，放到这一层。
DW层其主要功能如下：
- 组合相关和相似数据：采用明细宽表，复用关联计算，减少数据扫描。
- 公共指标统一加工：基于OneData体系构建命名规范、口径一致和算法统一的统计指标，为上层数据产品、应用和服务提供公共指标；建立逻辑汇总宽表。
- 建立一致性维度：建立一致的数据分析维表，降低数据计算口径、算法不统一的风险。
应用数据层（ADS）
存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成。
四、模型实施过程
实施流程主要分为：数据调研、架构设计、规范定义和模型设计
模型整体实施过程如下图所示：
1、数据调研
-
业务调研
要构建大数据数据仓库，就需要了解各个业务领域、业务线的业务有什么共同点和不同点，以及各个业务线可以细分为哪几个业务模块，每个业务模块具体的业务流程又是怎样的。业务调研是否充分，将会直接决定数据仓库建设是否成功 。 -
需求调研
需求调研的途径有两种：一是根据与分析师、业务运营人员的沟通（邮件、IM）获知需求；二是对报表系统中现有的报表进行研究分析。通过需求调研分析后，就清楚数据要做成什么样的。很多时候，都是由具体的数据需求驱动数据仓库团队去了解业务系统的业务数据，这两者并没有严格的先后顺序。
2、架构设计
数据域划分
- 数据域
是指面向业务分析，将业务过程或者维度进行抽象的集合。业务过程可以概括为一个个不可拆分的行为事件，如下单、支付、退款。为保障整个体系的生命力，数据域需要抽象提炼，并且长期维护和更新，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中或者扩展新的数据域。
构建总线矩阵
- 在进行业务调研和需求调研后，就要构建总线矩阵了。需要做两件事情：明确每个数据域下有哪些业务过程；业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。
3、规范定义
规范定义主要定义指标体系，包括原子指标、修饰词、时间周期和派生指标。上面也做了详细说明，此处不做展开。
4、模型定义
模型设计主要包括维度及属性的规范定义，维表、明细事实表和汇总事实表的模型设计。
4.1维度设计
维度是维度建模的基础和灵魂，数据仓库的能力直接与维度属性的质量和深度成正比。
维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。维度的作用一般是查询约束、分类汇总以及排序等。维度的设计过程就是确定维度属性的过程
设计步骤：
- 第一步：选择维度或新建维度作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。
- 第二步：确定主维表此处的主维表一般是ODS表，直接与业务系统同步。
- 第三步：确定相关维表数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性
- 第四步：确定维度属性主要包括两个阶段，其中第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。
规范化和反规范化
当具有多层次的维度属性，按照第三范式进行规范化后形成一系列维度表，而非单一维度表，这种建模称为雪花模式。
将维度的属性层次合并到单个维度中的操作称为反规范化。
维度整合
不同的应用系统的数据进入数仓后需要整合在一起：
- 命名规范的统一。表名、字段名等统一。
- 字段类型的统一。相同和相似字段的字段类型统一。
- 公共代码以及代码值的统一。
- 业务含义相同的表的统一。主要依据高内聚、低耦合的理念，将业务关系大，源系统影响差异小的表进行整合。
微型维度
微型维度的创建是通过将一部分不稳定的属性从相对稳定的主维度中移除，放置到拥有自己代理键的新表来实现。
递归层次
递归层次指的是某维表的实例值的层次关系，维度的递归层次分为有固定数量级别的均衡层次结构和无固定数量级别的非均衡层次结构。
由于数仓中一般不支持递归SQL的功能来处理这种层次结构，所以需要用到其他方式。
- 层次结构扁平化，适合均衡层次结构维度。
- 层次桥接表，适合非均衡层次结构维度。
多值维度
多值维度指事实表的一条记录在某维度表中有多条记录与之对应。
针对多值维度，常见的处理方式有三种：
- 降低事实表的粒度。
- 列扩展。
- 较为通用的方式，采用桥接表。
杂项维度
杂项维度是由操作型系统中的指示符或者标志字段组合而成，一般不在一致性维度之列。
这些维度如果作为事实存在事实表中，则会导致事实表占用空间变大；如果单独建立维表，则会出现许多零碎的小维表。
这时，通常的解决方案是建立杂项维度，将这些字段建立到一个维表中，在事实表中只需保存一个外键即可，杂项维度可以理解为将许多小维表通过行转列的方式存储到一张大维表中的处理方案。
退化维度
指维度属性直接存储到事实表中的维度。
4.2事实表设计
事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。
- 粒度事实表中一条记录所表达的业务细节程度被称为粒度。
- 事实类型作为度量业务过程的事实，一般为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型。
- 可加性事实，是指可以按照与事实表关联的任意维度进行汇总。
- 半可加性事实，只能按照特定维度汇总，不能对所有维度汇总，比如库存可以按照地点和商品进行汇总，而按时间维度把一年中每个月的库存累加起来则毫无意义。
- 不可加性事实，还有一种度量完全不具备可加性，比如比率型事实。对于不可加性事实可分解为可加的组件来实现聚集。
事实表类型
事务事实表
用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为"原子事实表"。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不能更改，其更新方式为增量更新。
周期快照事实表
以具有规律性的、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。周期快照事实表的日期维度通常记录时间段的终止日，记录的事实是这个时间段内一些聚集事实值或状态度量。事实表的数据一旦插入就不能更改，其更新方式为增量更新。
累积快照事实表
用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，而且这类事实表在数据加载完成后，可以对其数据进行更新，来补充业务状态变更时的日期信息和事实。
另外一个视角划分事实表类型：
单事务事实表：
针对每个业务过程设计一个事实表。这样方便对每个业务过程进行独立的分析研究。
多事务事实表：
将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程。
多事务事实表有两种方法进行事实处理：
不同业务过程的事实使用不同的事实字段进行存放；如果不是不是当前业务过程的度量，可以考虑用0值填充。
不同业务过程的事实使用同一个事实字段进行存放，但增加一列作为业务过程标签，记录该事务是否在当天完成。
4、事实表设计原则
尽可能包含所有与业务过程相关的事实。
只选择与业务过程相关的事实。
分解不可加性事实为可加的组件。
在选择维度和事实之前必须先声明粒度。
在同一个事实表中不能有多种不同粒度的事实。
事实的单位要保持一致。
对事实的null值要处理，建议用0填充。
使用退化维度提高事实表的易用性。
