如何逐步填充数据仓库？

Question

我参与了多个应用程序，并与其他开发人员进行了交谈，这些开发人员遇到了数据仓库的几个细节问题。

我看到的主要问题是运营数据存储中的变更数据检测（CDC）。 显然，在运营数据存储中很难检测到更新和硬删除。

可以通过在EVERY表上插入触发器来处理更新，该表自动使用当前时间戳更新updated_at列。删除更难 - 一个解决方案是在触发器中更新已删除id的审计表，表和时间戳。

使用触发器似乎是更改数据检测的最合理方式，但我看到的另一个选项是解析数据库事务日志文件，但这可能会使更新操作数据存储数据库变得更加困难。

我的问题是，人们通常如何处理此问题？我做了一些研究，看起来很多正在进行数据仓库的公司正在推出他们自己的次优解决方案。

我见过避免与CDC相关的问题的另一个解决方案是每隔一段时间简单地重建整个ENTIRE（或与源数据相关的部分）数据仓库，这将确保所有数据都是最新的在操作数据存储上执行CDC的代码中没有错误。

Answer 1

这是我通常处理更新和删除的方式。

源系统中的更新

某些DBMS提供了一个列，如果添加到所有表中，则为仓库提供始终增加的唯一标识符。 SQL Server具有TIMESTAMP列。 Oracle提供了ora_rowscn伪列，它在块级别上表现优异。

虽然我没有使用它，但Postgres有xmin伪列，我相信它可以以类似的方式使用。对它有一些担忧，但我认为对于数据仓库更改跟踪目的，它可能会有所作为。

源系统中更新上次修改日期的UPDATE触发器是另一种选择。将此日期保持在非常高的精度，以便在执行提取时，如果正在运行ODS上的大量更新，则可以降低“丢失”记录的风险。

在源系统中删除

对于已删除的记录，我首选的解决方案是确保所有源表都有一个主键（最好是一列，但多个是可行的）。我每天将此列的整体提取到阶段表中，然后识别目标表中与源相比“缺少”的行，更新“源已删除”标记或目标记录上的某些内容。我通常只对维度表执行此操作，因为即使原始事务已经消失，事实表也应保留历史记录。

Answer 2

作为postgresql用户和开发人员，使用你所描述的触发器是-IMHO--最好的方法。让数据库按照预期的方式执行：管理和保护您的数据。使用更新日期和使用删除日期处理的逻辑删除可以更轻松地提供事务的历史记录。使用低负载时段将“已删除”数据移动到历史表有助于保持生产表的可管理性。

Answer 3

我认为在正确设计的数据仓库中不应删除或更新事实表，只能插入。然后，通过时间戳或通过一些顺序ID来捕获插入应该是微不足道的。