52、ETL子系统与技术解析

ETL子系统与技术解析

1. 累积快照事实表加载器

累积快照粒度代表具有明确开始和结束的流程的当前演变状态。通常，这些流程持续时间较短，因此不适合使用定期快照。订单处理就是累积快照的典型示例，订单在一个报告期内完成下单、发货和付款。事务粒度会将细节分散到各个事实表行中，而定期快照则不是报告此类数据的正确方式。

1.1 累积快照的设计与管理

累积快照事实表的设计和管理与前两种事实表类型有很大不同。所有累积快照事实表都有一组描述典型流程工作流的日期。例如，一个订单可能有订单日期、实际发货日期、交付日期、最终付款日期和退货日期。这些日期以五个单独的日期值外键代理键的形式出现。

当首次创建订单行时，第一个日期是明确的，但其他日期可能尚未发生。随着订单在订单管道中推进，会再次访问同一事实行。每次有事件发生时，累积快照事实行都会被破坏性修改，日期外键会被覆盖，各种事实也会被更新。通常，第一个日期保持不变，因为它描述了行的创建时间，但其他所有日期可能会被覆盖，有时甚至会多次覆盖。

1.2 性能优化

许多关系型数据库管理系统（RDBMS）使用可变行长度。由于这些可变行长度，对累积快照事实行的重复更新可能会导致行增长，从而影响磁盘块的驻留。为了提高性能，在更新活动后偶尔删除并重新加载行可能是值得的。

1.3 适用场景与局限性

累积快照事实表是表示具有明确开始和结束的有限流程的有效方式。然而，根据定义，累积快照是最新视图。通常，利用所有三种事实表类型来满足各种需求是有意义的。定期历史可以通过定期提取来捕获，而流程中涉及的所有无限细节可以在关联的事务粒度事实表中捕获。如果存在许多违反标准场景