趋近智
事务事实表记录实时发生的事件,而周期快照以固定间隔捕获状态。但这两种结构都不太适合分析业务流程的速率。当您需要了解一个实体通过流程所需的时间时,累加快照事实表就是标准的设计模式。
这种模式最常用于有明确起点和终点的流程。常见例子包括订单履行、保险理赔和抵押贷款申请。在这些情况下,业务方对离散事件的兴趣较小,更关注里程碑之间的时间长度。
累加快照的主要特点是,一行代表一个业务实体的整个生命周期。在事务模型中,一个订单经过“已创建”、“已发货”和“已送达”阶段会生成三条独立的记录。而在累加快照中,这会生成一条带有多个列的记录,这些列表示这些日期。
随着流程的推进,系统会更新这一行记录。我们不会为后续步骤插入新记录。相反,当达到里程碑时,我们会用新数据填充空字段。
累加快照事实表中单行记录的生命周期。该记录保留在表中,并随着业务流程的推进而接收更新。
这种结构创建了一个表,该表物理上比事务表更短但更宽。它包含更少的行,因为每个订单我们只有一条记录;但它有明显更多的列,以适应与每个阶段关联的各种日期和度量。
这种模式的一个显著特点是存在指向日期维度的多个外键。订单履行流程的典型模式可能包括:
订单日期键打包日期键发货日期键送达日期键在上一章中,我们讨论了角色扮演维度。这是该技术的主要应用场景。您维护一个物理上的单一Dim_Date表,但事实表多次与之连接。每次连接代表一个不同的作用:订单日期、发货日期等。
当一行首次创建时,只有订单日期键是已知的。其他日期键通常设置为默认的“未知”代理键(通常是 -1 或 0),或保留为 NULL,依据您的物理数据库限制。随着工作流的推进,ETL 过程会更新这些键以反映实际日期。
从这种设计中获得的主要分析能力是延迟的计算。延迟表示两个里程碑之间经过的时间。因为所有相关日期都存在于单行中,计算步骤之间的时间长度变成了一个简单的跨列算术运算。
如果您使用事务模式,计算“订单”和“发货”之间的时间将需要复杂的自连接或窗口函数,以找到两个不同的事件行。在累加快照中,查询很简单:
您可以在 ETL 过程中预先计算这些延迟,并将它们作为可加事实存储在表中。这使得分析师可以轻松地平均延迟时间。例如,您可以计算特定区域所有订单的平均发货时间,而无需在查询时执行昂贵的日期计算。
履行不同阶段的平均延迟时间比较。使用累加快照时,这种分析的计算成本较低。
尽管累加快照对于分析来说效力强大,但它们在现代数据仓库中带来技术开销。大多数分析型数据库(如 Snowflake、BigQuery 或 Redshift)使用针对读取和追加数据优化的列式存储。它们未针对行级更新进行优化。
累加快照非常依赖 UPDATE 语句。每次订单进入下一阶段时,流程必须找到现有行并修改它。在高并发环境中,这可能导致性能瓶颈。
为了缓解这种情况,数据工程师通常采用特定的策略:
MERGE 语句,能高效处理批量更新,而不是逐行修改。识别何时不需要累加快照很重要。如果工作流没有明确的结束状态,或者如果实体之间的路径差异很大,这种模式就会失效。
例如,分析网站用户会话通常更适合使用事务模型。一个用户可能访问三页或三百页。他们可能会来回跳转。尝试将变长活动流扁平化成为累加快照中固定的列集合,将导致稀疏、难以管理的表结构。
累加快照仅适用于那些具有标准、可预测里程碑序列的流程,其主要分析目标是衡量流程的效率和速率。
这部分内容有帮助吗?
© 2026 ApX Machine LearningAI伦理与透明度•