dbt Snapshots による履歴化：timestamp / check 戦略の使い分け

dbt の Snapshot は、ソースの行が変化したときに履歴行を増やし、有効期間を管理することで SCD Type 2 を実現します。代表的な戦略は timestamp と check の2つで、どちらも unique_key が必須です。

本稿では、2つの戦略の選定基準、よくある落とし穴、倉庫別の実務チューニング、試験で狙われやすい論点を、公式ドキュメントの挙動に沿って解説します。

Snapshot の基本と生成カラム

dbt の Snapshot は、SELECT 文の結果を基準に、行ごとの変化を検知して履歴テーブルを更新します。更新検知が発生すると既存の現行行の有効終了を閉じ、新しい現行行を追加します。結果として、同じ unique_key の行に複数バージョンが蓄積されます。

Snapshot テーブルには、dbt が付与する制御カラムが含まれます。これらは戦略に関わらず共通で、履歴の整合性検証や期間クエリに利用できます。

• 必須: unique_key、strategy（timestamp または check）
• 共通の制御カラム: dbt_scd_id, dbt_valid_from, dbt_valid_to, dbt_updated_at
• invalidate_hard_deletes: true でソースから消えた行も失効させられる（ハードデリートの無効化）
• Snapshot はモデルではなく snapshot ブロックとして定義し、dbt snapshot コマンドで更新

最小構成の Snapshot（check 戦略）

{% snapshot customers_snapshot %}
{{
  config(
    target_schema='snapshots',
    unique_key='customer_id',
    strategy='check',
    check_cols=['email', 'address', 'status'],
    invalidate_hard_deletes=true
  )
}}
select customer_id, email, address, status
from {{ source('app', 'customers') }}
{% endsnapshot %}

timestamp vs check 戦略の比較

timestamp 戦略は、単一の更新時刻カラム updated_at を基準に行の変化を検知します。updated_at が単調に増加し、全ての変更時に正しく更新されるデータセットに最適です。

check 戦略は、指定したカラム集合の値変化で検知します。更新時刻が信用できない場合や、ビジネス上の重要属性だけで変更判定したい場合に有効です。

• updated_at を正しく持つなら timestamp が単純で高速になりやすい
• 更新時刻が不信・欠損・遅延するなら check で業務上重要な列のみ監視
• check では非決定的・高変動な列（更新日時そのもの、乱数、浮動小数の微小誤差）は除外

Snapshot の履歴化イメージ（SCD2）

両戦略のスケルトン

{% snapshot orders_ts %}
{{
  config(
    target_schema='snapshots',
    unique_key='order_id',
    strategy='timestamp',
    updated_at='updated_at'
  )
}}
select order_id, updated_at, amount, status
from {{ ref('stg_orders') }}
{% endsnapshot %}

{% snapshot users_ck %}
{{
  config(
    target_schema='snapshots',
    unique_key='user_id',
    strategy='check',
    check_cols=['email', 'is_active', 'plan']
  )
}}
select user_id, email, is_active, plan
from {{ ref('stg_users') }}
{% endsnapshot %}

timestamp 戦略の実務ポイント

updated_at はソース側で全更新時に必ず書き換わる必要があります。遅延到着やバックフィルで updated_at が過去を指すと、検知漏れの原因になります。信頼できる単調増加の時刻を確保してください。

タイムゾーンの取り扱いは倉庫依存です。ソースと DWH の時刻帯が不一致だとウィンドウ境界がずれます。ETL 側で UTC に正規化するか、Snapshot の SELECT 内で明示的に正規化しましょう。

• バックフィル時は updated_at を本来の更新時ではなくロード時刻へ上書きしないこと
• 日次ロールアップに合わせて時刻を丸めると変化が潰れる可能性あり
• ハードデリートへの対応は invalidate_hard_deletes=true を検討

SELECT 内での時刻正規化例（概念）

{% snapshot payments_ts %}
{{
  config(
    target_schema='snapshots',
    unique_key='payment_id',
    strategy='timestamp',
    updated_at='updated_at_utc'
  )
}}
select
  payment_id,
  -- ここで UTC に正規化（倉庫に応じて適切な関数を使用）
  cast(updated_at as timestamp) as updated_at_utc,
  amount, status
from {{ ref('stg_payments_raw') }}
{% endsnapshot %}

check 戦略の実務ポイント

check_cols は業務的に意味のある変更を反映する列に限定します。ログ由来の更新時刻や並び順、非決定的関数の結果は除外してください。浮動小数は丸め誤差で不要な変更検知の原因になりやすいので、比較前に丸めるか文字列化するなどの前処理が有効です。

派生列をチェックしたい場合は、Snapshot の SELECT で安定的に計算してから check_cols に含めます。これによりソーススキーマの変更影響を最小化できます。

• check_cols には NULL セーフな比較が必要になる場合があるため、SELECT で coalesce を活用
• 大量カラムを比較するほどコスト増。必要最小限に絞る
• 金額の丸めはビジネスルールに合わせて統一（例：2桁小数で固定）

check_cols を前処理して安定化する例

{% snapshot subscription_ck %}
{{
  config(
    target_schema='snapshots',
    unique_key='account_id',
    strategy='check',
    check_cols=['plan', 'is_active', 'mrr_str']
  )
}}
with src as (
  select account_id, plan, is_active, mrr
  from {{ ref('stg_subscription') }}
)
select
  account_id,
  plan,
  is_active,
  -- 丸めと型統一により比較を安定化
  cast(round(mrr, 2) as string) as mrr_str
from src
{% endsnapshot %}

運用とパフォーマンス：スケジュール、肥大化対策

Snapshot は実行のたびに差分を評価します。データ更新頻度に合わせたスケジュールが重要で、過剰な頻度は不要な比較コストを招きます。逆に低すぎると検知タイムラグが伸びます。

履歴テーブルは時間とともに増大します。クエリ対象が現行行のみなら、dbt_valid_to が NULL の行を参照するビューを用意し、パーティションやクラスタリングで読み取りを最適化します。

• スケジュールはソース更新直後に寄せると無駄が減る
• 大規模テーブルはパーティション・クラスタリングキーに dbt_valid_from など時系列列を活用
• ハードデリート検知が必要なら invalidate_hard_deletes=true を有効化
• スナップショット専用スキーマ target_schema を分離し権限・ライフサイクルを管理

現行行のみを返すビュー例

create or replace view analytics.v_customers_current as
select *
from snapshots.customers_snapshot
where dbt_valid_to is null;

試験対策の要点：出題されやすいひっかけ

Analytics Engineer 試験では、timestamp と check の適用条件、unique_key の必須性、ハードデリートの扱い、比較対象列の選定などが頻出です。演算子や倉庫固有関数の知識よりも、意味的に正しい差分定義と安定した比較の考え方が問われます。

Snapshot は増分モデルとは目的が異なります。増分は最新状態を効率更新する手段、Snapshot は履歴を保持する手段です。この違いを混同しないでください。

• unique_key は必須。これが不安定だと履歴が壊れる
• timestamp は updated_at 依存。check は業務列依存
• invalidate_hard_deletes でソースから消えた行の失効が可能
• 非決定的列や微小差を check に含めない

schema.yml でのテスト例（unique と not_null）

version: 2
snapshots:
  - name: customers_snapshot
    tests:
      - not_null:
          column_name: customer_id
      - unique:
          column_name: customer_id

問題で確認

よくある質問