事实表的分类:事务事实表,周期快照事实表,累计快照事实表

文章详细介绍了数据仓库中事实表的三种主要类型:事务事实表记录原子数据,具有稀疏性质;周期快照事实表定期统计度量,是稠密表;累计快照事实表关注事务完整生命周期,包含多个关键时间点。这三种事实表在粒度、更新方式和应用场景上有所不同,分别适应不同的业务分析需求。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

维度建模数仓领域中的事实表大致分以下三种:事务事实表,周期快照事实表,累计事实表。

事务事实表与周期快照事实表、累积快照事实表虽然使用相同的一致性维度,但是它们在内容构成以及业务描述上还是有很大的区别。

1.事务事实表
事务事实表记录的事务层面的事实,保存的是最原子的数据,也称“原子事实表”。事务事实表中的数据在事务事件发生后产生,数据的粒度通常是每个事务记录一条记录。一旦事务被提交,事实表数据被插入,数据就不再进行更改,其更新方式为增量更新。由于事实表具有稀疏性质 ,因此只有当天数据才会进入 当天的事实表中,相当于每个分区里面都是每天的数据,不包含之前的数据。 

事务事实表的日期维度记录的是事务发生的日期,它记录的事实是事务活动的内容。用户可以通过事务事实表对事务行为进行特别详细的分析。

为什么事务事实表具有稀疏性质?

事实表一般围绕着度量来建立,当度量产生的时候,事实记录就生成了。度量可以是销售数量、交易流水值、月末节余等数值。如果同时生成多个度量值的话,我们可以在一个事实表中建立多个事实。当我们的事实表中的事实比较多时,有可能多个事实不同时发生,如果同时生成的几率很小,我们称之为稀疏事实表(Sparse Facts)。

来自http://wenda.tianya.cn/answer/1eb54dc6c0a17b11000481a632d86094

2.周期快照事实表
周期快照事实表以具有规律性的、可预见的时间间隔来记录事实,时间间隔如每天、每月、每年等等。典型的例子如销售日快照表、库存日快照表等。它统计的是间隔周期内的度量统计,如历史至今、自然年至今、季度至今等等

周期快照表没有粒度的概念,取而代之的是周期+状态度量的组合,如历史至今的订单总数,其中历史至今是一个周期,订单总数是度量。

周期快照事实表的粒度是每个时间段一条记录,通常比事务事实表的粒度要粗,是在事务事实表之上建立的聚集表,比如说时间周期是1周,那么这个周期快照事实表的一条记录就是这一周的对于某个度量的统计值(我理解的)。

周期快照事实表的维度个数比事务事实表要少,但是记录的事实要比事务事实表多(为什么记录的事会比事务事实表表多呢?)。事务事实表是稀疏表,周期快照表是稠密表。

什么是稀疏表,什么是稠密表?

稀疏表:当天只有发生了操作才会有记录

稠密表:当天没有操作也会有记录,便于下游使用

周期快照事实表的日期维度通常是记录时间段的终止日,记录的事实是这个时间段内一些聚集事实值。事实表的数据一旦插入即不能更改,其更新方式为增量更新。

为什么周期快照事实表纪录的纪录会比事务事实表多呢?

根据阿里大数据之路第11章212页所说:

事务事实表是 稀疏的,只有当天发生的业务过程,事实表才会记录该业务过程的事 实, 如下单、支付等;而快照事实表是稠密的,无论当天是否有业务过程发 生,都会记录一行,比如针对卖家的历史至今的下单和支付金额,无论 当天卖家是否有下单支付事实,都会给该卖家记录一行。

假如卖家之前下单6笔,昨天没有下单,但是还是会给他在昨天的分区里面纪录它截止目前为止下单6笔的纪录。

 
3.累计快照事实表
累积快照事实表和周期快照事实表有些相似之处,它们存储的都是事务数据的快照信息。但是它们之间也有着很大的不同,周期快照事实表记录的确定的周期的数据,而累积快照事实表记录的不确定的周期的数据。累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度,它通常具有多个日期字段,用来记录整个生命周期中的关键时间点。例如订单累计快照事实表会有付款日期,发货日期,收货日期等时间点。

事务事实表中一条交易记录会每天有一条数据来记录整个交易过程;而累积快照事实表只会有一条记录,数据会一致更新直到过程结束。

累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度,它通常具有多个日期字段,用来记录整个生命周期中的关键时间点。另外,它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的,所以必须使用代理关键字来处理未定义的日期,而且这类事实表在数据加载完后,是可以对它进行更新的,来补充随后知道的日期信息。

周期快照事实表记录的是重复的可预测到的时间间隔的事实,例如帐户月结余事实表,用来记录每个月末的帐户结余信息。一般周期快照的数据会按报表需要的周期进行记录,比较适合周期长一些的情况。

而累计快照适用于较短周期,有着明确的开始和结束状态的过程,如一个订单执行的过程,并记录过程中每个步骤的执行时间,使分析人员对执行的过程有整体的把握。周期快照事实表记录上每个步骤的执行时间是逐步建立的,随着执行的过程逐步更新的事实表中。

最后来用表格比较一下三种事实表的区别:

参考文章:

https://www.jianshu.com/p/453afb5382ea

https://www.jianshu.com/p/ff8dcb089d3d

https://www.jianshu.com/p/f55238c6e0b4

https://blog.youkuaiyun.com/maenlai0086/article/details/93998924

 
————————————————
版权声明:本文为优快云博主「泽米」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.youkuaiyun.com/a6822342/article/details/99189806

<think>嗯,用户问为什么库存数据要保存成快照表而不是事务事实表。让我先回忆一下之前讨论过的维度建模中的事实表类型。库存数据通常变化频繁,比如每天的入库、出库,但用户可能需要定期查看某个时间点的库存量。 首先,我需要明确事务事实表周期快照事实表的区别。事务事实表记录每个事件,比如每次销售或采购,而周期快照则是定期记录状态,比如每天结束时的库存量。库存属于状态型数据,用户关心的是某个时刻的存量,而不是每次变动的事件。如果使用事务事实表,要计算某天的库存,可能需要汇总所有之前的事件,这在数据量大时效率不高,而且可能遗漏某些时段的情况。 另外,用户可能没有考虑到历史状态的重建问题。事务表虽然记录了每次变动,但随着时间的推移,要回溯某一天的确切库存量可能需要复杂的计算,尤其是当数据量很大时,这会影响查询性能。而快照表直接存储了每天结束时的库存,查询起来简单快捷。 还有,库存可能有多个维度,比如仓库、商品等,周期快照可以方便地与这些维度关联,提供多维度的分析。而事务表虽然详细,但可能需要复杂的关联和计算才能得到同样的分析结果。 可能用户的实际需求是需要快速生成报表或者进行趋势分析,这时候快照表的预聚合特性会更高效。此外,如果库存数据需要与其他周期性数据(比如销售周期)结合分析,使用快照表可以保持时间粒度的一致性,减少处理复杂度。 不过,用户可能担心存储开销,因为快照表每天都要记录所有商品的库存,即使没有变化。这时候可能需要权衡存储成本和查询效率,或者采用一些优化策略,比如只记录有变化的库存项。 总结下来,使用快照表主要是为了查询效率、简化复杂计算以及方便历史状态追踪,而事务表更适合需要详细事件分析的场景。用户可能需要根据具体业务需求选择合适的事实表类型,或者结合两者使用。</think>好的!库存数据存储为**周期快照事实表**而非事务事实表,是出于业务分析效率、数据聚合复杂度等多方面的权衡。以下是详细解释: --- ### **一、核心原因:业务场景的差异** #### 1. **事务事实表的特点** - **记录事件**:每次库存变动(如入库、出库、调拨)都会生成一条记录。 - **数据粒度**:细粒度,能精确追踪每一次操作的明细。 - **缺点**: - 要计算某个时间点的库存量,需**累加所有历史事件**(如初始库存 + 入库总量 - 出库总量)。 - 当数据量庞大时,计算效率低且容易出错。 #### 2. **周期快照事实表的优势** - **直接记录状态**:按固定周期(如每天、每小时)记录当前库存量。 - **数据粒度**:粗粒度,但可直接查询某个时间点的库存状态。 - **优点**: - **查询高效**:无需复杂计算,直接获取结果。 - **支持历史状态分析**:例如对比不同日期的库存变化趋势。 - **避免累计误差**:事务记录的丢失或错误不会影响快照数据的准确性。 --- ### **二、具体场景对比** #### 案例:计算“2023年10月1日”的库存量 - **事务事实表的实现方式**: ```sql SELECT SUM(CASE WHEN operation_type = '入库' THEN quantity WHEN operation_type = '出库' THEN -quantity END) AS current_stock FROM inventory_transaction_fact WHERE operation_time <= '2023-10-01 23:59:59'; ``` - **问题**:需要扫描所有历史记录,性能差;若事务表存在数据缺失,结果可能错误。 - **周期快照表的实现方式**: ```sql SELECT stock_quantity FROM inventory_snapshot_fact WHERE snapshot_date = '2023-10-01'; ``` - **优势**:直接命中结果,查询速度极快。 --- ### **三、为什么不用事务表?关键限制** 1. **性能瓶颈** - 事务表中数据量随操作次数线性增长,频繁的全表扫描会导致查询延迟。 - 快照表通过预计算状态,避免实时聚合。 2. **分析需求不同** - 业务往往需要回答: - “昨天仓库中有多少库存?”(快照表直接回答) - “过去30天库存波动趋势如何?”(快照表按日统计更简单) - 而事务表更适合回答: - “某个商品的入库频率如何?” - “某次出库操作的负责人是谁?” 3. **数据冗余与存储成本** - 事务表需要存储每次操作的明细,而快照表仅存储关键时间点的状态。 - **权衡**:快照表牺牲部分存储空间换取查询效率。 --- ### **四、实际设计中的混合方案** 大型系统中,通常**同时使用两种表**: 1. **事务事实表**:记录所有库存变动事件(用于审计、明细查询)。 2. **周期快照事实表**:按天/小时生成快照(用于报表、趋势分析)。 #### 示例:电商库存管理 - **事务表**: | 时间戳 | 商品ID | 操作类型 | 数量 | 仓库ID | |------------------|--------|----------|------|--------| | 2023-10-01 09:00 | P001 | 入库 | 100 | W01 | | 2023-10-01 14:00 | P001 | 出库 | 50 | W01 | - **快照表**: | 日期 | 商品ID | 仓库ID | 库存量 | |------------|--------|--------|--------| | 2023-10-01 | P001 | W01 | 50 | --- ### **五、总结:如何选择?** | **场景** | **推荐表类型** | **原因** | |------------------------|--------------------------|---------------------------------------| | 需要实时跟踪每次操作 | 事务事实表 | 记录明细,支持操作溯源 | | 需要快速查询历史状态 | 周期快照事实表 | 避免复杂计算,直接读取结果 | | 高频分析(如日报、月报)| 快照表 + 事务表辅助 | 平衡性能与灵活性 | **核心原则**: - **快照表**用于高效回答“**当前/历史状态是什么**”。 - **事务表**用于回答“**为什么会变成这样**”。 通过结合两者,既能满足业务分析需求,又能优化系统性能。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值