数据仓库分期体系结构

Question

这是一个关于数据仓库设计的问题。我们正在建立一个医疗数据仓库，从两个主要的源系统开始，这些系统包含大约2万张表和2TB数据。1)这是高维数据2)我们不想严重影响OLTP系统

我们选择了一个递增的金球设计。我的问题是，是否所有的数据都是分阶段的，然后按插入/更新排序，然后放到数据仓库中。然后，将为下一个增量负载清除暂存数据。

这给您留下了1份数据副本。

另一种方法是将其增量加载到暂存中，将其排序为插入/更新，并以与源系统相同的格式存储。然后，我们将来自源系统的数据从完整的副本组合到数据仓库中。

这将给您留下两个数据副本，一个是源系统的形式，另一个是加载到实际数据仓库中的数据。

这方面的最佳做法是什么？我最初认为最好只将副本存储在数据仓库中，并清除每个加载的源表。

但是，在这种情况下，如果必须返回到现有维度并添加列，则必须重新加载所有依赖的源表。再加上你会失去历史？

存储它两次似乎效率很低，though....just想要一些关于设计、经验和最佳实践的想法。

Answer 1

就我个人而言，我有用于提取、转换和持久数据存储的分阶段表。

无论是完全导出还是增量加载，将取决于您拥有哪些工具、您的策略以及您的应用程序模式和数据是否支持它。有时你无法避免全部出口。

向维度添加列并不是什么大不了的事，但回填历史数据可能非常困难，或者根本不可能。试图重建一个应用程序如何回顾某个时间点将是一项重大任务。你需要一个很好的理由来证明这一点。

你提到的所有事情都是可能的，但只有你才能决定成本/效益是否值得。

Answer 2

这在很大程度上取决于你的规格。对于这样的项目来说，存储空间并不是很昂贵(20K表可能需要更大的开发预算)。

请记住，DWH通常应该比Source系统保持更多的历史记录，因此，如果您认为需要回顾并添加一个新的维度列或一个新的事实，那么一个很好的建议就是在Source系统和Kimball数据集市之间建立一个数据库。

您可以在数据集市层上获得详细的历史记录和更多的灵活性，这需要接近用户，因此需要很大的灵活性，才是可行的。

Answer 3

我们通常会发现，ODS (Operational，源系统的一个副本)首先对您的ETL流程进行分层(用于维护和故障排除)非常有用，但最终对于操作报告非常有用。

您还可以添加索引和编写疯狂的查询。反对它。

您还可以使用它来排除故障(因为您拥有加载数据的副本，而不是实际源中的移动目标)。然后，如果您可以让您的复制工具每五分钟向ODS中滴入提要，那么您就有了一个非常有用的架构。

忘掉这里的“低效”吧。当您无法对ETL进程进行故障排除时，您将遇到真正的低效率，因为ETL进程被压缩到一个层中，并且您没有ODS层可以进行故障排除。