使用分离数据库在设计数据仓库时的好处

Question

我正在设计数据仓库架构。

在探索从生产环境中提取数据并投入数据仓库的各种选择时，我遇到了许多主要建议以下两种方法的文章 -

1. 生产数据库 ----> 数据仓库（星型模式） ----> OLAP立方体
2. 生产数据库 ----> 暂存数据库 ----> 数据仓库（星型模式） ----> OLAP立方体

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

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

- Prateek Singh

Answer 1

以下内容摘自 DWBI组织 的文章：

如果您遇到以下情况之一，可能需要使用暂存区：

1.增量加载：从数据源读取数据并需要一个中间存储位置，在此处可以临时存储增量数据集以进行转换；

2.转换需求：在将数据用于仓库之前，需要执行数据清理、验证等操作；

3.解耦：处理过程需要很长时间，您不想在整个处理过程中始终连接到源系统（假定实际的业务用户正在不断使用源系统），因此更喜欢一次性从源系统读取数据，断开与源的连接，然后在“自己的一边”继续处理数据；

4.调试目的：您不需要一直返回源，可以仅从暂存区解决问题（如果有）；

5.失败恢复：源系统可能是短暂的，数据状态可能会发生变化。如果遇到任何上游故障，则可能无法重新提取数据，因为此时源已经发生了更改。拥有本地副本有助于解决该问题。

性能和减少处理时间可能不是唯一的考虑因素。添加暂存区有时可能会增加延迟（即业务事件发生和报告之间的时间延迟）。但我希望上述观点能够帮助您做出更好的判断。

- hashbrown

Answer 2

ETL = 提取（Extract）、转换（Transform）和加载（Load）。在转换方面，暂存数据库会提供帮助。个人建议始终包含一个暂存数据库和 ETL 步骤。

暂存数据库可协助将源数据转换为与数据仓库事实和维度目标结构等效的格式。它还将您的仓库和仓库 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 步骤可能只是从最近的夜间备份重新创建 DB。 （传统上，RAW_DB 用于从各种外部来源获取数据，每个字段均为纯文本，然后将这些字段转换为其预期的数据类型，并在遇到异常时处理。当您只有一个来源并且其为强类型规范化的数据库时，这不再是问题） 从这个 RAW_DB 中，下一个 ETL 过程将清除并填充 staging，使得 STAGING DB 包含即将进入仓库的所有新/更新记录。

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

- Joe

---

在这个实例中，[DM DB] 是什么？ - pim

DM_DB = 数据集市数据库。根据我们的设置，您维度化的数据仓库模式可能过于庞大、通用和复杂，不适合运行报告，特别是如果您的用户对时间点立方数据集不感兴趣。此外，数据集市可能只包含整个数据仓库数据库的子集（例如，会计部门可能只对工资数据感兴趣，人力资源部门可能只需要考勤数据）。 - Joe

Answer 3

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

• 如果合适的话，您可以对生产数据库进行快照（您可能已经有每日备份或热站点快照），然后从恢复的备份或快照中进行ETL。这可以节省生产数据库的负载。
• 您的ETL可能需要复杂的处理，需要许多中间表，这些表除了ETL过程之外没有任何用处。您可能不想在数据仓库中混杂这些中间表。
• 您的原始数据可能无法一次性全部获取，您需要在开始ETL过程之前累积它的地方，以构建数据仓库。
• 您的数据仓库可能有生产时间窗口要求，无法满足您的ETL需求，因此您需要将“输出”（即数据仓库的新记录）暂存在生产数据库之外或者同时存储在暂存数据库中。
• 生产系统可能处于高度安全的环境中，由于某种原因，决定不允许ETL进程完全访问原始生产数据。控制生产数据库的团队可能只想将必要的数据提取到暂存数据库中，以便ETL进程只能看到所需的内容。我曾经见过这种情况，其中生产系统和ETL进程由不同的第三方供应商管理。
• 可能您的ETL过程会创建大型的中间表。有时候，如果您从空模型数据库开始作为ETL暂存区域，然后每天“丢弃”它，而不是尝试以更精细的方式恢复空间（就像您对生产或报告数据库所做的那样），则空间管理会更容易。

也有可能存在一些缺点，这些缺点对您可能重要，也可能不重要。其中最主要的一个缺点就是需要另外一个数据库服务器。如果您使用同一个服务器来托管生产和/或数据仓库数据库，则许多优点可能没有意义。

- Joel Brown

Answer 4

实际上，如果我们能够在运行时处理数据，那么暂存区域就不是必需的。但是我们能做到吗？以下是无法避免使用暂存区域的几个原因： 1.源系统仅在特定时间段内提供抽取功能，这段时间通常比数据加载时间短。在失去与源系统连接之前，将数据抽取并保存在您的端点上是个好主意。 2.您想基于某些条件提取数据，这需要您同时连接两个或多个不同的系统。例如，您只想提取某些也存在于其他系统中的客户记录。您无法执行连接两个来自物理上不同数据库的表的 SQL 查询。 3.各个源系统为数据抽取分配了不同的时间。 4.数据仓库的数据加载频率与源系统的刷新频率不匹配。 5.从相同的一组源系统中提取的数据将在多个地方使用（例如数据仓库加载，ODS加载，第三方应用程序等）。 6. ETL 过程涉及复杂的数据转换，需要额外的空间临时暂存数据。 7.在预，过程和后负载数据验证中需要使用暂存区域进行特定数据对账/调试要求。

显然，暂存区域在数据加载期间提供了很大的灵活性，因此我们应该始终拥有一个单独的暂存区域吗？拥有暂存区域会产生影响吗？是的，有一些影响： 1.暂存区域会增加延迟时间，即源系统中的更改所需的时间在数据仓库中生效。在很多实时/准实时应用程序中，通常避免使用暂存区域。同时，暂存区域中的数据占用额外的空间。 2.在所有实际意义上，我的看法是，暂存区域的好处超过了它的问题。因此，在一般情况下，我建议在数据仓库项目中指定一个特定的暂存区域。

- Vishnu Kumar