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

Question

我已经从头到尾阅读了数据保险库书，但我仍在尝试解决与如何填充链接表（如何获取所有哈希值）相关的特定问题。来自 scalefree：大规模并行处理的博客，它展示了可以以完全并行的方式加载卫星和集线器，但它没有涉及与链接表相关的很多细节。

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

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

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

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

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

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

Answer 1

我和一位专家讨论过这个问题，这是我从他那里得到的答案：

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

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

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