如何逐步填充数据仓库？

Question

我已经开发了几个应用程序，并与其他在数据仓库的细节方面有问题的开发人员进行了交谈。

我看到的主要问题是关于操作数据存储中的变更数据检测(CDC)。显然，在操作数据存储中很难检测到更新和硬删除。。

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

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

我的问题是，人们通常如何处理这个问题，？我做了相当多的研究，似乎很多从事数据仓库的公司都在推出他们自己的次优解决方案。

为了避免与CDC相关的问题，我看到的另一个解决方案是每隔一段时间重新构建整个数据仓库(或与源数据相关的部分)，这将确保所有数据都是当前的，并且在操作数据存储上进行CDC操作的代码中没有错误。

Answer 1

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

源系统中的更新

有些DBMS提供了一个列，如果将该列添加到所有表中，就会为仓库提供一个不断增加的唯一标识符。Server具有时间戳列。Oracle提供了ora_rowscn伪block，这在块级别很好。

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

在源系统中更新更新上次修改日期的触发器是另一个选项。保持这一日期在一个非常高的精度，以减少“丢失”记录的风险，如果有东西正在运行大规模的更新在ODS上，当你做你的提取。

在源系统中删除

至于已删除的记录，我喜欢的解决方案是确保所有源表都有主键(最好是一列，尽管多列是可行的)。我每天将整个列提取到一个stage表中，然后与源、更新“源已删除”标志或目标记录上的某些内容相比较，从目标表中识别“缺少”的行。我通常只对维度表这样做，因为事实表应该保留历史记录，即使原始事务已经消失。

Answer 2

作为postgresql用户和开发人员，您所描述的使用触发器--IMHO--是最好的方法。让数据库执行它设计的任务:管理和保护您的数据。使用更新日期，以及使用删除日期处理的逻辑删除，可以更容易地提供事务的历史跟踪。使用低负载周期将“删除”数据移动到历史表有助于使生产表易于管理。

Answer 3

我认为，在设计正确的数据仓库中，不应该删除或更新事实表，只需要插入。然后，通过时间戳或某些顺序ID捕获插入应该是非常简单的。