管理数据仓库中的代理键

Question

我想构建一个数据仓库，并且想使用代理键作为事实表的主键。但问题是，就我而言，事实表应该更新。

第一个问题是如何在源系统中找到自然键对应的自动生成的代理键？我看到一些答案提到查找表存储自然键和代理键之间的对应关系，但我不明白它们到底是如何实现的。该表应该存储在哪里：数据仓库本身还是其他地方？

还有第二个问题。源系统已包含事实的代理键，但它们具有 16 字节的 UUID 数据类型。并且事实的数量不太可能超过最大整数值（4 字节）。我应该使用源系统提供的 UUID 来简化 ETL，还是应该执行更复杂的 ETL 并实现自己的整数代理键以获得更好的性能？

Answer 1

我想剩下的已经有了答案。我愿意为您提供关于管理和维护代理键的 2 美分。

在 Teradata 工作期间，我经常使用代理键。以下是我多年来学到的有关代理键的一些最佳实践。

1. 您仅从批准的主源（在您的情况下是特定的 API）生成代理键。不应允许许多 API 生成相同的域值。选择充当您的域值的主源的代理键。例如，客户编号通常来自CRM系统不太可能从计费系统为主）
2. 您生成并将它们存储在一个查找表中（我们称之为 Customer_SGK）。通常，这些代理键表不是 inmon 或 kimbal 方法中最终 LDM/PDM 的一部分。它们驻留在同一数据库服务器中，但位于技术元数据模式中。我们将该架构称为“My_Tec_Schema”
3. 在这样的查找表中，您将拥有代理键​​列（例如 Customer_ID）、每个主源的源自然键列（source1_customerNO、source2_customerNO）以及用于跟踪生成此键的时间的时间戳。
4. 您的 PK 是 Customer_ID，在此列中可能不是唯一的，因此根据所使用的数据存储技术，您可能必须将其分类为唯一或非唯一主索引/键（例如，在 Teradata 中，它将是 NUPI）。

5. 有时，您必须允许这样做来简化您的 ETL 流程，同时为来自 2 个不同源系统的两个不同自然键加载相同的客户 ID，但它们都表示同一个客户。

6. 有了这个查找表，您需要从阶段表/源加载它（生成键），这是 ETL 过程中的第一件事。然后，您从阶段左外连接与查找表加载以获取代理键并将其加载到您的事实表中，希望也加载到您的自然键中。（你总是希望拥有它们，因为大多数情况下你会在你的事实表中得到一些孤儿，而恢复这种情况的唯一快速可靠的方法是在你的事实表中拥有你的自然键并使用 PK 或 PI 或基于索引更新操作比全表扫描非常快）

7. 您始终可以通过表示层视图隐藏事实表中的自然键（该视图由消费应用程序和用户使用，同时保留表用于 ETL 目的/仅用于技术人员）
8. 由于您使用自动编号生成技术；在将数据从一种环境迁移到另一种环境时以及在主要版本期间迁移生产数据时，您必须特别注意。（你不想发生碰撞）

我可以继续谈论代理键。请在阅读此高级概述后提出任何具体问题。我很乐意提供帮助。