【发布时间】：2018-08-16 09:51:58
【问题描述】：
比方说，有一个 SCD2 维度表 - 位置。自然键是国家、州和城市的组合。由于是 SCD2 表，所以 eff 日期也是 key 的一部分。
将代理键设置为 usavirginarichmond20110101 还是使用 hive 中的 row_number() 创建实际的数字键更好？
为什么一种方法比另一种更好？
【问题讨论】：
标签： hive data-warehouse dimensional-modeling
【发布时间】：2018-08-16 09:51:58
【问题描述】：
您可以按有效日期进行分区，以便更快地过滤/加入仅具有生效日期的分区。
像usavirginarichmond20110101 这样的代理键会给你什么？完全扫描，因为过滤将在 substr 上。因此，将country, state, city and effective_date 单独作为键和effective_date 分区。
还有一点很重要：在 hive 中使用 row_number() 的数字键不是好的解决方案，因为它的生成不是在分布式模式下运行的。为此目的最好使用 GUID。
【讨论】：
-
这只是关键。国家、州、城市和有效日期列将是维度表中的附加属性。
-
@RaviR 好的。您将如何使用此密钥？如果更新比它不优于 4 个自然键
-
@vikrantrana 但是恕我直言，自然键是更好的解决方案。生成它们没有额外的开销，Hive 可以很好地处理长字符串和复合键。只是一个意见。
（术语注意：自然键的组合称为“复合键”，不是代理键，它仍然是“自然键”。代理键（又名合成键）是一个没有商业意义的连续整数）。
简短回答：由于您的维度是 SCD2，因此绝对要使用代理/合成键。使用自然/复合键处理 SCD 很痛苦。
更长的答案： 代理（SK）与自然键（NK）设计是一个持续的争论。每个都有优点和缺点。我的方法是始终在数据仓库 (DW) 中使用代理键。这意味着一些额外的 ETL 工作，但这是可以接受的成本，因为代理键具有一些重要优势：
SCD 处理要容易得多。如果你有 SCD，使用自然键是相当麻烦和丑陋的。合成密钥没有问题；
系统范围的一致性：由于 SCD，您很有可能必须在数据仓库中至少在某些表中使用 SK。因此，在所有表格中始终如一地使用它们是有意义的。混合 SK 和 NK 设计很难看；
复合 NK 通常可以是大而复杂的字母数字字符串。这意味着它们可能会大大增加表大小，并且连接可能会更慢。 SK 是一个简单的整数，具有可预测的大小和一致的连接速度；
NK 可能是 DW 中的错误和不稳定的来源。例如，一些数据库重复使用它们的自然键，因此它们的含义可能会随着时间而改变。在依赖 NK 的 DW 中，这是一场潜在的灾难。此外，NK 可能来自多种来源，并导致整合冲突。
还有其他考虑因素，但根据我的经验，系统地使用代理键可以使 DW 设计更加可靠和高效。
【讨论】：