多个登台表的CDC策略

时间:2019-04-12 13:03:20

标签: etl data-warehouse cdc

我正在按照Kimball方法实施数据集市,并且在将多个源表的增量应用于单个目标维度方面遇到了挑战。

这是传入源数据的示例:

STG_APPLICATION
APP_ID, APP_NAME, APP_START_DATE, CDC_HASH, ...
1, FOOBAR, 20/10/2018, MD5_XXX

STG_APPLICATION_STATUS
APP_ID, STATUS_CODE, STATUS_DESC, CDC_HASH, ...
1, SUBMITTED, "APP WAS SUBMITTED", MD5_YYY

这些表中的每一个(还有其他几个表)代表源数据的规范化版本,即单个应用程序可以具有一个或多个与之关联的状态。

现在,由于我们仅获得这些表的完整Alpha,因此我们必须进行快照合并,即在当前记录集的基础上对每个单独表的前一天记录集应用完全外部联接。通过比较CDC_HASH(所有源列的连接)进行计算。比较结果存储在增量表中,如下所示:

STG_APPLICATION_DELTA
APP_ID, APP_NAME, APP_START_DATE, CDC_HASH, CDC_STATUS ...

STG_APPLICATION_STATUS
APP_ID, STATUS_CODE, STATUS_DESC, CDC_HASH, CDC_STATUS...
1, AWARDED, "APP WAS AWARDED", MD5_YYY,  NEW

因此,在此示例中,第一个表STG_APPLICATION不会生成增量记录,因为与该表有关的属性在每日负载之间没有变化。但是,关联的表STG_APPLICATION_STATUS确实计算了增量,即自上次加载以来一个或多个字段已更改。 CDC_STATUS将其突出显示,将其标识为要插入的新记录。

现在的问题当然是在加载目标尺寸时如何正确处理这种情况?例如:

DIM_APPLICATION
ID, APPLICATION_ID, APP_NAME, APP_START_DATE, APP_STATUS_CODE, FROM_DATE, TO_DATE
1, 1, FOOBAR, 20/10/2018, SUBMITTED, 20/10/2018, 12/04/2019
2, 1, NULL, NULL, NULL, AWARDED, 13/04/2019, 99/99/9999

这将显示第一条记录(基于已连接的这两个登台表)和第二条记录,该记录旨在反映该记录的更新版本。但是,如前所述,我的Delta表仅被部分填充,因此,我无法正确更新维度,如下所示。

从逻辑上讲,我了解我需要能够将维度使用的所有字段都包括在内,以作为增量计算的一部分,以便在更新维度时拥有完整记录的副本,但我没有确保在我的暂存区中实现此目标的最佳方法。如前所述,我目前只有独立的登台表,每个登台表分别计算其增量。

请问有人可以建议最好的处理方式吗?我正在仔细检查Kimball的书,但无济于事。同样,我也没有在任何在线论坛上找到合适的答案。这是一个常见问题,因此我确定存在合适的体系结构模式来解决此问题。

1 个答案:

答案 0 :(得分:0)

您将需要对联接的记录进行比较,或者查找当前的维值。

如果(不变的)数据量没有过多,则可以将STG_APPLICATION和STG_APPLICATION_STATUS的完整快照结合到APP_ID上,直到它们类似于按维度记录的维度并将它们与CDC哈希一起存储在单独的表中以供使用和前一天一样。然后,您可以在此级别获取增量,并将(完整的)更改的记录作为维度的更新发送。

如果每日更新中的记录量使连接完整表变得不切实际,则可以像现在一样使用增量和完整外部连接它们。然后,您为此APP_ID查找当前维记录,并填写增量记录中的所有空白字段。然后将完成的记录作为维度的更新发送。 该解决方案需要较少的存储空间,但似乎更脆弱,特别是如果一天之内可以进行多次更改的话。如果有很多更改,性能可能也会受到影响。对于数百万条记录中的少数更改,它应该更有效。