💭

dbt snapshotの"dbt_updated_at"の正体

2024/09/03に公開

きっかけ

  • dbt snapshotを使用してみて、騙された想像と違っていたものを、備忘録として整理しておくことにする

想像と違っていたこと

  • strategyによって、格納される値が変わる
  • snapshot上でレコードの更新があっても、"dbt_updated_at"は初回に登録された値のまま

snapshotのソースとなるテーブル

  • dbt seedでLoadするために、csvで用意
  • 使用するデータウェアハウス製品はBigQueryです
1回目用ソース
id,name,created_at,updated_at
1,A,2024-09-01T01:00:00+00:00,2024-09-01T01:00:00+00:00
2,B,2024-09-01T01:00:00+00:00,2024-09-01T01:00:00+00:00
2回目用ソース
id,name,created_at,updated_at
1,AA,2024-09-01T01:00:00+00:00,2024-09-01T02:00:00+00:00  -- 更新
2,B,2024-09-01T01:00:00+00:00,2024-09-01T01:00:00+00:00   -- 不変
3,C,2024-09-01T02:00:00+00:00,2024-09-01T02:00:00+00:00   -- 新規

strategy='timestamp'の場合

  • dbt_updated_at: snapshotのconfigで指定した "ソーステーブルの更新日時"
  • 指定した"ソーステーブルの更新日時"のカラムに依存してデータ型も変わる
    • →このデータ型は "dbt_valid_from""dbt_valid_to" にも影響する
snapshotモデル
{% snapshot snapshot_timestamp %}

{{
    config(
      target_schema='data_lake',
      unique_key='id',
      strategy='timestamp',
      updated_at='updated_at',  -- ソース側の"更新日時"に該当するカラムを指定
    )
}}

select
    id,
    name,
    created_at,
    updated_at
from {{ source("dev", "raw_product") }}

{% endsnapshot %}

1回目のsnapshot

2回目のsnapshot

snapshot固有のカラムのデータ型について

updated_atで指定するカラムがTIMESTAMP型の場合

updated_atで指定するカラムがDATETIME型の場合

strategy='check'の場合

  • dbt_updated_at: snapshotにレコードが新規登録されたタイミングの "システムタイムスタンプ"
snapshotモデル
{% snapshot snapshot_check %}

{{
    config(
      target_schema='data_lake',
      unique_key='id',
      strategy='check',
      check_cols=[
        'id',
        'name',
        'created_at',
        'updated_at'
      ],
    )
}}

select
    id,
    name,
    created_at,
    updated_at
from {{ source("dev", "raw_product") }}

{% endsnapshot %}

1回目のsnapshot

2回目のsnapshot

参考記事

Discussion