Ruby on rails 如何以增量方式填充数据仓库？

我开发了几个应用程序，并与其他开发人员进行了交谈，他们对数据仓库的一些细节存在问题

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

可以通过在每个表上插入触发器来处理更新，这些触发器会自动使用当前时间戳更新更新的_at列。不过，删除更难——一种解决方案是在其中放入触发器，用删除的id、表和时间戳更新审核表

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

我的问题是，人们通常如何处理这个问题？我做了很多研究，看起来很多做数据仓库的公司都在推出自己的次优解决方案

---

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

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

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

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

源系统中的更新

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

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

另一个选项是在源系统中更新触发器以更新上次修改的日期。如果在您提取数据时有什么东西正在ODS上进行大规模更新，请将此日期保持在非常高的精度，以减少“丢失”记录的风险

在源系统中删除

---

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

我指的是有人删除生产数据库中的记录，而不是数据仓库中的记录。除非事实表是一个累积的快照事实。。。然后每天都会更新。作为补充：解析ODS日志文件通常是主要ETL供应商的CDC工具所做的。解析日志不适合胆小的人，我建议使用触发器或我提到的其他方法。