数据仓库——事实表，阿里技术专家深入讲解

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

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

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

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

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

条件、范围或资格

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

对条件建模的原因

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

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

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

缓慢变化维度和条件

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

导出模式的开销

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

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

事实表快照

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

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

快照模型

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

事务事实表	快照事实表
粒度可以以多种方式表达	粒度通常以维度形式声明
事务事实表是稀疏的	快照事实表是稠密的
事实是完全可加的	事实包含至少一个用来展示半可加性质的事实

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

累积快照事实表

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

• 过程有效性的关键度量之一，是花费在过程中的每个步骤上的总的时间。事务模型查询编写困难，并且性能低下
• 开始与结束日期不是答案，当研究不同阶段或者不同里程碑花费时间时，描述处理步骤的事务模型是存在问题的。
  累积快照设计的粒度是依照在业务流程中可识别的实体来构造的。
• 粒度，为了设计累积快照，必须可以区分被处理或者跟踪实体的唯一实例，对于考虑的实体的每个实例，都将定义一行粒度。累积快照的行在被插入后将定期更新。
• 里程碑的完成日期，快照记录了每个被监视的处理阶段的完成日期。
• 每个阶段间隔时间的事实，累积快照中的每一行都包含一组事实，从来度量每个阶段花费的天数。
• 行的生命周期，累积快照事实表将会定期更新行，处理间隔时间的事实将随着日期增长，每当实现一个新状态时，将会涉及里程碑日期。
• 使用累积快照，对研究花费在任何过程或者任何阶段的组合来讲，累积快照都是一种有效且强大的工具。
• 累积快照不能替代事务模型，许多情况下，两者能够互为补充。
• 关注关键状态里程碑，累积快照不必跟踪操作型系统中每个记录的状态变化，可以设计成通过业务来追踪关键里程碑或汇总级别的状态。
• 多源过程信息，某些情况下，有关业务过程信息不可能在一个地方获得。可能给架构设计者和ETL开发人员带来额外挑战。
• 非线性过程，许多业务过程是非线性或不可预见的，与采用标准严格的里程碑集合过程不同，这种过程可以包含可选的、交替的或者重复的步骤。这些情况不会妨碍累积快照的使用，但是在使用时需要在架构设计过程中附加严格的评估方法。不按照固定的可预见的里程碑处理过程仍然可以使用累积快照进行跟踪。需要谨慎定义在任何给定时间增长的事实的规则。如果一个特定状态完成了多次，那就需要确定使用哪个日期，这些选择应该由商业用户决定，而不是由设计者或开发人员确定。
• 缓慢变化，当由累积快照定义维度表示的事务发生类型2变化时，在维度表中关于该事务有两行，最近运行的代理键应该用于事实表中，不要使用自然键，因为这将导致双重计算。

融合事实表

消除了使用多步横向钻取过程的需要。

融合事实表将一个或者多个星型模式中的事实合并为单一的事实表，产生的星型模式可以用于横向钻取。开展过程比较工作。采用融合事实表表时，不再需要进行横向钻取。除了简化查询，融合事实表还可以极大地改善性能。

通过预先计算横向钻取活动，融合事实表从多个事实表中合并事实，这使得跨过程分析的查询更容易编写并且能提高心性能。如果使用的报表工具不支持横向钻取，可以采用融合事实表取代报表工具进行比较工作。

融合星型模式并不总是能够包含最细粒度的数据，融合事实表包含来自多个过程的信息，因此会记录0值事实。

当需要比较两个或者多个星型模式时，通常需要使用一个不可共享的维度来对某个星型模式进行行过滤，在设计融合事实表以支持这类比较时，需要确定如何将维度合并起来。它可能被融合的星型模式忽略，这会使分析能力受限。这需要将每个查询限制在涉及问题的维度上。消除这列问题的方法是，在融合事实表中包含不可共享的维度。针对融合事实表的查询必须始终限定维度设计于单一值，从而避免发生双重计算。

旋转事实表

消除了建立报表时所需要的行列转换。

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

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）

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

备注大数据）**
[外链图片转存中…(img-zI4TMH9R-1713408226234)]

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