Datavault：如何获取外键关系的哈希（填充链接表）

Posted 2023-03-29

【中文标题】Datavault：如何获取外键关系的哈希（填充链接表）

【英文标题】：Datavault: How to get hashes for foreign key relationships (populating link tables)

【发布时间】：2018-05-23 19:29:34

【问题描述】：

我已经端到端地阅读了数据保险库书籍，但我仍在尝试解决与您如何填充链接表（如何为此获取所有哈希值）相关的一个特定问题。来自 scalefree 的博客：massively parallel processing，它演示了卫星和集线器可以以完全并行的方式加载，但并没有涉及链接表相关的很多细节。

链接需要哈希键，因此以某种方式来自多个表的“业务键”来建立关系，这就是它们所做的，它们记录集线器之间的关系。在填充这些链接表时，没有很好的解释或深入的解释如何检索相关实体的业务键。

对于像“客户”这样的特定表，对于集线器和卫星来说，事情很容易：只需将业务密钥转换为哈希并并行加载它们。

但是来自 OLTP 的客户详细信息表或事务表需要某种联接来查找客户的业务密钥或查找事务中的所有相关实体（产品、客户、商店等） )，因为这些表通常不会将（所有）业务​​键作为属性存储在表中。

如果我假设 staging 是增量加载并被截断的，那么 staging 并不一定要加载所有实体才能在那里执行连接。如何解决这个困境并创造出有效的设计？

加入源 OLTP 系统中的表以从那里生成业务密钥并将它们作为散列从那里传播？ （如果业务密钥选择不正确，这最终会出错） 使用永久暂存区，所以永远不要截断？ （那么总是可以加入那里的任何表来解决） 为代理键使用某种索引 -> 业务键并从那里执行查找？ （进一步最小化 I/O 并且是增量分段和持久分段之间的混合）。 其他方法...？

本质上，为您的 OLTP 系统的所有外键关系生成哈希的最佳做法是什么？

【参考方案1】：

我和一位专家谈过这个问题，这是我从他那里接受的答案：

为没有为该表生成业务键所需的所有列的表生成哈希的唯一明智的两种方法是：

如果您已满载具有业务键的所有表（但对于链接表来说可能是增量的），请连接到具有暂存业务键的相关源表。这没关系，因为您可以保证此时您拥有暂存的所有数据。 如果您对具有业务键的表进行增量加载，则必须使用持久暂存区 (PSA) 为您执行此操作。

在源系统查询中连接表以生成业务键被认为是不好的做法。原因是数据仓库应该对运营产生尽可能小的影响。

【讨论】：

在源数据库的客户详细信息表中，业务键通常存储为外键。 （源系统必须以某种方式将详细记录与客户相关联）。因此，显然不需要在阶段或源系统中进行额外处理。