最全数据仓库——事实表_累积型快照和事务性快照区别，作为大数据开发开发程序员_累积快照事实表

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

数据仓库基础笔记思维导图已经整理完毕，完整连接为：
数据仓库基础知识笔记思维导图

事实表

事务事实表

• 事务事实表用于跟踪事件，通过存储事实和与之关联的维度细节，允许单独或聚集地研究行为。
• 粒度
• 稀疏性
• 包含可加事实

无事实的事实表

不包含事实的事实表被称作无事实的事实表。虽然没有明确地记录事实，但是却能够支持度量。

• 为事件而设的无事实的事实表，记录活动的发生，虽然没有事实被明确地存储，但是这些事件能够被计算出来，产生有意义的过程度量
• 为条件而设的无事实的事实表，用来捕获有意义的信息，这些信息并不是商业活动的一部分，条件在事件点上的不同维度关联，当与活动进行比较时，可以提供有价值的见解
  没有相关事实的活动能够放在无事实的事实表中进行跟踪，每一行是描述事件维度的外键集合。行的存在构成了度量。

无事实的事实表的使用

无事实的事实表中的事件能够通过计算行数来聚集，事实表中的任何列也都可以作为计数的基准

添加事实

当无事实的事实表在追踪事件时，可以通过增加特殊事实使类似于标准事实表。该事实表总是包含值。即使是多余的，增加的列将会使读写用于分析的sql更加容易。
无事实的设计通常会成为对持续时间和开销的度量。

条件、范围或资格

无事实的事实表也可以用在不清楚对应事件活动的情况下，这些例子都描述了条件、范围或资格。它们通常不被认为是事务或者活动。它们可以按照对活动处理的方法进行建模，使用事实表。描述条件的事实通常是无事实的。

对条件建模的原因

事实表获取维度之间的关系。事实表是海量的交叉表，在特定的环境下每行关联多个维度表的实例。处于时间点的条件也关联特定环境下的维度。条件表示没有被业务活动获取的维度之间的关系。对活动研究可以通过列出条件来着色。

用于条件的无事实的事实表

可以使用无事实的事实表对条件建模。星型模式与维度关联起来，共同表示特定时间点的条件或者针对一段时间。条件、覆盖和资格应该被建模为无事实的事实表。
比较行为和条件

缓慢变化维度和条件

当使用星型模式度量条件时，维度中的类型2缓慢变化将需要添加新的事实表行。
性能是维度设计的指导性原则。通过加载过程中而不是在查询中重构数据，对油管业务过程的分析问题回答将更加便捷。然而，有时更快捷仍然不够充分。尽管设计良好的模式能够以更合理的方式处理过程的复杂查询。随着数据集的不断增大，即时简单的查询，也可能呈现出性能低下的问题。导出模式用来存储对已有已存在的维度数据重构后的数据副本。重构后的数据结构可以改善查询性能并降低报表开发的复杂度。同样，性能的改善是以额外地加载和管理数据的工作为代价。

导出模式的开销

导出模式是要付出代价的，这种好处的获得是通过将查询和报表阶段的工作负担转嫁到ETL阶段实现的。这与数据仓库的总体目标是一致的。但必须将其作为设计决策加以考虑。导出模式也会对可用性产生影响。任何打算开发查询或者报表的人员都必须为完成任务选择适当的星型模式。

• 事务事实表跟踪定义业务过程的个体行为，并且支持几种描述这种行为事实。可以提供丰富的分析型能力，时常充当原子数据的粒度化仓库
• 快照事实表周期性地采样状态度量，这些度量与一系列事务的累积效果相当，但是这些事务的格式不易进行研
• 累积快照事实表用来跟踪通过一系列处理步骤的个体项的进展情况，用于研究多数过程中里程碑或者事件的经过时间。这种事实表在单一行中关联多个不同的行为。

事实表快照

状态度量： 度量一系列事务的效果称为状态度量，当状态度量很重要时，事务事实表是无效率的。
状态度量，通常可以从事务历史中构造出来，然而如果事务历史延伸到很远的过去，或者必须计算许多事务的状态，监控状态将是低效的办法。
无法使用事务事实表分析的原因：

• 事务设计不符合标准
• 有时不存储事务数据
• 不要为挨个事务存储状态度量

快照模型

周期性事表快照简称事实表快照。事实表快照在确定的时间间隔中对问题的度量进行抽样，这样就可以容易地研究问题的度量值，而不需要聚集长期的事务历史。

• 用快照采用状态，快照事实表以预定的采用间隔采样状态度量。这种间隔联合一个或者多个维度，将被用来定义快照事实表的粒度。每行将包含记录所涉及状态的事实
• 快照粒度，快照的粒度必须包括采样状态的周期以及将被采样的定义，通常在维度关系中指明
• 稠密的，在快照中，不论是否存在活动，行都被记录，如果不这样做，确定状态将变得非常困难。快照事实表是稠密的，每个周期的信息被记录并与粒度声明一致，而不论是否发生任何行为
• 半可加性。快照事实表中手机的状态度量通常是半可加的，半可加事实能够用其他方法按照周期来汇总，包括计算最小值、最大值和平均值等
• 事务和快照模型能够很好的相互补充，如果都被建立起来，可以使用事务星型模式作为快照的数据源
• 周期性快照不限制存储度量状态的事实。
• 周期到日期度量，周期到日期度量通常不是存储在事务事实表中，快照事实表是周期到日期独恋在逻辑上存储的地方。
• 指定周期维度，对于周期快照，考虑表示被汇总周期的时间维度，而不是使用表示周期结束日的日维度。
• 快照与缓慢变化。周期快照仅仅为定义粒度的维度的每个自然键组合记录一行

累积快照事实表

累积快照事实表用来跟踪通过一系列处理步骤的个体项的进展情况，用于研究多数过程中里程碑或者事件的经过时间。这种事实表在单一行中关联多个不同的行为。
许多业务流程可以描述成一系列必经的阶段、步骤或状态。过程的效率往往是通过完成一个或者多个步骤所花费的时间来度量的。
间隔时间的研究要求关联多个状态，在事务模型中，每个状态变化都将记录在事实表的不同行中。但是事件彼此存在关联时就不起作用了。
事务模型存在的问题：

• 过程有效性的关键度量之一，是花费在过程中的每个步骤上的总的时间。事务模型查询编写困难，并且性能低下
• 开始与结束日期不是答案，当研究不同阶段或者不同里程碑花费时间时，描述处理步骤的事务模型是存在问题的。
  累积快照设计的粒度是依照在业务流程中可识别的实体来构造的。
• 粒度，为了设计累积快照，必须可以区分被处理或者跟踪实体的唯一实例，对于考虑的实体的每个实例，都将定义一行粒度。累积快照的行在被插入后将定期更新。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

/forums/4f45ff00ff254613a03fab5e56a57acb)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！