设计数据仓库时使用临时数据库的好处

Question

我正在设计数据仓库架构。 在探索从生产中提取数据并放入数据仓库的各种选项时，我发现了许多文章，主要建议采用以下两种方法 -

  

  
1. 生产DB ----＆gt;数据仓库（Star Schema）----＆gt; OLAP Cube
  
2. 生产DB ----＆gt; 暂存数据库 ----＆gt;数据仓库（Star Schema）----＆gt; OLAP Cube
  

我仍然不确定哪种方法在性能方面更好，减少了生产数据库的处理负荷。

在设计数据仓库时，您发现哪种方法更好？

Answer 1

以下几点取自DWBI Organization's文章

如果您有以下任何一种情况，可能需要暂存区域：

1. Delta Loading ：您的数据是从源逐步读取的，您需要一个中间存储，其中可以临时存储增量数据集以进行转换
2. 转型需求：您需要在使用仓库中的数据之前执行数据清理，验证等。
3. 解除耦合：您的处理需要花费大量时间，并且您不希望在整个系统中保持与源系统的连接（可能是源系统经常被实际业务用户使用）您处理的时间，因此，更喜欢一次性从源系统读取数据，断开与源的连接，然后继续在“自己的一侧”处理数据
4. 调试目的：您无需一直回到自己的来源，只需从暂存区域解决问题（如果有的话）
5. 故障恢复：源系统可能是暂时的，数据状态可能正在发生变化。如果遇到任何上游故障，您可能无法重新提取数据，因为此时源已更改。有本地副本帮助

性能和减少处理可能不仅仅是考虑因素。添加分段有时可能会增加latency（即，在发生商业事件和报告之间的时间延迟）。但我希望以上几点可以帮助你做出更好的判断。

Answer 2

ETL =提取，转换和加载。使用Transform位暂存数据库的帮助。我个人总是包括一个登台DB和ETL步骤。

Staging数据库有助于将源数据转换为与数据仓库FACT和DIMENSION目标等效的结构。它还将您的仓库和仓库ETL流程与源数据分离。

如果您的数据仓库目标表几乎只使用一些其他维度字段映射您的生产数据库表，那么可以忽略暂存数据库。这将节省您一点开发时间。我不建议你这样做：

1. 最终会将您的数据仓库解决方案直接绑定到您的 源数据库
2. 最有可能最终会出现一个非常复杂的ETL步骤
3. 可能会因为比赛条件/孤儿记录而结束 ETL过程中源数据库中的更改
4. 数据仓库人员可能会发出“hrumph”类型的声音

最有可能的是，您将执行某种数据操作（将日期转换为DATE_DIM键，聚合值），在这种情况下，登台数据库将帮助您将转换逻辑和计算与数据仓库操作（标注数据）分开。

您可能也遇到过这种模式：

[PROD DB] -(ETL)->  [RAW DB] -(ETL)-> [STAGING DB] -(ETL)-> [DW DB]  -(ETL)-> [DM DB]

如果性能考虑很重要，您可能需要查看。在您的情况下，RAW_DB可能是生产数据库的精确1：1副本，创建它的ETL步骤可能只是从最近的夜间备份重新创建数据库。 （传统上RAW_DB用于从各种外部源获取数据，每个字段都是纯文本，这些字段然后转换为预期的数据类型，遇到异常处理。当你有一个源和它时，这不是一个问题。一个很好的强类型规范化数据库）

从这个RAW_DB中，下一个ETL过程将截断并填充分段，以便STAGING DB包含进入仓库的所有新/更新记录。

所有这些步骤的另一个好处是，它确实有助于调试奇怪的数据，因为对于任何给定的运行，您可以在每个差异数据库中查看记录值，并确定哪个ETL过程引入了悲伤。

Answer 3

使用中间登台数据库有一些潜在的优势，这可能适用于您的情况，也可能不适用。没有完美的，一刀切的解决方案。一些潜在的优势包括：

• 如果合适，您可以拍摄生产数据库的快照（您可能已经拥有每日备份或热站点快照），然后从还原的备份或快照执行ETL。这可以节省生产数据库的负载。
• 您的ETL可能需要复杂的处理，这需要许多中间表，除了ETL过程之外没有任何用处。您可能不希望使用这些中间表来混乱数据仓库。
• 您的原始数据可能无法一次全部使用，在开始ETL过程以构建数据仓库之前，您需要在某处积累它。
• 您的数据仓库可能具有ETL无法满足的生产窗口要求，因此您需要暂存“输出”（即数据仓库的新记录），而不是生产数据库。 / LI>
• 生产系统可能处于高度安全的环境中，无论出于何种原因，可能已决定不允许ETL过程完全访问原始生产数据。控制生产数据库的组可能只想将必要的数据提取到临时数据库，以便ETL过程只能看到它需要的内容。我已经看到了生产系统和ETL流程由不同的第三方供应商管理的地方。
• 可能是您的ETL过程创建了大型中间表。有时，如果您从ETL临时区域的空模型数据库开始，然后每天“扔掉”而不是尝试以更外科的方式恢复空间，就像使用生产或报告数据库那样，空间管理会更容易

也有可能存在的缺点，对您而言可能或不重要。其中最主要的是必须拥有另一个数据库服务器。如果您使用相同的服务器来托管生产和/或数据仓库数据库，那么许多优点可能毫无意义。

Answer 4

如果我们可以动态处理它，那么真正的临时区域并不是必需的。但我们可以吗？以下是您无法避开临时区域的几个原因： 1.源系统仅在特定期间可用于提取 时隙通常小于整体数据加载 时间。最好先提取并保留好的东西 你失去了与源系统的连接。 2.您希望根据某些条件提取数据，这些条件要求您将两个或多个不同的系统连接在一起。例如。您只想提取同样存在于其他系统中的客户。您将无法执行从两个物理上不同的数据库连接两个表的SQL查询。 3.各种源系统具有不同的分配时序用于数据提取。 4.数据仓库的数据加载频率与源系统的刷新频率不匹配 5.来自同一组源系统的提取数据将用于多个地方（数据仓库加载，ODS加载，第三方应用程序等） 6. ETL过程涉及复杂的数据转换，需要额外的空间来临时暂存数据 7.有特定的数据协调/调试要求，保证在加载数据验证之前，期间或之后使用暂存区域

显然，暂存区域在数据加载期间提供了很大的灵活性。那时候我们不应该有一个单独的集结区吗？有舞台区域有什么影响吗？是的，有一些。 1.暂存区域会增加延迟 - 这是源系统更改在数据仓库中生效所需的时间。在许多实时/近实时应用中，相当避免了暂存区域暂存区域中的数据占用了额外的空间 2.对我来说，从实际的角度来看，拥有一个集结区的好处超过了它的问题。因此，总的来说，我建议在数据仓库中指定一个特定的暂存区域     项目