当我们在实际工作过程中涉及到一些指标的计算比如账户余额、买卖家星级 商品库存、卖家累积交易额等计算中，则需要聚集与之相关的事务才能进行识别计 ；或者聚集事务无法识别 ，比如 温度等。对于这些状态度量，事务事实表是无效率的，而这些度量也和度量事务本身一样是有用的 ，因此， 维度建模理论给出了第二种常见的事实表一一周期快照事实表，简称“快照事实表”。
快照事实表：在确定时间间隔内对实体的度量进行抽样，这样可以很容易的研究实体的度量值，而不需要
要聚集长期 事务历史。接下来将以淘宝交易结束后的评价数据、卖家的累积支 金额、买卖家星级等事实表的设计为例，介绍快照事实表在事件中应用。
特性
快照事实表的设计有一些区别于事务事实白的设计性质。事务事实表的粒度能以多种方式表达，单快照事实表的粒度通常以维度的形式表明；事务事实表是稀疏的，但快照事实表是稠密的；事务事实表中的事实是完全可加的，但快照模型将至少包含一个用来展示半可加性质的事实。
1、用快照采集状态
快照事实表以预定的间隔采样状态度量。这种间隔联合一个或多个维度，将被用来定义快照事实表的粒度，每行都将包含记录所涉及状态的事实。
以自然年汇总事实表为例子介绍，比如我们会统计自然年至今的下单金额、支付金额、支付买家数、支付商品件数等状态度量，具体表可以参考下面
2、快照粒度
但快照事实表的粒度通常总是被多维声明，可以简单地理解为快照需要采样的周期以及什么将被采样。
例如交易卖家快照事实表中，粒度可以被理解为每天针对卖家历史截至当日的一些事实度量做快照。例如有每日汇总事实表，每周、每月等时间粒度（具体结合业务做相应粒度快照）
3、密度与稀疏性
事务事实表是稀疏的，只有当天发生的业务过程，，事实表才会记录该业务过程的事实。而快照事实表是稠密的，无论当天是否有业务过程发生，都会记录 行，比如针对卖家的历史至今的下单和支付金额，无论当天卖家是否有下单支付事实，都会给该卖家记录一行。
4、半可加性
在快照事实表中收集到的状态度量都是半可加的。事实不能根据时间维度获得有意义的汇总结果。交易事务事实表，比如可以对 个周期内的下单金额或者支付金额进行汇总，得到下单支付总额，但快照事实表在每个采样周期内是不能对状态度量进行汇总的。
例子
1、单维度的每天快照事实表
（1）、确认粒度
比如淘宝卖家历史至今汇总事实表、淘宝商品自然月至今汇总事实 ，不同的采样粒度确定了不同的快照事实表。
（2）、确定状态度量
确定好粒度以后，就要针对这个粒度确定需要采样的状态度量。比如淘宝卖家历史至今汇总事实表，包含了历史截至当日 的下单金额、历史截 当日的支付金额等度量
商品历史至今快照事实表，确定了商品维度和商品状态度量
2、混合维度的每天快照事实表
混合维度相对于单维度，只是在每天的采样周期上针对多个维度进行采样。比比如淘宝买卖家历史至今快照事实 ，采样周期依然是每天维度是卖家加买家，反映的是不同 家对于不同 卖家的下 支付金额
3、以上两类快照事实表都可以从事务事实表进行汇总产 出，这是周期快照事实表常见的 种产出模式。除此之外，还有种产出模式，直接使用操作型系统的数据作为周期快照事实表的数据源进行加工。
3、全量快照事实表
这类事实表的特性与前面所述的快照事实表有些差异，但依然属于周期快照事实表范畴。对于全量快照事实表，这里再增加 步，即冗余维度。此如好中评快照事实表，冗余了子订单维度、商品维度、评论者维度、被评论维度以及杂项维度 ，包括评论内容、是否匿名等信息
1、事务与快照成对设计
对于事务事实表和快照事实表往往都是成对设计的 ，互相补充，以满足更 的下游统计分析需求，特别是在事务事实表的基础上可以加工快照事实表，既丰富了星形模型，又降低了下游分析的成本。
2、附加事实
快照事实表在确定状态度量时， 般都是保存采样周期结束时的状态度量。但是也有分析需求需要关注上 个采样周期结束时的状态度，而又不愿意多次使用快照事实表，因此一般在设计周期快照事实表时会附加 些上 个采样周期的状态度量。
3、周期到日期度量
在卖家历史至今快照事实表时，指定了统计周期是卖家历史至今的一些状态度量，然而在实际应用中，也有需要关注自然年至今、季度至今等一些状态度量，因此在确定周期快照事实表的度量时，也要考虑类似的度量值，以满足更多的统计分析需求。数据仓库在设计周期快照事实表时，就针对多种周期到日期的度量设计了不同的快照事实表。
了淘宝交易下单／支付／确认收货事务事实表，用于统计下单／支付／确认收货的子订单数、 GMV 等。但仍然有很多需求，此事务事实表很难满足，比如统计买家下单到支付的时长、买家支付到卖家发货的 时长、买家从下单到确认收货的时长等。如果使用事务事实表进行统计，则逻辑复杂且性能很差。对于类似于研究事件之间时间间隔的需求，采用累积快照事实表可以很好地解决。
1、设计过程
对于累积快照事实表，其建模过程和事务事实表相同，适用于维度建模的步骤。下面详述了交易累积快照事实表的设计过程。
第一步：选择业务过程。
在事务事实表的设计中，订单的流转过程主要有四个事件，买家下单、买家支付、卖家发货、买家取人收获业务过程。而统计中事务统计只关注下单、支付和确认收货三个业务过程；而我们要统计事件事件间隔需求中，卖家发货也是关键环节。所以针对交易累积快照事实表，我们选择这四个业务过程。
第二部：确认粒度。
对于累积快照事实表，我们用于考察实体的唯一实例，所以子订单在此表中只有一行记录，事件发生时，对此实例进行更新。
第三部：确定维度：
事务事实表相同，维度主要有买家、卖家、店铺、商品、类目、发货地区、收货地区和发生事件的事件等维度，除了常规的维度之外我们还会增加其对应的杂项维度等。
其具体可以参考；
第四步：确认事实，
对于累积快照事实表，需要将各业务过程对应的事实均放人事实表中。比如某宝交易累积快照事实表，包含了各业务过程对应的事实，如下单对应的下单金额，支付对应的折扣、邮费和支付金额，确认收货对应的金额等。累积快照事实表解决的最重要的问题是统计不同业务过程之间的时间间隔，建议将每个过程的时间间隔作为事实放在事实表中。
第五部：退化维度
在大数据的事实表模型设计中，更多的是考虑提高下游用户的使用效率，降低数据获取的复杂性，减少关联的表数量。，在分布式数据仓库系统中，事实表和维表关联的戚本很高。所以在传统的维度模型设计完成之后，在物理实现中将各维度的常用属性退化到事实表中，以大大提高对事实表的过滤查询、统计聚合等操作的效率。
2、特点
1、数据不断跟新
事务事实表记录事务发生 时的状态，对于实体的某一实例不再更新；而累积快照事实表则对实体的某一实例定期更新。假设我们次啊用多事务事实表；对于orderl1订单， 2015-11-12 支付后，产生新的支付
记录， 2015-11-1 的数据不会更新。截至 2015-11-13 ，买家确认收货后，共产生 条记录。
而对于累积快照事实表，则只有一条记录，针对此记录不断跟新。
2、多业务过程日期
累积快照事实表适用于具有较明确起止时间的短生命周期的实体，比如交易订单、物流订单等，对于实体的每 个实例，都会经历从诞生到消亡等一系列步骤。对于商品、 用户等具有长生命周期的实体，一般采用周期快照事实表更合适。
例如某宝的宝交易累积快照事实表，存放加工后的事实，并将各维度常用属性和订单
杂项维度退化到此表中。然后将全量表保留到公共明细层中，通常用于数据探查、统计分析、数据挖掘等。
3、特殊处理
（1）、非线性过程
如上面交易流程，有时并不会按照正常流程从下单-支付-完成，比如买家下单之后不支付。自己关闭订单或字段取消订单。或支付之后申请退款等场景。
针对非线性过程，处理情况主要有以下几种
1）业务过程的统
将非正常流程侠的交易关闭党曾交易结束的一个分支，所以将交易结束作为流程结束、实体消亡的标志，括交易完成和交易结束两种情况。
2)、针对业务关键里程碑构建全面的流程
交易，全流程可能是下单→支付→发货→确认收货。对于没有支付或没有发货的交易订单，全流程仍然可以覆盖，相关业务过程的时间字段和事实置空。
3）循环流程的处理
是解决一个业务过程存在多个里程碑日期的问题。使用业务过程第 次发生的日期还是最后一次发生的日期，决定权在商业户，而不是设计或开发人员。
（2）多源过程
业务过程可能来自于不同的系统或者来于不同的表，其对于累积快照事实表的模型设计没有影响，但会影ETL 开发的复杂程度。对于交易累积快照事实表，除了上述提到的下单→支付→发货→确认收货流程，假设需要关注交易子订单退款业务或者物流业务， 时会涉及交易、售后、物流 个业务源系统。针对多源业务建模，主要考虑事实表的粒度问题。对于淘宝交易累积快照事实表，其粒度是交易子订单。对于退款，由于每个子订单可能存在多次退款，此时如果要将退款相关业务过程加入模型中，则需要和
商业用户确定存在多次退款时如何取舍，确保模型粒度不变。
（3）、业务过程的取舍
将退款相关业务流程设计进入交易累积快照事实表时 ，是否需要所有的业务过程？答案是否定的。当拥有大量的业务过程时，模型的实现复杂度会增加，特别是对于多源业务过程，模型的精合度过高，此时需根据商业用户需求，选取关键的里程碑。
4、物理实现
第一种方式是全量表的形式。
此全量表一般为日期分区表 ，每天的分区存储昨天的全量数据和当天的增量数据合并的结果，保证每条记录的状态最新。 此种方式适用于全量数据较少的情况。
第二种方式是全量表的变化形式。
业务实体 般从产生到消亡都有一定的时间间隔，可以测算此时间间隔，或者根据商业用户的需求确定一个相对较大的时间间隔。比如针对交易订单，我们以 200 天作为订单从产生到消亡的最大间隔。设计最近 200 天的交易订单累积快照事实 ，每 的分区存储最近 200 天的交易订单 200 天之前的订单则按照 gmt_create建分区存储在归档表中。。此方式存在的 个问题是 200 天的全量表根据商业需求需要保留多天的分区数据，而由于数据量较大，存储消耗较大。
第三种方式是以业务实体的结束时间分区
每天的分区存放当天的结束数据，设计一个时间非常大的分区，比如如 3000-12-31 ，存放截至当
前未结束的数据。由于每天将当天结束的数据归档至当天分区
通过前面的介绍，我们对数据仓库三种事实表有了详细的了解。一些业务过程可能只需要一种事实表，而另外一些业务过程可能需要两种或三种事实表。 种事实表相互补充，给出业务的完整描述。
下面给了下三种事实表的比较。
1、事务事实表记录的事务层面的事实，也称为原子事实表，用于跟踪业务过程行为，并支持几种藐视行为的事实，保存的事最原子的数据，粒度通常是每个事务一条记录。 一旦事务被提交，事实表数据被插人，数据就不能更改，其更新方式为增量更新。
2、周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，如余额、库存、层级等，时间间隔可以为为每天、每月、每年等，典型的例子如库存日快照表等。周期快照事实表的日期维度通常记录时间段的终止日，记录的事实是这个时间段内一些聚集事实值或状态度量。事实表的数据一旦插人就不能更改，其更新方式为增量更新。
3、累积快照事实表用来跟踪实体的一系列业务过程的进展情况，它通常就要有多个日期字段，用于眼见业务过程中的里程碑过程时间间隔，另外，它还会有一个只是最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时时不知道的，而且这类事实表在数据加载完成后。可以对其数据进行更新，来补充业务状态变更跟时的日期信息和事实。
聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。通过访问聚集数据，可以减少数据库在响应查询时必须执行的工作量，能够快速响应用户的查询，同时有利于减少不同用户访问明细数据带来的结果不一致问题。尽管聚集能带来良好的收益。
某宝在应用公用数据是比较多的，通过聚集进行沉淀，比如卖家最近1天的交易汇总表、卖家最近1 天的交易汇总表、卖家自然年交易汇总表等，这类聚集汇总数据，被叫做公共汇总层。
1、聚集的基本原则
一致性：聚集表的查询记过和明细数据结果保持一致。
避免单一表设计：不要在同 个表中存储不同层次的聚集数据，或者把不同聚集数据放到不同列中表示，如把按天与按月汇总的交易额用两列存放，但是需要在列名或者列注释上能分辨出来。
聚集粒度可以不同：。聚集并不需要保持与原始明细粒度数据 样的粒度，聚集只关心所需要查询的维度。单涉维度有商品、买家等。我们可以按照商品汇总 天的交易额，可以按照卖家汇总 天的营业额等。
2、聚集的基本步骤
第一步：确定聚集维度。
原始明细模型中会存在多个描述事实的维度 ，如 日期、商品类卖家等，这时候需要确定根据什么维度聚集 ，如果只关 商品的交易额情况，那么就可以根据商品维度聚集数据。
第二步：确定一致性上钻。
这时候要关心是按月汇总还是按天汇总，是按照商品汇总还是按照类目汇总，如果按照类目汇总，还需要关心是按照大类汇总还是小类汇总。
第三步：确定聚集事实。
在原始明细模型中可能会有多个事实的度量，比如在交易中有交易额、交易数量等，这时候要明确是按照交易额汇总还是按照成交数量汇总。
3、公共汇总层
（1）、基本原则
第一数据公用性：通用数据或者经常用于数据分析的数据我们才选择放到公共汇总层中
第二不跨数据域：数据域是在较高层次上对数据进行分类聚集的抽象。如交易统一划到交易域下，
第三区分统计周期：在表的命名上要能说明数据的统计周期，如 Id表示最近 天， td 表示截至当天， nd 表示最近 天。
（2）交易汇总表设计（例子）
聚集事指针对原始明细李端的数据进行汇总，鉴定已有的交易订单明细模型如下，可以看出事实和商品、卖家、买家等维度关联。
可以看出聚集的组合可能性为各个维度属性个数的乘积： 2222235 …。下面将按照聚集的基本步骤来介绍聚集表的设计流程。
1）按商品粒度汇总。
（1）确定聚集维度一一商品。
（2）确定一致性上钻-按商品（商品ID）最近1天汇总
（3）确定聚集事实-下单量、交易量。
因此，按商品聚集的星形模型如图
可以看出聚集的事实都是原始模型中的事实，聚集的维度也是原始模型维度中商品维度，只是去掉了其他不关心的维度。
注意：前面聚集基本原则中说过，应该避免将不同层级的数据放在一起，为此我们选择用两列存放7天和30天的事实，但是需要在列茗和字段注释上说明清楚。
其他的 分别按照卖家粒度汇总、按照卖家买家商品粒度汇总、按照二级类目汇总等逻辑相似。
4、聚集补充说明
（1）聚集事不跨越事实的
聚集是针对原始星形模型进行的汇总，为了获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因 此聚集是不跨越事实的。横向钻取是针对多个事实基于一致性维度进行的分析，很多时候采用融合事实表，预先存放横向钻取的结果，从而提过查询性能，因此融合事实表是一种导出模式而不是聚集。
（2）聚集带来的问题
聚集会带来查询性能的提升，但聚集也会增加 ETL 维护的难度。当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。这一额外工作随着业务复杂性的增加，会
导致多数 ETL 人员选择简单强力的方法，删除并重新聚集数据。
在维度模型中，事实表用事实来度量业务过程，不包含事实或度量的事实表称为“无事实的事实表＼虽然没有明确的事实，但可以用来支持业务过程的度量。
常见的无事实事实表主要有如下两种：
第一种是事件类的，记录事件的发生，其中最常见的是日志类事实表，比如用户的浏览日志，某会员某事件点浏览淘宝首页等对于每次点击其事实为1，但一般不会存此事实的列
第二种是条件、范围或资格类的，记录维度与维度多对多之 间的系。比如客户和销售人员的分配情况、产品的促销范围等。
