💭
dbt snapshotの"dbt_updated_at"の正体
きっかけ
- 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
参考記事
- タイミーのokodooooon様の以下の記事が大変参考になりました
Discussion