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

以下几点来自DWBI Organization的文章

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

Delta Loading:您的数据从源中逐步读取,您需要一个中间存储,其中可以暂时存储增量的数据集以进行转换

转换需求:您需要在使用仓库中的数据之前执行数据清理,验证等

解耦:您的处理需要花费大量时间,并且您不希望在整个处理过程中保持与源系统的连接(可能是源系统经常被实际的业务用户使用),因此,更喜欢只需一次性读取源系统中的数据,断开与源的连接,然后继续在"自己的一侧"处理数据

调试目的:您无需一直回到源代码,只需从暂存区域解决问题(如果有的话)

故障恢复:源系统可能是暂时的,数据状态可能正在发生变化.如果遇到任何上游故障,您可能无法重新提取数据,因为此时源已更改.拥有本地副本有帮助

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

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

如果合适，您可以为生产数据库制作快照（您可能已经有每日备份或热点快照），然后从还原的备份或快照中进行ETL。这可以节省生产数据库上的负载。

您可能需要对ETL进行复杂的处理，这需要许多中间表，除了ETL流程外，这些中间表无用。您可能不希望这些中间表使数据仓库混乱。

您的原始数据可能无法一次全部获得，并且您需要在开始ETL流程以建立数据仓库之前积累一些数据。

您的数据仓库可能具有ETL不能满足的生产窗口要求，因此您需要暂存“输出”（即数据仓库的新记录），而不是在生产数据库之外或附加。

生产系统可能处于高度安全的环境中，并且出于任何原因，可能已做出决定，不允许ETL过程完全访问原始生产数据。控制生产数据库的组可能只希望将必要的数据提取到登台数据库，以便ETL流程只能看到其需要的内容。我已经看到了生产系统和ETL流程由不同的第三方供应商管理的情况。

您的ETL流程可能会创建大型中间表。如果您从一个空的ETL过渡区模型数据库开始然后每天“扔掉”空间，而不是像生产或报告数据库那样尝试以更外科的方式恢复空间，有时空间管理会更容易。

也可能存在不利因素，这可能对您无关紧要。其中最主要的是必须拥有另一个数据库服务器。如果您使用同一台服务器托管生产和/或数据仓库数据库，则许多优点可能毫无意义。

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

临时数据库有助于将源数据转换为与数据仓库FACT和DIMENSION目标等效的结构.它还将仓库和仓库ETL过程与源数据分离.

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

最终会将您的数据仓库解决方案直接绑定到源数据库

最有可能最终会出现一个非常复杂的ETL步骤

由于ETL过程中源数据库的更改,最终可能会出现竞争条件/孤立记录

数据仓库人员可能会发出"hrumph"类型的声音

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

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

[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过程引入了悲伤.