阿里笔记之数据模型
文章目录
- 数据模型
-
- 名词说明
-
- 业务板块
- 公共定义
- 项目管理
- 维度
- 业务过程
- 指标
- 统计粒度
- 事实
-
- 事实的设计准则
- 事实表
-
- 事实表设计原则
- 事实表设计方法
-
- 声明粒度
- 确定事实
- 冗余维度
- 事务事实表
-
- 设计过程
- 事务事实表分类
-
- 多事务事实表
- 两种事务事实表如何选择
- 周期快照事实表
-
- 特性
-
- 用快照采样状态
- 快照粒度
- 密度与稀疏性
- 半可加性
- 快照事实表分类
-
- 设计步骤
- 单维度的每天快照事实表
- 混合维度的每天快照事实表
- 全量快照事实表
- 累计快照事实表
-
- 设计过程
-
- 业务过程
- 确定粒度
- 确定维度
- 确定事实
- 特点
-
- 数据不断更新
- 多业务过程日期
- 聚集型事实表
-
- 基本原则
- 基本步骤
- 聚集补充说明
- 讨论
数据模型
名词说明
业务板块
定义数据仓库的名称和业务空间，以企业内一个相对独立的业务为分配单元。例如，如果业务涉及零售、文娱，且系统间相对独立，则需要构建两个业务板块，即零售、文娱。如果业务仅涉及零售，且业务内的系统间隔离较少，则只需要构建一个业务板块，即零售。
公共定义
定义企业构建数据所需的全局概念对象或参数，以保证全局概念统一。当定义完成后，系统内其他指标（例如派生指标）可以按需统一、通用化引用这些对象，例如统计周期，年、月、日、每周、每日。
项目管理
项目是一种物理空间上的划分。项目管理，即用户在数据中台建设过程中，对物理资源及开发人员进行隔离化管理。一个业务板块可以包含多个项目，每个系统成员可以加入多个不同的项目。
维度
维度即进行统计的对象。通常情况下，维度是实际存在、不因事件发生就存在的实体。创建维度，即从顶层规范业务中的实体（主数据），并保证实体的唯一性。例如订单、商品。维度由多个属性组成的一个实体，例如买家维度，可以由买家支付金额、买家姓名、买家手机号之类的属性丰富维度这个实体。对于哪些使用较多却无法归属到相应的维度中的属性，归并到杂项维度中。
维度在事实表中用于描述业务过程所处的环境信息。
维度退化，是将一些维度信息直接存储到事实表中，冗余数据，方便读取数据。
业务过程
业务过程即业务活动中的所有事件（它是一个事件集合）。创建业务过程，即从顶层规范业务中事务内容的类型及唯一性。因此业务过程是一个不可拆分的行为事件。例如下单、支付、退款都是业务过程。
淘宝交易订单的流转的业务过程有四个：创建订单、买家付款、卖家发货、买家确认收货。
指标
指标分为原子指标和派生指标。
原子指标：对指标统计口径（即计算逻辑）、具体算法的一个抽象，是业务定义中不可再拆分的指标，例如支付金额。一般都为数值（统计）。原子指标=业务过程（动作）+度量，如支付（事件）金额（度量）。
派生指标：业务中常用的统计指标。派生指标=原子指标+业务限定+统计周期+统计粒度。例如，自然周、会员、采用优惠券支付的订单。
统计粒度
统计的最小颗粒度，数据唯一性的保证，统计分析的对象或视角，定义数据需要汇总的程度，可以理解为聚合运算时的分组条件（类似于SQL中group by的对象）。粒度是维度的一个组合，指明您的统计范围。例如，某个指标是某个卖家在某个省份的成交额，则粒度就是卖家、省份这两个维度的组合。
事实表中的一条记录所表达的业务细节程度被称为粒度。通常粒度可以通过两种方式来表述：一种是维度属性组合所表示的细节程度；一种是所表示的具体业务含义。
事实
度量业务过程，一般为整型或浮点型的十进制数值。有可加性、半加性和不可加性三种类型。可加性事实是指可以按照与事实表关联的任意维度进行汇总。半可加性事实只能只能按照特定的维度汇总，能对所有维度汇总，比如库存可以按照地点和商品进行汇总，而按时间维度把一年中每个月的库存累加起来则毫无意义。还有一种度量完全不具备可加性，比如比率型事实。对于不可加性事实可分解为可加的事实来实现聚集。
事实可以通过回答“过程的度量是什么”来确定。
事实的设计准则
-
事实完整性
尽可能多地获取所有的度量。
-
事务一致性
明确存储每一个事实以确保度量的一致性。
-
事实可加性
遇到不可加性度量，比如分摊比例、利润率等，需要进行转化为可加性。
不可加性，就是两条记录中的值相加，是没有统计价值的，就可以认为是不可加的。
事实表
事实表紧紧围绕业务过程来设计，通过获取描述业务过程的度量来表达业务过程。
事实表有三种类型：事务事实表、周期快照事实表和累计快照事实表。
事务事实表用来描述业务过程，跟踪空间或时间上某个点的度量事件，保存的是最原子的数据。
周期快照事实表以具有规律性的、可预见的时间间隔记录事实，时间间隔如每天、每月、每年等。
累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点。
| 事务事实表 | 周期快照对照事实表 | 累积快照事实表 | |
|---|---|---|---|
| 时期/时间 | 离散事务时间点 | 以有规律的、可预测的间隔产生快照 | 用于时间跨度不确定的不断变化的工作流 |
| 日期维度 | 事务日期 | 快照日期 | 相关业务过程涉及的多个日期 |
| 业务过程数 | 一个或多个 | 多个 | 多个 |
| 粒度 | 每行代表实体的一个事务 | 每行代表某时间周期的一个实体 | 每行代表一个实体的生命周期 |
| 事实 | 事务事实 | 累积事实 | 相关业务过程事实和时间间隔事实 |
| 事实表加载 | 插入 | 插入 | 插入与更新 |
| 事实表更新 | 不更新 | 不更新 | 业务过程变更时更新 |
事实表设计原则
- 尽可能包含所有与业务过程相关的事实
- 只选择与业务过程相关的事实
- 分解不可加性事实为可加的组件
- 在选择维度和事实之前必须先声明粒度
- 在同一个事实表中不能有多种不同粒度的事实
- 事实的单位要保持一致
- 对事实的 null 值要处理
- 使用退化维度提高事务表的易用性
事实表设计方法
- 选择业务过程及确定事实表类型
- 声明粒度
- 确定维度
- 确定事实
- 冗余维度
声明粒度
应该尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。
确定了粒度，也就确定了主键。
确定事实
尽可能包含所有与业务过程相关的事实。
冗余维度
正常建模时对维度的处理应该是单独存放在一张表中，通过主键与事实表进行关联。其目的是为了减少事实表的维度冗余，但有的时候，为了提高效率，进行适当将高频的维度信息冗余，方便下游用户使用。
事务事实表
设计过程
任何类型的时间都可以被理解为一种事务。
事务事实表用以跟踪定义业务过程的个体行为，提供丰富的分析能力，作为数据仓库原子的明细数据。
- 选择业务过程
- 确定粒度
- 确定维度
- 确定事实
- 冗余维度
在确定维度的时候，对于无法归类的维度属性，可以合并到一个杂项维度进行存放。
在事实表中，除了维度信息外的其他属性都是事实。事实一般为整型或浮点型的十进制数值。
事务事实表主键为粒度。
Kimball 维度建模理论认为，为了便于进行独立的分析研究，应该为每个业务过程建立一个事实表。
Q：每一个业务过程是否只能建一个事实表呢？
A：当然不是，一般我们建设事务事实表时，选用最小粒度作为粒度，增强其灵活性。除了事务事实表，还有其他两种类型的事实表。
事务事实表分类
事务事实表还分为两种：单事务事实表和多事务事实表。
单事务事实表：针对每一个业务过程设计一个事实表。
多事务事实表：将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程。
多事务事实表
多事务事实表使用场景一般为多个业务过程拥有相同的粒度。
多事务事实表设计时有两种方法进行事实的处理：
- 不同业务过程的事实使用不同的事实字段进行存放
- 不同业务过程的事实使用同一个事实字段进行存放
当两个或多个业务过程事实结构比较相似的时候，选用同一个事实字段进行存放。
不同的事实字段
如果不是当前业务过程的度量，则采取零值处理方式。
同一个事实字段
两种事务事实表如何选择
| 单事务事实表 | 多事务事实表 | |
|---|---|---|
| 业务过程 | 一个 | 多个 |
| 粒度 | 相互间不相关 | 相同粒度 |
| 维度 | 相互间不相关 | 一致 |
| 事实 | 只取当前业务过程中的事实 | 保留多个业务过程中的事实，非当前业务过程中的事实需要置零处理 |
| 冗余维度 | 多个业务过程，则需要冗余多次 | 不同的业务过程只需冗余一次 |
| 理解程度 | 易于理解，不会混淆 | 难以理解，需要通过标签来限定 |
| 计算存储成本 | 较多，每个业务过程都需要计算存储一次 | 较少，不同业务过程融合到一起，降低了存储计算量，但是非当前业务过程的度量存在大量零值。 |
建议：为了理解性和存储资源相对不紧张的情况下，尽可能选用单事务事实表，但若满足粒度和维度的要求情况下，可以考虑多事务事实表。
周期快照事实表
当需要一些 状态度量 时，比如账户余额、买卖家星级、商品库存等，则需要聚集于至相关的事务才能进行识别计算；或者聚集事务无法识别，比如温度等。对于这些状态度量，事务事实表是无效率的，而这些度量也和度量事务本身一样是有用的。
特性
事务事实表的粒度能以多种方式表达，但快照事实表的粒度通常以维度形式声明；事务事实表是稀疏的，但快照事实表是稠密的；事务事实表中的事实是完全可加的，但快照模型将至少包含一个用来展示半可加性质的事实。
用快照采样状态
快照事实表以预定的间隔采样状态度量。这种间隔联合一个或多个维度，将被用来定义快照事实表的粒度。
快照粒度
快照事实表的粒度通常总是被多维声明，可以简单地理解为快照需要采样的周期以及什么将被采样。
密度与稀疏性
快照事实表是稠密的，无论当天是否有业务过程发生，都会记录一行。
半可加性
在快照事实表中收集到的状态都是半可加的。半可加性事实不能根据时间维度获得有意义的汇总结果。
快照事实表分类
设计步骤
- 确定粒度
- 确定状态度量
单维度的每天快照事实表
不同的采样粒度确定了不同的快照事实表。
混合维度的每天快照事实表
混合维度相对于单维度，只是在每天的采样周期上针对多个维度进行采样。
以上两类快照事实表都有一个特点：都可以从事务事实表中进行汇总产出。除此之外，还有一种产出模式，即直接使用操作型系统的数据作为周期快照事实表的数据加工，比如淘宝卖家星级。
全量快照事实表
全量快照事实表会增加冗余维度的操作。
快照事实表与事务事实表往往都是成对设计的，相互补充，一瞒住更多的下游统计分析需求。
累计快照事实表
比如统计卖家下单到支付的时长、买家支付到卖家发货的时长等。对于类似于研究事件之间事件间隔的需求。
设计过程
- 选择业务过程
- 确定粒度
- 确定维度
- 确定事实
- 退化维度
业务过程
存在横跨多个业务过程。
确定粒度
一个完整的流程，累计快照事实表用于考察实体的唯一实例，所以只记录一行。
确定维度
与事务事实表相同。多个维度进行描述。
确定事实
需要将各业务过程对应的事实均放入事实表中。累计事实表解决掉的最重要的问题是统计不同业务过程之间的时间间隔，建议将每个过程的时间间隔作为事实放在事实表中。
特点
数据不断更新
事务事实表记录事务发生时的状态，对于实体的某一实例不再更新，而累积快照事实表则对实体的某一实例定期更新。
多业务过程日期
累积快照事实表适用于具有较明确起始时间的段生命周期的实体，比如交易订单、物流订单等。
聚集型事实表
又名为汇总表。聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。
基本原则
一致性。聚集表必须提供与查询明细粒度数据一致的查询结果。最简单方法是确保聚集星型模型中的维度和度量与原始模型中的维度和度量保持一致。
避免单一表设计。不要在同一个表中存储不同层次的聚集数据。
聚集粒度可不同。聚集并不需要保持与原始米线粒度数据一样的粒度，聚集只关心锁需要查询的维度。
基本步骤
- 确定聚集维度
- 确定一致性上钻
- 确定聚集事实
聚集补充说明
聚集不能跨越事实的，聚集的维度和度量必须与原始模型保持一致。
聚集会带来查询性能的提升，但聚集也会增加 ETL 维护的难度。当子类目对应的以及类目发生变更是，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。
讨论
Q：是否所有的业务流程都需要进行统计？
A: 不是，对于有些业务流程特别长的，需要考虑进行精简，对关键节点进行统计就行了。
Q: 汇总表与快照事实表的区别是什么？
A: 汇总表是基于事实表数据进行汇总，是纵向的，是基于已有的数据进行类似于 SUM 操作。而快照事实表更多是横向的，跨越多个事务事实表，进行横向的合并。