Hive 使用代理密钥或nk+更好吗；apache配置单元中维度表中的有效时间

比如说，有一个SCD2维度表-位置。自然的关键是国家、州和城市的结合。由于它是SCD2表，eff date也是键的一部分

使用USAVIGINARICHMOND20110101作为代理键更好，还是在配置单元中使用row_number（）创建实际的数字键更好

---

为什么一种方法优于另一种方法？

您可以按生效日期进行分区，以便更快地筛选/仅与只有生效日期的分区合并。 像这样的

usaviginarichmond20110101

代理键会给你什么？完全扫描，因为筛选将在substr上。因此，将

国家、州、城市和生效日期分别保留为键，并按
生效日期进行分区

还有一点很重要：在配置单元中使用row_number（）的数字键不是一个好的解决方案，因为它的生成不是在分布式模式下运行的。为此，最好使用GUID。
（术语说明：自然键的组合称为“复合键”，而不是代理键，它仍然是一个“自然键”。代理键（也称为合成键）是一个顺序整数，没有业务意义）

简短回答：因为您的维度是SCD2，所以一定要使用代理键/合成键。使用自然/复合键处理SCD是一件痛苦的事情

详细回答：
代理（SK）与自然键（NK）的设计是一场持续的争论。各有利弊。我的方法是在数据仓库（DW）中始终使用代理键。这意味着一些额外的ETL工作，但这是可以接受的成本，因为代理密钥有一些重要的优势：

SCD的处理要容易得多。如果您有SCD，使用自然关键点是相当麻烦和丑陋的。合成键没有问题

系统范围的一致性：由于SCD，您很可能必须在数据仓库中至少在某些表中使用SKs。因此，在所有表中一致使用它们是有意义的。混合SK和NK设计是丑陋的

复合NK通常可以是大型复杂的字母数字字符串。这意味着它们可能会大大增加表的大小，而联接可能会变慢。SK是一个简单的整数，具有可预测的大小和一致的连接速度

NKs可能是DW中错误和不稳定的来源。例如，一些数据库重复使用它们的自然键，因此它们的含义可能会随着时间的推移而改变。在依赖NKs的DW中，这是一个潜在的灾难。此外，NK可能来自多种来源，并导致集成冲突

还有其他考虑，但根据我的经验，系统地使用代理键可以使DW设计更加可靠和高效
 这将是关键。列country、state、city和eff date将是维度表中的附加属性。@RaviR ok。你将如何使用这把钥匙？如果进行更新，则不超过4次自然更新keys@vikrantrana但IMHO自然钥匙是更好的解决方案。生成它们时没有额外的开销，而配置单元可以很好地处理长字符串和复合键。只是一个意见。