52、ETL 子系统与技术解析

最新推荐文章于 2025-12-13 05:08:20 发布

pca5navigator

最新推荐文章于 2025-12-13 05:08:20 发布

阅读量21

点赞数

CC 4.0 BY-SA版权

分类专栏：维度建模的艺术与实践文章标签： ETL 累积快照事实表代理键管道

本文链接：https://blog.youkuaiyun.com/pca5navigator/article/details/154568985

维度建模的艺术与实践专栏收录该内容

59 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

ETL 子系统与技术解析

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

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

累积快照的设计和管理与其他两种事实表类型有很大不同。所有累积快照事实表都有一组描述典型流程工作流的日期。例如，订单可能有订单日期、实际发货日期、交付日期、最终付款日期和退货日期，这些日期以单独的日期值外键代理键形式存在。当订单行首次创建时，第一个日期是明确的，但其他日期可能尚未发生。随着订单在处理流程中推进，会多次访问同一事实行，每次有事件发生时，累积快照事实行都会被修改，日期外键会被覆盖，各种事实也会更新。通常第一个日期保持不变，因为它描述了行的创建时间，而其他日期可能会被多次覆盖。

许多关系型数据库管理系统（RDBMS）采用可变行长度。对累积快照事实行的重复更新可能会因可变行长度导致行增长，影响磁盘块的驻留。因此，在更新活动后偶尔删除并重新加载行可能有助于提高性能。

累积快照事实表是表示具有明确开始和结束的有限流程的有效方式，但它代表的是最新视图。通常，可以结合使用三种事实表类型来满足不同需求。可以通过定期提取来捕获周期性历史数据，而与流程相关的所有详细信息可以在关联的事务粒度事实表中捕获。若存在许多违反标准场景或涉及流程重复循环的情况，则不适合使用累积快照。

2. 代理键管道子系统

每个 ETL 系统都必须包含一个步骤，用于将传入事实表行中的操作自然键替换为适当的维度代理键。参照完整性（RI）意味着事实表中的每个外键在相应的维度表中都有对应的条目。如果销售事实表中有一个产品代理键为 323442 的行，那么产品维度表中必须有相同键的行，否则就无法知道销售的是什么产品。

键查找过程应确保每个传入的自然键都能匹配到相应的值或默认值。如果在查找过程中出现未解决的参照完整性失败，需要将这些失败反馈给负责的 ETL 流程进行解决。同样，ETL 流程还需要解决键查找过程中可能遇到的任何键冲突。

以下是操作步骤：
1. 在事实表数据处理完成且即将加载到展示层之前，进行代理键查找，用适当的当前代理键替换事实表记录中的操作自然键。
2. 为了保持参照完整性，先完成维度表的更新，确保维度表是事实表中必须替换的主键的合法来源。
3. 最直接的方法是使用实际的维度表作为每个自然键对应的最新代理键值的来源。每次需要当前代理键时，查找维度中自然键等于所需值的所有行，然后使用当前行指示器或开始和结束生效日期选择与事实行历史上下文一致的代理键。
4. 在处理过程中，将传入事实记录中的每个自然键替换为正确的当前代理键，事实表中只应包含代理键。
5. 在所有事实行通过所有处理步骤之前，不要将输入数据写入磁盘。如果可能，将所有所需的维度表固定在内存中，以便在每个传入记录呈现其自然键时可以随机访问。
6. 代理键管道需要处理尝试加载重复行时的键冲突。若识别出键冲突，代理键管道过程可以选择暂停过程、将有问题的数据挂起，或应用适当的业务规则来确定是否可以纠正问题、加载该行并在错误事件模式中写入解释行。
7. 如果需要重新加载历史数据或有大量延迟到达的事实行，需要创建逻辑来查找事实记录生成时适用的代理键，即查找事实交易日期在键的有效开始日期和结束日期之间的代理键。

当事实表中的自然键被替换为代理键后，事实行就可以加载了，此时事实表行中的键是合适的外键，保证了事实表与维度表之间的参照完整性。

3. 多值维度桥接表构建器

有时，事实表必须支持在其最低粒度上具有多个值的维度。如果事实表的粒度无法直接支持该维度，则必须通过桥接表将多值维度与事实表关联起来。桥接表在医疗行业、销售佣金环境以及支持可变深度层次结构中很常见。

ETL 团队面临的挑战是构建和维护桥接表。当遇到与事实行的多值关系时，ETL 系统可以选择将每组观察结果作为唯一组，或者在出现相同观察结果集时重用组，但没有简单的选择方法。如果多值维度具有类型 2 属性，桥接表也必须是随时间变化的。

在某些情况下，桥接表会包含一个权重因子，以支持从桥接表进行正确加权的报告。在许多情况下，权重因子是常见的分配因子，但在其他情况下，确定合适的权重因子可能会有问题，因为可能没有合理的依据来分配该因子。

4. 延迟到达数据处理子系统

数据仓库通常基于这样的理想假设构建：测量活动（事实记录）与活动的上下文（维度记录）同时到达数据仓库。当同时拥有事实记录和正确的当代维度行时，可以先维护维度键，然后在相关事实行中使用这些最新键。然而，由于各种原因，ETL 系统可能需要处理延迟到达的事实或维度数据。

4.1 延迟到达的事实数据

在某些环境中，可能需要对标准处理程序进行特殊修改以处理延迟到达的事实数据，即延迟很久才进入仓库的事实记录。这是一个复杂的情况，因为需要回溯历史来确定活动发生时哪些维度键有效。此外，可能需要调整后续事实行中的半加性余额。在合规性要求较高的环境中，还需要与合规子系统进行交互，因为这涉及到更改历史数据。

4.2 延迟到达的维度数据

当活动测量（事实记录）到达数据仓库时没有完整的上下文，即与之关联的维度状态在一段时间内不明确或未知时，就会出现延迟到达的维度数据。在传统的批量更新周期中，可能只需等待维度数据报告即可。例如，新客户的识别可能会在几个小时后通过单独的数据源提供，可以等待依赖关系解决。

但在许多情况下，尤其是实时环境中，这种延迟是不可接受的。业务需求要求在知道维度上下文之前使事实行可见，因此 ETL 系统需要额外的功能来支持这一要求。以客户维度为例，ETL 系统需要支持以下两种情况：
1. 支持延迟到达的类型 2 维度更新 ：需要将修订后的客户行添加到维度中，并使用新的代理键，然后修改后续事实行中指向客户表的外键。还需要重置受影响维度行的有效日期，并扫描维度以查看该客户是否有后续的类型 2 行，并修改受影响行中的相应列。
2. 收到具有有效客户自然键但尚未加载到客户维度的事实行 ：可以将该行指向维度表中的默认行，但这种方法在最终处理维度更新时需要对事实行的外键进行破坏性更新。另一种方法是，如果认为客户是有效的但尚未处理，可以为新客户维度行分配一个新的客户代理键和一组虚拟属性值，在获得新客户的完整信息后，再对该虚拟维度行的属性进行类型 1 覆盖更改，这样可以避免对事实表键进行破坏性更改。

虽然无法避免维度存在“不太正确”的短暂临时时期，但这些维护步骤可以最大限度地减少对键和其他列的不可避免的更新的影响。

5. 维度管理系统子系统

维度管理器是一个集中的权威机构，负责准备并向数据仓库社区发布一致维度。一致维度必须是集中管理的资源，每个一致维度都必须有单一、一致的来源。维度管理器负责管理和发布其所负责的一致维度，其职责包括以下 ETL 处理：
1. 实施数据管理员和利益相关者在维度设计过程中商定的通用描述性标签。
2. 为新的源数据向一致维度添加新行，并生成新的代理键。
3. 为现有维度条目的类型 2 更改添加新行，并生成新的代理键。
4. 对类型 1 更改和类型 3 更改进行原地修改，不更改代理键。
5. 如果进行了任何类型 1 或类型 3 更改，更新维度的版本号。
6. 同时将修订后的维度复制到所有事实表提供者。

在单表空间数据库管理系统的单台机器上管理一致维度相对容易，因为维度表只有一个副本。但在多表空间、多数据库管理系统或多机分布式环境中，管理一致维度变得更加困难。在这些情况下，维度管理器必须仔细管理向每个事实提供者同时发布维度的新版本。每个一致维度的每行都应有一个版本号列，每次维度管理器发布维度时，该列都会被覆盖。该版本号可用于支持任何跨钻查询，以确保使用的是同一版本的维度。

6. 事实提供者系统子系统

事实提供者负责从维度管理器接收一致维度。事实提供者负责管理一个或多个事实表的创建、维护和使用。如果事实表用于任何跨钻应用程序，则事实提供者必须使用维度管理器提供的一致维度。事实提供者的职责更为复杂，包括：
1. 从维度管理器接收或下载复制的维度。
2. 在维度不能简单复制而必须进行本地更新的环境中，事实提供者必须处理标记为新的和当前的维度记录，以更新代理键管道中的当前键映射，同时处理标记为新的但日期后置的维度记录。
3. 在将自然键替换为正确的代理键后，将所有新行添加到事实表中。
4. 修改所有事实表中的行，以进行错误纠正、累积快照和处理延迟到达的维度更改。
5. 删除无效的聚合。
6. 重新计算受影响的聚合。如果维度的新版本未更改版本号，则只需扩展聚合以处理新加载的事实数据；如果维度的版本号发生了变化，则可能需要重新计算整个历史聚合。
7. 确保所有基础和聚合事实表的质量，确保聚合表计算正确。
8. 将更新后的事实表和维度表上线。
9. 通知用户数据库已更新，并告知是否进行了重大更改，包括维度版本更改、添加日期后置记录以及对历史聚合的更改。

7. 聚合构建器子系统

聚合是影响大型数据仓库环境性能的最显著方式。聚合类似于索引，是为提高性能而创建的特定数据结构，对性能有重大影响。ETL 系统需要有效地构建和使用聚合，同时避免造成重大干扰或消耗过多资源和处理周期。

应避免将聚合导航构建到专有查询工具中的架构。从 ETL 的角度来看，聚合构建器需要填充和维护聚合事实表行以及聚合事实表所需的缩减维度表。最快的更新策略是增量更新，但对维度属性的重大更改可能需要删除并重新构建聚合。在某些环境中，将数据从数据库管理系统中导出并使用排序实用程序构建聚合可能比在数据库管理系统内构建聚合更快。在提取时，可以通过在排序包中计算断点行来轻松聚合可加性数值事实。聚合必须始终与原子基础数据保持一致，当聚合与基础数据不一致时，事实提供者负责将聚合下线。

用户对运行缓慢的查询的反馈对于设计聚合至关重要。虽然可以在一定程度上依赖非正式反馈，但应记录经常尝试但运行缓慢的查询。还应尝试识别那些由于性能问题从未完成运行或甚至未被尝试的查询。

8. OLAP 立方体构建器子系统

OLAP 服务器以直观的方式呈现维度数据，使各类分析用户能够对数据进行切片和切块操作。OLAP 与关系数据库中的维度星型模式类似，服务器上定义了关于关系和计算的智能逻辑，能够实现更快的查询性能，并通过广泛的查询工具提供更有趣的分析功能。

以下是这些子系统的关系流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(累积快照事实表加载器):::process --> B(代理键管道子系统):::process
    B --> C(多值维度桥接表构建器):::process
    C --> D(延迟到达数据处理子系统):::process
    D --> E(维度管理系统子系统):::process
    E --> F(事实提供者系统子系统):::process
    F --> G(聚合构建器子系统):::process
    G --> H(OLAP 立方体构建器子系统):::process

通过以上各个子系统的协同工作，可以构建一个高效、稳定且功能强大的 ETL 系统，满足数据仓库在数据处理、存储和分析方面的需求。不同的子系统负责不同的任务，它们之间相互关联、相互影响，共同为数据仓库的正常运行提供支持。在实际应用中，需要根据具体的业务需求和数据特点，合理配置和管理这些子系统，以实现最佳的性能和效果。

9. 各子系统操作步骤总结

为了更清晰地展示各子系统的操作流程，下面对每个子系统的关键操作步骤进行总结：

9.1 累积快照事实表加载器

确定流程的有限开始和结束，如订单处理的各个阶段（下单、发货、付款等）。
为事实表定义描述流程工作流的日期列，如订单日期、实际发货日期等。
首次创建订单行时，确定第一个日期，其他日期可能为空。
随着订单在流程中推进，对事实行进行破坏性修改，更新日期外键和相关事实。
考虑定期删除并重新加载行以提高性能，特别是在使用可变行长度的 RDBMS 时。

9.2 代理键管道子系统

处理事实表数据后，在加载到展示层前进行代理键查找。
先更新维度表以保证参照完整性。
使用维度表查找与自然键对应的最新代理键。
将事实记录中的自然键替换为代理键，仅保留代理键在事实表中。
处理过程中避免将输入数据写入磁盘，尽量将维度表固定在内存中。
解决键冲突，可选择暂停、挂起数据或应用业务规则处理。
对于历史数据或延迟到达的事实行，查找适用的代理键。

9.3 多值维度桥接表构建器

识别需要通过桥接表关联的多值维度。
决定如何处理多值关系，如将每组观察结果作为唯一组或重用相同组。
若多值维度有类型 2 属性，确保桥接表随时间变化。
考虑在桥接表中添加权重因子以支持加权报告，确定合适的权重因子。

9.4 延迟到达数据处理子系统

9.4.1 延迟到达的事实数据

对标准处理程序进行特殊修改以处理延迟事实数据。
回溯历史确定活动发生时有效的维度键。
调整后续事实行中的半加性余额。
在合规环境中与合规子系统交互。

9.4.2 延迟到达的维度数据

在传统批量更新周期中等待维度数据报告。
在实时环境中，支持延迟到达的类型 2 维度更新，修改事实行外键和维度行有效日期。
处理具有有效自然键但未加载到维度的事实行，可指向默认行或分配新代理键和虚拟属性值。

9.5 维度管理系统子系统

实施维度设计中商定的通用描述性标签。
为新源数据和类型 2 更改添加新行并生成新代理键。
对类型 1 和类型 3 更改进行原地修改，不改变代理键。
更新维度版本号。
同时将修订后的维度复制到所有事实表提供者。

9.6 事实提供者系统子系统

从维度管理器接收或下载复制的维度。
处理标记为新的和当前的维度记录，更新代理键管道中的键映射。
替换事实表行的自然键为代理键后添加新行。
修改事实表行进行错误纠正、累积快照和处理延迟维度更改。
删除无效聚合，重新计算受影响的聚合。
确保基础和聚合事实表的质量。
将更新后的表上线并通知用户。

9.7 聚合构建器子系统

避免将聚合导航构建到专有查询工具中。
填充和维护聚合事实表行和缩减维度表。
采用增量更新策略，必要时删除并重新构建聚合。
考虑使用排序实用程序构建聚合。
确保聚合与原子基础数据一致，不一致时将聚合下线。
收集用户对慢查询的反馈以设计聚合。

9.8 OLAP 立方体构建器子系统

利用 OLAP 服务器以直观方式呈现维度数据。
借助服务器上的关系和计算逻辑实现快速查询和有趣的分析。

10. 子系统交互示例

为了更好地理解各子系统之间的交互，下面给出一个简单的示例流程：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(数据源):::process --> B(累积快照事实表加载器):::process
    B --> C(代理键管道子系统):::process
    C --> D(多值维度桥接表构建器):::process
    D --> E(延迟到达数据处理子系统):::process
    E --> F(维度管理系统子系统):::process
    F --> G(事实提供者系统子系统):::process
    G --> H(聚合构建器子系统):::process
    H --> I(OLAP 立方体构建器子系统):::process
    I --> J(数据分析用户):::process

在这个示例中，数据从数据源开始，首先经过累积快照事实表加载器处理，然后依次通过各个子系统，最终到达 OLAP 立方体构建器子系统，为数据分析用户提供直观的数据展示和分析功能。每个子系统在这个过程中都发挥着关键作用，确保数据的准确性、完整性和可用性。

11. 总结

通过对 ETL 各子系统的详细解析，我们了解到每个子系统都有其独特的功能和重要性。累积快照事实表加载器适用于表示有限流程的当前状态；代理键管道子系统保证了事实表与维度表之间的参照完整性；多值维度桥接表构建器处理复杂的维度关联；延迟到达数据处理子系统解决了数据延迟带来的问题；维度管理系统子系统统一管理一致维度；事实提供者系统子系统负责事实表的全面管理；聚合构建器子系统提升了数据仓库的性能；OLAP 立方体构建器子系统为用户提供了强大的数据分析能力。

在实际应用中，需要根据具体的业务需求和数据特点，合理配置和管理这些子系统。各子系统之间的协同工作是构建高效、稳定且功能强大的 ETL 系统的关键。通过遵循上述操作步骤和注意事项，可以更好地发挥各子系统的优势，满足数据仓库在数据处理、存储和分析方面的各种需求。

综上所述，深入理解和掌握 ETL 子系统与技术，对于提升数据仓库的性能和价值具有重要意义。希望本文能为相关从业者提供有价值的参考和指导。