源中记录不唯一的DBT快照

Question

我很想知道这里是否有人在处理DBT中的快照时遇到过源并不总是唯一的情况。

我有一个数据湖，数据只在追加的基础上到达。每次源被更新时，都会在数据湖中的相应表上创建一个新的记录。

在运行DBT解决方案时，我的源可能有超过1行具有唯一id的行，因为自上次运行以来，数据已经更改了不止一次。

理想情况下，我希望使用源中最早的dbt_valid_to记录来更新快照表中的各个updated_at列，然后将新记录添加到快照表中，使最新的updated_at记录成为当前记录。我知道如何使用窗口函数来实现这一点，但不确定如何使用dbt来处理这种情况。我想知道以前是否有人遇到过同样的问题。

Snapshot Table

| **id** |   **some_attribute** |   **valid_from**      |   **valid_to**          |
|  123   |      ABCD            |   2021-01-01 00:00:00 |    2021-06-30 00:00:00  | 
|  123   |      ZABC            |   2021-06-30 00:00:00 |      null               |

Source Table

|**id**|**some_attribute**|   **updated_at**    |
| 123  |   ABCD           | 2021-01-01 00:00:00 |-> already been loaded to snapshot
| 123  |   ZABC           | 2021-06-30 00:00:00 |-> already been loaded to snapshot
 -------------------------------------------
| 123  |   ZZAB           | 2021-11-21 00:10:00 |
| 123  |   FXAB           | 2021-11-21 15:11:00 |

Snapshot Desired Result

| **id** |   **some_attribute** |   **valid_from**      |   **valid_to**          |
|  123   |      ABCD            |   2021-01-01 00:00:00 |    2021-06-30 00:00:00  | 
|  123   |      ZABC            |   2021-06-30 00:00:00 |    2021-11-21 00:10:00  |
|  123   |      ZZAB            |   2021-11-21 00:10:00 |    2021-11-21 15:11:00  | 
|  123   |      FXAB            |   2021-11-21 15:11:00 |    null                 | 

Answer 1

标准快照的运行假设是，我们正在拍摄的源表在没有存储历史的情况下被更改。这与我们在这里的行为是相反的(基本上，我们正在快照的源表只不过是事件的仅附加日志)-这意味着我们可以简单地使用一个无聊的旧incremental模型来实现与快照给我们的相同的SCD2结果。

我在这里有一些样例代码，可能会对https://gist.github.com/jeremyyeo/3a23f3fbcb72f10a17fc4d31b8a47854有所帮助

Answer 2

我同意，如果dbt快照有一个可以涉及重复数据删除的策略，那将是非常方便的，但目前还不支持。

最简单的变通方法是源代码下游的stage视图，它具有您所描述的窗口函数。然后，您可以为该视图创建快照。

然而，我确实看到了处理仅追加源代码的新快照策略的潜力。也许您想仔细阅读现有策略的dbt Snapshot docs和strategies source code，看看是否想要创建新的策略！