数仓建模之事实表

1. 事实表介绍

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计。其包含与该业务过程有关的维度引用(维度表外键)以及该业务过程的度量(通常是可累加的数字类型字段)。事实表中的每行数据代表一个业务事件(下单、支付、退款、评价等)。"事实"这个术语表示的是业务事件的度量值(可统计次数、个数、件数、金额等)，例如，订单事件中的下单金额。
每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。

2. 事实表的特征

• 数据量非常的大
• 内容相对的窄：列数较少(主要是外键ID和度量值)
• 经常发生变化，每天会新增加很多。

3. 事实表分类

事实表有三种类型：分别是事务事实表、周期快照事实表和累积快照事实表。

3.1 事务型事实表

1. 概述
   事务事实表用来记录各业务过程，它保存的是各业务过程的原子操作事件，即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度。以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
2. 不足
   事务型事实表可以保存所有业务过程的最细粒度的操作事件，故理论上其可以支撑与各业务过程相关的各种统计粒度的需求。但对于某些特定类型的需求，其逻辑可能会比较复杂，或者效率会比较低下。例如：
   • 存量型指标：要求统计截至当日的各用户虚拟货币余额。
   • 多事务关联统计：现需要统计最近30天，用户下单到支付的时间间隔的平均值。

3.2 周期型快照事实表

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型(例如商品库存，账户余额)或者状态型(空气温度，行驶速度)指标。周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。
对于商品库存、账户余额这些存量型指标，业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合了。又比如购物车，有加减商品，随时可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析。
对于空气温度、行驶速度这些状态型指标，由于它们的值往往是连续的，我们无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样，构建周期型快照事实表。

3.3 累积型快照事实表

累积快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。
累积型快照事实表通常具有多个日期字段，每个日期对应业务流程中的一个关键业务过程(里程碑)。 累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
累积型快照事实表主要用于分析业务过程(里程碑)之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔，使用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。

4. 拉链表

1. 拉链表，记录每条信息的生命周期，一旦一条记录的生命周期结束，就重新开始一条新的记录，并把当前日期放入生效开始日期。如果当前信息至今有效，在生效结束日期中填入一个极大值(如9999-12-31)。
   拉链表适合的场景：
   拉链表适合于：数据会发生变化，但是大部分是不变的。(即：缓慢变化维) 比如：用户信息会发生变化，但是每天变化的比例不高。如果数据量有一定规模，按照每日全量的方式保存效率很低。比如：1亿用户*365天，每天一份用户信息。(做每日全量效率低)

2. 制作当日变动数据(包括新增，修改)每日执行
   如何获得每日变动表？

• 最好表内有创建时间和变动时间
• 如果没有，可以利用第三方工具监控比如canal，监控MySQL的实时变化进行记录
• 逐行对比前后两天的数据，检查md5(concat(全部有可能变化的字段))是否相同
• 要求业务数据库提供变动流水