没有任何

我们将重点讨论退化维度和缓慢变化维度。这种类型的维度是指将一些简单的维度直接放在事实表中。退化维度是维度建模领域中一个非常重要的概念。它在理解维度建模中起着非常重要的作用。退化维度一般可用于分析中的分组。退化维度：在维度类型中，有一种重要的维度称为退化维度。这种维度是指将一些简单的维度直接放在事实表中。在此基础上衍生出一种称为缓慢变化维度的概念。

由于维度的属性并不是恒定不变的，而是会随着时间而缓慢发生变化，我们一般把这种随时间变化的维度称为缓慢变化维度（SCD）。

SCD的常见治疗方法有三种：

①直接覆盖原值

②添加尺寸行

为维度成员添加新行时，需要为其分配新的主代理键。此外，还需要为维度行添加至少三列：生效日期、到期日期和行 ID。这可以与拉链表设计相关联。

③ 添加属性列

④ 混合法

您可以根据实际业务场景，混合使用或者选择使用以上三种方式，从而快速、方便、准确地分析历史变化情况。

事实表

事实表中的每一行数据都代表一个业务事件（比如你在淘宝上下单、付款、退款、评论等动作都算一个事件）。“事实”这个词指的是业务事件的度量值（我们可以统计次数、数量、金额等）。比如今年双十一，你在某个店铺花了钱，购买了一定数量的商品。对此，我们可以在维度表中记录这个动作：时间、用户、商品、店铺。事实表中登记的度量值可以包括购买金额、购买数量等。

事实表中的每一行包括：加法数值测量[因为数字是最能体现效果的方式]，与维度表相连的外键[我的理解是，如果只是裸的，你就不知道该说什么了]，通常有两个或多个外键，外键表示维度表之间的多对多关系。

事实表的特点是：首先数据量非常大（行数），因为双十一当天只会产生一定数量的订单，而我们所有的行为数据都会通过这种方式记录下来，所以你可以想象行数不会很多。内容比较狭窄：列数较少（主要是外键ID和测量值）。这是因为事实表的初衷就是狭窄地记录重要信息，不负责各种属性的描述。另外它会经常变化，每天都会新增很多，以电商为例，每天的订单记录会不断增加。

在此基础上生成了三大事实表！

1）事务事实表

交易事实表的粒度是每一行数据对应一个交易，或者一行对应一个交易中的一个条目。交易可以理解为业务流程中的各种事件节点，比如网购流程中的订单创建、买家付款，物流流程中的招工、发货、收货，退款流程中的退款申请、退款确认等，交易事实表就是针对这些流程构建的，作为数据仓库的原子明细数据，可以追踪定义业务流程的事件，提供丰富的分析能力。

只有当发生事务时，才会向事务事实表中添加一条新的数据，一般不会进行更新操作。

简单来说，事实表是基于每笔交易或者事件的，比如一条销售订单记录，一笔付款记录等，都可以看成是事实表中的一行数据。一旦该事务被提交，并插入事实表数据后，该数据将不再改变，其更新方式为每日增量更新。

2）定期快照事实表

定期快照事实表对于了解业务在定期、可预测的时间间隔内的累积绩效是必不可少的。与为每个发生的事件加载一行数据的交易事实表不同，定期快照可用于在每天、每周或每月结束时拍摄当前行为的图片，然后在下一个周期拍摄另一张图片，例如产品库存、账户余额、每日交易金额、每月累计交易金额等。交易事实表需要汇总长期交易历史才能获得这些结果，其效率相对较低。定期快照可以作为交易事实表的补充。

周期快照事实表并不保留全部数据，而只保留固定时间间隔的数据，比如每日或每月的销售额，或者每月的账户余额。再比如购物车，里面有商品的添加或移除，随时可能发生变化，但我们更关心的是每天结束时里面有多少商品，方便我们后期进行统计分析。因此周期快照事实表的更新方式为每日全量更新，即每天都对数据进行一次快照。

3）累积快照事实表

累积快照表完全覆盖了交易或离散产品（或用户）生命周期的不确定跨度。累积快照表具有多个日期字段，对应于主要可预见事件或步骤的发生。通常还有一个额外的日期列，指示快照行上次更新的时间。

累积快照事实表需要重新访问数据，当有事件发生时，需要更新对应的时间字段和相关指标，而不是新增一行。累积快照可以很好的满足一些特殊需求，比如：统计下单到支付的时间，支付到发货的时间，下单到确认收货的时间等。如果使用交易事实表，逻辑复杂，性能较差。

**换句话说，累积快照事实表用于跟踪业务事实的变化。**例如，数据仓库可能需要累积或存储从下订单到订单货物被包装、发货和签收的每个业务阶段的时间点数据，以跟踪订单生命周期的进展。当这个业务过程在进行时，事实表中的记录也必须不断更新。

订单ID 用户ID 下单时间 打包时间 发货时间 收货时间 订单金额

3-8

3-8

3-9

3-10

维度模型设计采用四步设计方法：

选择业务流程 -> 声明粒度 -> 确定维度 -> 确定粒度

设计流程的第一步是确定需要建模的业务流程和指标，这些业务流程是在业务需求收集过程中确定的。在业务系统中，如果业务表太多，则选取我们感兴趣的业务线，如订单业务、支付业务、退款业务、物流业务等，一条业务线对应一张事实表。

确定了事实表的粒度，就意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了，应该尽可能选取最小的粒度来满足各种需求。

最后一步是认真选择适用于业务流程的事实和指标，事实的粒度与声明的事实表的粒度一致。

表同步策略

意思是说我们在同步数据的时候，按照同步方式的不同来进行划分。

数据同步策略种类有：全量表、增量表、新增及变化表、​​特殊表等，通常数据仓库中的DWD层是根据你ODS层中的表的同步策略以及是否按照分区设计来设计的。

全表：存储完整的数据。

增量表：存储新增加的数据，数据一来就源源不断涌出，如同小溪流入大海

新增及变更表：存放新增的数据和变更的数据。比上面好一点的是，还可以同步变更的数据，所以每次改版都会有一点点数据。。。。

特殊表：只需要存储一次。

拉链手表

拉链表是数据仓库设计中针对表存储数据的方式进行定义的，顾名思义，所谓拉链就是记录历史，记录一个事物从开始到现在的所有变化。

我们来看一个例子，这是一个拉链表，里面存储了用户最基本的信息以及每条记录的生命周期，我们可以通过这个表获取最近一天的最新数据以及之前的历史数据，如果当前的信息还有效，则在有效结束日期处填写一个最大值（例如 9999-99-99）。

[外链图片传输失败，源站可能有防盗链机制，建议保存图片后直接上传(img--68)(C:\\SWQ\\\\-user-\34.png)]

在目前的大数据场景下，大部分公司都会选择基于HDFS+Hive的数据仓库架构。对于目前的HDFS版本来说，其文件系统中的文件是无法改变的，也就是说Hive表只能进行删除和添加操作，而不能进行其他操作。基于这个前提，我们就可以实现拉链表了。以上面的用户表为例，我们要实现用户的拉链表，在实现之前，我们需要确定可以使用哪些数据源，第一，我们需要一个ODS层的全量用户表，至少需要初始化一下，第二是每日的用户更新表，并且我们需要确定拉链表的时间粒度，比如拉链表每天只取一个状态，也就是如果一天中有3个状态变化，那么我们只取最后一个状态。这种日粒度的表其实已经可以解决大部分问题了。

另外，在知乎上看到的每日用户更新表的获取方式有三种，通过这些方式可以获取或者间接获取每日用户增量：

第一个就是我们可以监控数据的变化，从数据的来源处进行监控，比如说使用，最后我们可以把每天的变化合并起来，只需要获取最后的状态就可以了。

第二个就是假设我们每天都会得到一份切片数据，我们可以把两天的切片数据的差值作为日更新表，这样的话，我们可以先把所有字段进行md5，然后取，就ok了。

第三种方法是制作流程表，然后有每日变化流程表。

流量计

流表存储的是某个用户的变更记录，比如在流表中，某个用户的每条修改记录都会保存在一天的数据中，但是拉链表中只有一条记录。

这是设计拉链表时需要考虑的粒度问题，我们当然可以把粒度设得更小，一般几天就够了。

如果我们想知道这些数据，我们可以建立一个流表，相当于一个状态变化表，这样我们就可以记录下来，然后建立一个事务事实表，这样我们就可以获取这些变化的数据。

表也会遇到查询性能的问题，比如我们存储了 5 年的 数据，那么这张表必然会比较大，查询的时候性能会比较低，网上有两种思路：

首先，我们可以在一些查询引擎中建立索引，这样可以提高性能。然后我们还可以保留一些历史数据。例如，我们将全量的拉链表数据存储在一张表中，然后暴露一张只提供过去三个月数据的拉链表。

那么下面就是表格的记录啦~~

使用的时候性能比较低，在网上看到两个思路：

首先，我们可以在一些查询引擎中建立索引，这样可以提高性能。然后我们还可以保留一些历史数据。例如，我们将全量的拉链表数据存储在一张表中，然后暴露一张只提供过去三个月数据的拉链表。

那么下面就是表格的记录啦~~