5

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

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

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

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

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

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

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

4

1 回答 1

3

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

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

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

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

于 2018-06-02T05:49:00.543 回答