数据仓库暂存区内的结构答案

【问题标题】：Structure within staging area of data warehouse数据仓库暂存区内的结构
【发布时间】：2009-05-14 13:43:37
【问题描述】：

我们正在为一家银行开发数据仓库，并且几乎遵循标准的 Kimball 临时表模型、星型模式和 ETL 来通过流程提取数据。

Kimball 谈到使用暂存区进行导入、清理、处理和一切操作，直到您准备好将数据放入星型模式。在实践中，这通常意味着将数据从源上传到一组表中，几乎没有修改，然后选择性地通过中间表获取数据，直到它准备好进入星型模式。这对单个实体来说是很多工作，这里没有单一的责任。

我以前工作过的系统对不同的表集进行了区分，达到了这样的程度：

上传表格：原始源系统数据，未修改
暂存表：中间处理、类型化和清理
仓库表

您可以将它们粘贴在单独的架构中，然后为存档/备份/安全等应用不同的策略。其他人之一曾在一个仓库工作，其中有一个 StagingInput 和一个 StagingOutput，类似的故事。整个团队在数据仓库和其他方面都拥有丰富的经验。

然而，尽管如此，纵观 Kimball 和网络，似乎完全没有关于为暂存数据库提供任何类型的结构的书面文件。如果相信 Kimball 先生会让我们所有人都将分期工作作为这个庞大的深黑色非结构化数据池，那将是可以原谅的。

当然，如果我们想为暂存区添加更多结构，该怎么做是很明显的，但似乎没有任何关于它的文章似乎很奇怪。

那么，其他人都在做什么呢？只是上演这么大的非结构化混乱还是人们有一些有趣的设计？

【问题讨论】：

标签： sql database-design data-warehouse

【解决方案1】：

我也遇到过同样的问题。我们有一个大型 HR 数据仓库，我正在从整个企业的系统中提取数据。我收集了很多 Fact 和 Dimension 表，但是暂存区一团糟。我不知道任何设计标准。我会遵循与您相同的路径，并提出一组标准的名称以使事情井井有条。您的建议对于命名非常好。我会继续努力。

【讨论】：

好奇，一个似乎没有人感兴趣的领域，但却影响着任何规模的每个 BI 项目。我想 Upload 和 Staging 的区别至少会给我们一些结构。

【解决方案2】：

请注意，Raph Kimball 和 Joe Caserta 有一本书名为“The Data Warehouse ETL Toolkit”，因此 Kimball 先生确实为此付出了一些努力。 :)

【讨论】：

本书未涵盖
是的，我也检查过。不知道为什么你在不引用页面的情况下引用它们 - 除非我找不到页面/部分。

【解决方案3】：

我们目前正在处理一个大型保险 DWH 项目，它有点复杂，但是每个源系统表都被放入 STAGING 数据库中的单独模式中，然后我们有移动/清理/符合的 ETL（MDM ) 将暂存数据库中的数据放入 STAGINGCLEAN 数据库，然后进一步 ETL 将数据移入 Kimball DWH。

我们发现 Staging 和 StagingClean 数据库的分离对于诊断问题非常有帮助，尤其是在数据质量方面，因为我们有脏的暂存数据以及在转换为 DWH 之前的清理版本。

【讨论】：

我们也通过定期导入生产数据库（不是数据仓库）来做到这一点。无法告诉您在试图表明问题出在他们的数据而不是我们的流程时，看到数百万条记录未被清理是多么容易。

【解决方案4】：

Staging 中可以有子区域。例如称为 staging1、staging2。

Staging1 可以直接从数据源中提取，无需转换。而Staging1 只保留最新的数据。

Staging2 保持数据转换并准备好进入仓库。 Staging2 保留所有历史数据。

【讨论】：

感谢 Ken，是的，这与我过去使用过的设计相似。我觉得奇怪的是没有任何关于它的出版物。
我个人不建议在表名末尾添加数字来表示数据库中的差异。如果我继承该架构，我的第一个想法会是，'哦，这些必须是团队从未删除过的废弃表'。

【解决方案5】：

看看这个帖子here。它很好地概述了 DW 中暂存区的职责。

【讨论】：

【解决方案6】：

真是个好问题。

过去我们使用_MIRR（用于镜像）后缀用于登陆数据库的未转换数据，即。它反映了源。然后我们将_STG 用于来自源的转换数据，然后使用_DW 用于星型模式。

此处的暂存表位于3NF。我认为这是关键点。数据未经转换并与下一步完全规范化数据分开，然后将其全部展平到我们的星型模式中以进行报告。

【讨论】：

【解决方案7】：

就我个人而言，我不会去金博尔或其他地方找麻烦。

您在寻找什么样的“结构”？你觉得需要什么样的“结构”？您今天从缺乏“结构”中看到了什么问题？

我可能会让您觉得我不太喜欢 Kimball。不是这样 - 我还没有读过金博尔。除了适应某种模式之外，我只是不考虑无缘无故地改变事情。改变以解决一些现实世界的问题会很好。例如，如果您发现备份暂存表是因为缺乏结构导致暂存表和仓库表被视为相同，那么这将是更改结构的原因。但如果这是您的想法，那么您应该编辑您的问题以表明它。

【讨论】：

我们现在看到这一点的驱动因素是，我们需要能够将“上传”过程与“暂存”过程分开，因为提要在不同时间可用。我们需要在提要可用时上传提要，然后运行处理 ETL 的其余部分。目前，整个暂存过程都混杂在一大系列任务中。除此之外，还需要编写结构化软件以满足我们的审计要求。
@Chris：那么你应该澄清你的问题。我读它是关于数据库中的表，而不是关于构建过程。这是一个完全不同的问题。
我认为我们不能将 ETL 的结构与表的结构完全分开。是的，我的问题主要是关于表结构（有大量没有 RI、约束或其他任何东西的表是违背规律的），但是 ETL 结构遵循表的排列方式。