dbt snapshots のカスタムスキーママクロの設定変更を試してみた

2026.01.14
 はじめにdbt の snapshots 利用時に snapshots のテーブルの作成先を制御したい場面があったので、基本的な動作確認と合わせて、試した内容を記事としました。
 前提条件以下の環境で検証しています。
dbt platform（旧 dbt Cloud） を使用
DWH：Snowflake
 dbt snapshotsdbt における snapshots は Slowly Changing Dimensions Type2 を用いたテーブルの変更履歴の保持を実装できる機能です。

現在はその設定を YAML 形式で定義でき、カスタムスキーマやデータベースの設定も可能です。本機能については、以下の記事が参考になります。
https://dev.classmethod.jp/articles/dbt-try-snapshot/
https://dev.classmethod.jp/articles/dbt-snapshots-with-yaml/
 事前準備 Snowflake 側Snowflake 側で以下のように環境を用意します。
環境分離：データベースレベル
prd_db
dev_db

それぞれ環境DBの RAW スキーマにスナップショットの元となるテーブルを作成します。検証で使用するウェアハウスやロールとあわせて以下の内容で作成しました。
USE ROLE SYSADMIN;

-- 変数の設定:dev または prd
SET env_name = 'dev'; # 開発環境
-- SET env_name = 'prd'; # 本番環境
SET db_name = concat($env_name,'_db');
SET schema_name = concat($db_name,'.raw');
SET wh_name = concat($env_name,'_dbt_whs');
SET role_name = concat($env_name,'_dbt_role');

-- warehouses作成
CREATE WAREHOUSE IF NOT EXISTS identifier($wh_name)
  WITH
    WAREHOUSE_SIZE = XSMALL
    AUTO_SUSPEND = 60
    AUTO_RESUME = TRUE
    INITIALLY_SUSPENDED = TRUE;

-- 基本データベースとスキーマ作成
CREATE DATABASE identifier($db_name);
CREATE SCHEMA identifier($schema_name);  -- rawデータ用スキーマ

-- テーブル作成とデータロード
USE SCHEMA identifier($schema_name);

CREATE OR REPLACE TABLE RAW.CUSTOMERS_SRC (
  CUSTOMER_ID   VARCHAR(50)   NOT NULL,
  FULL_NAME     VARCHAR(200),
  EMAIL         VARCHAR(200),
  STATUS        VARCHAR(50),          
  PLAN          VARCHAR(50),          
  ADDRESS       VARCHAR(300),
  UPDATED_AT    TIMESTAMP_NTZ(9) NOT NULL,
  LOAD_TS       TIMESTAMP_NTZ(9) DEFAULT CURRENT_TIMESTAMP()
);

INSERT INTO RAW.CUSTOMERS_SRC (CUSTOMER_ID, FULL_NAME, EMAIL, STATUS, PLAN, ADDRESS, UPDATED_AT)
VALUES
  ('C001', 'Taro Yamada', 'taro@example.com', 'active',  'free',       'Tokyo, JP',        '2026-01-10 09:00:00'),
  ('C002', 'Hanako Sato', 'hanako@example.com', 'active','pro',        'Osaka, JP',        '2026-01-10 09:00:00'),
  ('C003', 'John Smith',  'john@example.com', 'paused', 'pro',        'CA, US',           '2026-01-10 09:00:00'),
  ('C004', 'Alice Chen',  'alice@example.com','active', 'enterprise', 'NY, US',           '2026-01-10 09:00:00');

-- 権限付与
-- ロール作成
USE ROLE SECURITYADMIN;
CREATE ROLE identifier($role_name);
GRANT ROLE identifier($role_name) TO ROLE SYSADMIN;

-- 権限付与:warehouse
GRANT USAGE,OPERATE ON WAREHOUSE identifier($wh_name) TO ROLE identifier($role_name);

-- 権限付与:rawデータへの読み取り
GRANT USAGE ON DATABASE identifier($db_name) TO ROLE identifier($role_name);
GRANT USAGE ON SCHEMA identifier($schema_name) TO ROLE identifier($role_name);

GRANT SELECT ON ALL TABLES IN SCHEMA identifier($schema_name) TO ROLE identifier($role_name);
GRANT SELECT ON FUTURE TABLES IN SCHEMA identifier($schema_name) TO ROLE identifier($role_name);

GRANT SELECT ON ALL VIEWS IN SCHEMA identifier($schema_name) TO ROLE identifier($role_name);
GRANT SELECT ON FUTURE VIEWS IN SCHEMA identifier($schema_name) TO ROLE identifier($role_name);

-- 権限付与:スキーマの作成権限
GRANT CREATE SCHEMA ON DATABASE identifier($db_name) TO ROLE identifier($role_name);
 dbt platform 側検証用プロジェクトとコネクションを作成し、対象の Snowflake アカウントとの接続設定を行います。スナップショットの元テーブルは、先の手順でに Snowflake 側に作成済みなので、このテーブルを参照する Source 定義ファイルを以下のように作成しました。
models\sources.yml
version: 2

sources:
  - name: raw
    database: "{{ env_var('DBT_DATABASE') }}"
    schema: raw
    tables:
      - name: customers_src
データベースは環境変数で参照するため、プロジェクトの環境設定（「Orchestration > Environments」）より環境変数を設定しておきます。
本番環境への適用はジョブを経由して行うので、本番環境の作成と本番環境へのデプロイジョブも作成しておきます。開発環境の設定とあわせて、それぞれ以下のような設定です。
開発環境
target.name：dev
（デフォルト）スキーマ：dbt_<ユーザー名>

本番環境
target.name：prd
（デフォルト）スキーマ：prd

 Snapshots の作成Source として定義したテーブルを参照する snapshot を作成します。こちらの設定については以下に記載があります。
https://docs.getdbt.com/docs/build/snapshots
ここでは以下のようにオプションを指定しました
models/customer_src_snapshot.yml
snapshots:
  - name: customer_src_snapshot
    relation: source('raw', 'customers_src')
    config:
      database: "{{ env_var('DBT_DATABASE') }}" # 環境ごとに指定のデータベースを出力先とする
      schema: snapshots # カスタムスキーマを指定
      strategy: timestamp
      unique_key: customer_id
      updated_at: updated_at
      dbt_valid_to_current: "to_timestamp_ntz('9999-12-31 00:00:00')"
      hard_deletes: new_record
主なオプションの概要は以下の通りです。
unique_key：必須。レコードの主キー列
strategy
変更検知の方式。以下のいずれかを指定する
timestamp（推奨）：更新日時カラムで変更検知
check：指定カラムの値比較で変更検知


strategy 別の主要オプション
strategy: timestampの場合
updated_at：変更検知に使う更新日時カラム名。これが前回より新しければ更新とみなして履歴行が作成される

strategy: checkの場合
check_cols：変更検知対象の列リスト。指定した列のいずれかが変わったら履歴行を作成
check_cols: allとし全列比較もできる

その他のオプション：
dbt_valid_to_current
現行レコードの [dbt_valid_to] を NULL ではなく任意の値で埋めるための設定。未来日を設定しておくことで、以下のようなクエリを記述しやすくできる
-- 任意の時点 ts に有効なレコードをフィルタ
where ts >= dbt_valid_from and ts < dbt_valid_to
hard_deletes
前回あった unique_key の行が、ソースから消え際に snapshot に削除履歴を残すかどうかを制御
ignore（デフォルト）
削除された行を追跡しない（[dbt_valid_to]が埋まらない）

invalidate
削除された行を無効化扱いとし、[dbt_valid_to]を現在時刻で埋める

new_record
削除されたという事象を新しいレコードとして追加して追跡する
dbt_is_deleted 列が付与され、削除時は true、対象のレコードが復活したら false の行が追加される

 各環境で実行上記の設定で、各環境でdbt snapshotコマンドを実行しスナップショットテーブルを作成します。
実行後、Snowflake 側を確認すると、それぞれ以下のデータベース・スキーマにテーブルが作成されます。
開発環境：DEV_DB.DBT_TYASUHARA_SNAPSHOTS
本番環境：PRD_DB.PRD_SNAPSHOTS
特にスキーマについて、明示的に設定を変更していない場合、スナップショットテーブルはこちらで説明されているようにデフォルトのgenerate_schema_nameマクロの挙動に従い宛先に作成されます。
ここまでの設定では、customer_src_snapshot.ymlでschemaオプションを指定しています。

この場合、schemaオプションの指定はつまり「カスタムスキーマ」を指定していることとなるため、generate_schema_name マクロの{{ default_schema }}_{{ custom_schema_name | trim }}のロジックが適用されます。
これまでの手順で以下のような設定となっているため、各環境で上記のデータベース・スキーマにスナップショットテーブルが作成されました。
開発環境
（デフォルト）スキーマ：dbt_<ユーザー名>
カスタムスキーマ：snapshots（customer_src_snapshot.ymlでschemaオプション）

本番環境
（デフォルト）スキーマ：prd
カスタムスキーマ：snapshots（customer_src_snapshot.ymlでschemaオプション）

 カスタムスキーマ マクロを変更デフォルトの generate_schema_name マクロの挙動から変更し、指定のスキーマにモデル等を作成したい場合、この設定を上書きできます。こちらについては、以下の記事が参考になります。
https://dev.classmethod.jp/articles/dbt-rewriting-the-generate-schema-name-macro/
プロジェクトの ./macros/ フォルダ内にget_custom_schema.sqlというファイルを作成し（このファイル名は任意の名称で可）、以下のようなgenerate_schema_nameマクロを上書きする内容としました。

ポイントとして、スナップショットテーブルのみを明示的に制御したい場合はnode.resource_type == 'snapshot'で制御できます。
macros/get_custom_schema.sql
{% macro generate_schema_name(custom_schema_name, node) %}

  {% set default_schema = target.schema %}

  {# 開発環境：snapshotは default_schema + '_' + custom_schema（無ければ default_schema_snapshot） #}
  {% if target.name != 'prd' and node.resource_type == 'snapshot' %}
    {% if custom_schema_name is not none %}
      {{ default_schema }}_{{ custom_schema_name | trim }}
    {% else %}
      {{ default_schema }}_snapshots
    {% endif %}

  {# 本番：custom_schema があればその値を使用。なければ default_schema #}
  {% elif target.name == 'prd' and custom_schema_name is not none %}
    {{ custom_schema_name | trim }}

  {% else %}
    {{ default_schema }}
  {% endif %}

{% endmacro %}
先の手順で Snowflake 側に作成されたスキーマ等を一度削除し、マクロを追加後、再度dbt snapshotを実行します。この場合、上書きした内容に基づき各環境で以下のようにスナップショットテーブルが作成されます。
開発環境：先と同じロジックが適用され{{ default_schema }}_{{ custom_schema_name | trim }}に作成されます
本番環境：指定のカスタムスキーマ（snapshots）作成されます
参考までに、これまでの設定でカスタムスキーマを指定しないスナップショットテーブルを定義してみます。
models\new_customer_src_snapshot.yml
snapshots:
  - name: new_customer_src_snapshot
    relation: source('raw', 'customers_src')
    config:
      database: "{{ env_var('DBT_DATABASE') }}"
      strategy: timestamp
      unique_key: customer_id
      updated_at: updated_at
      dbt_valid_to_current: "to_timestamp_ntz('9999-12-31 00:00:00')"
      hard_deletes: new_record
この場合、開発環境では{{ default_schema }}_snapshots が適用され、変わらず同じスキーマにテーブルが作成されます。
一方で本番環境では、デフォルトスキーマにテーブルが作成されます。
 スナップショットテーブルの基本操作を確認意図したデータベース・スキーマにスナップショットテーブルを作成できたので、基本的な動作を確認します。
初回スナップショットの元テーブルは以下のように作成していました。
>SELECT * FROM RAW.CUSTOMERS_SRC ORDER BY CUSTOMER_ID;
+-------------+-------------+--------------------+--------+------------+-----------+-------------------------+-------------------------+
| CUSTOMER_ID | FULL_NAME   | EMAIL              | STATUS | PLAN       | ADDRESS   | UPDATED_AT              | LOAD_TS                 |
|-------------+-------------+--------------------+--------+------------+-----------+-------------------------+-------------------------|
| C001        | Taro Yamada | taro@example.com   | active | free       | Tokyo, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 |
| C002        | Hanako Sato | hanako@example.com | active | pro        | Osaka, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 |
| C003        | John Smith  | john@example.com   | paused | pro        | CA, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 |
| C004        | Alice Chen  | alice@example.com  | active | enterprise | NY, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 |
+-------------+-------------+--------------------+--------+------------+-----------+-------------------------+-------------------------+
スナップショット テーブルを確認すると以下のようになっています。

特徴として、DBT_から始まるメタデータ列が付与されており、DBT_VALID_TOの値が、dbt_valid_to_currentオプションで指定の値となっています。
>SELECT * FROM SNAPSHOTS.CUSTOMER_SRC_SNAPSHOT ORDER BY CUSTOMER_ID;
+-------------+-------------+--------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------+
| CUSTOMER_ID | FULL_NAME   | EMAIL              | STATUS | PLAN       | ADDRESS   | UPDATED_AT              | LOAD_TS                 | DBT_SCD_ID                       | DBT_UPDATED_AT          | DBT_VALID_FROM          | DBT_VALID_TO            | DBT_IS_DELETED |
|-------------+-------------+--------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------|
| C001        | Taro Yamada | taro@example.com   | active | free       | Tokyo, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | b950b9f3e56fb2642799ebf9c08d5dac | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C002        | Hanako Sato | hanako@example.com | active | pro        | Osaka, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 0c5f4f742122a6254e576a78b107e46e | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C003        | John Smith  | john@example.com   | paused | pro        | CA, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 74f0abc05f8ed0123d5d6f3f9ee1993f | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C004        | Alice Chen  | alice@example.com  | active | enterprise | NY, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 622035ace12e14073daf2beeb7fbe1ae | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 9999-12-31 00:00:00.000 | False          |
+-------------+-------------+--------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------+
 UPDATE元テーブルのレコードを以下の通り更新します。
-- C002 のプラン変更
UPDATE RAW.CUSTOMERS_SRC
SET PLAN = 'enterprise',
    UPDATED_AT = '2026-01-12 10:30:00'
WHERE CUSTOMER_ID = 'C002';

-- C001 のメール変更
UPDATE RAW.CUSTOMERS_SRC
SET EMAIL = 'taro.yamada+new@example.com',
    UPDATED_AT = '2026-01-12 11:00:00'
WHERE CUSTOMER_ID = 'C001';
この状態で、スナップショットを再度作成すると、以下の通りスナップショットテーブルが更新されます。
C001 と C002 は snapshot テーブルに 新しい版の行が追加
以前の版は dbt_valid_to が埋まり、最新版の[dbt_valid_to]は「9999-12-31」となる（dbt_valid_to は UPDATED_AT の値で埋まる）
>SELECT * FROM SNAPSHOTS.CUSTOMER_SRC_SNAPSHOT ORDER BY CUSTOMER_ID;
+-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------+
| CUSTOMER_ID | FULL_NAME   | EMAIL                       | STATUS | PLAN       | ADDRESS   | UPDATED_AT              | LOAD_TS                 | DBT_SCD_ID                       | DBT_UPDATED_AT          | DBT_VALID_FROM          | DBT_VALID_TO            | DBT_IS_DELETED |
|-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------|
| C001        | Taro Yamada | taro@example.com            | active | free       | Tokyo, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | b950b9f3e56fb2642799ebf9c08d5dac | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 2026-01-12 11:00:00.000 | False          |
| C001        | Taro Yamada | taro.yamada+new@example.com | active | free       | Tokyo, JP | 2026-01-12 11:00:00.000 | 2026-01-12 18:43:44.616 | 758f0155771cb2c92ad10cb018384859 | 2026-01-12 11:00:00.000 | 2026-01-12 11:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C002        | Hanako Sato | hanako@example.com          | active | enterprise | Osaka, JP | 2026-01-12 10:30:00.000 | 2026-01-12 18:43:44.616 | 4959292bb5b95875ce969f036ffd9ec9 | 2026-01-12 10:30:00.000 | 2026-01-12 10:30:00.000 | 9999-12-31 00:00:00.000 | False          |
| C002        | Hanako Sato | hanako@example.com          | active | pro        | Osaka, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 0c5f4f742122a6254e576a78b107e46e | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 2026-01-12 10:30:00.000 | False          |
| C003        | John Smith  | john@example.com            | paused | pro        | CA, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 74f0abc05f8ed0123d5d6f3f9ee1993f | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C004        | Alice Chen  | alice@example.com           | active | enterprise | NY, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 622035ace12e14073daf2beeb7fbe1ae | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 9999-12-31 00:00:00.000 | False          |
+-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------+
 INSERT元テーブルに新規のレコードを追加します。
INSERT INTO RAW.CUSTOMERS_SRC (CUSTOMER_ID, FULL_NAME, EMAIL, STATUS, PLAN, ADDRESS, UPDATED_AT)
VALUES
  ('C005', 'Bob Lee', 'bob@example.com', 'active', 'free', 'TX, US', '2026-01-12 13:00:00');
この場合は、新しい履歴 C005 が追加されます。
>SELECT * FROM SNAPSHOTS.CUSTOMER_SRC_SNAPSHOT ORDER BY CUSTOMER_ID;
+-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------+
| CUSTOMER_ID | FULL_NAME   | EMAIL                       | STATUS | PLAN       | ADDRESS   | UPDATED_AT              | LOAD_TS                 | DBT_SCD_ID                       | DBT_UPDATED_AT          | DBT_VALID_FROM          | DBT_VALID_TO            | DBT_IS_DELETED |
|-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------|
| C001        | Taro Yamada | taro.yamada+new@example.com | active | free       | Tokyo, JP | 2026-01-12 11:00:00.000 | 2026-01-12 18:43:44.616 | 758f0155771cb2c92ad10cb018384859 | 2026-01-12 11:00:00.000 | 2026-01-12 11:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C001        | Taro Yamada | taro@example.com            | active | free       | Tokyo, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | b950b9f3e56fb2642799ebf9c08d5dac | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 2026-01-12 11:00:00.000 | False          |
| C002        | Hanako Sato | hanako@example.com          | active | enterprise | Osaka, JP | 2026-01-12 10:30:00.000 | 2026-01-12 18:43:44.616 | 4959292bb5b95875ce969f036ffd9ec9 | 2026-01-12 10:30:00.000 | 2026-01-12 10:30:00.000 | 9999-12-31 00:00:00.000 | False          |
| C002        | Hanako Sato | hanako@example.com          | active | pro        | Osaka, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 0c5f4f742122a6254e576a78b107e46e | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 2026-01-12 10:30:00.000 | False          |
| C003        | John Smith  | john@example.com            | paused | pro        | CA, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 74f0abc05f8ed0123d5d6f3f9ee1993f | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C004        | Alice Chen  | alice@example.com           | active | enterprise | NY, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 622035ace12e14073daf2beeb7fbe1ae | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C005        | Bob Lee     | bob@example.com             | active | free       | TX, US    | 2026-01-12 13:00:00.000 | 2026-01-12 22:56:10.267 | 61a7e4ce6b4c50d6ce733ffef8879717 | 2026-01-12 13:00:00.000 | 2026-01-12 13:00:00.000 | 9999-12-31 00:00:00.000 | False          |
+-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------+
 Hard deleteC003 を元テーブルから削除してみます。
DELETE FROM RAW.CUSTOMERS_SRC
WHERE CUSTOMER_ID = 'C003';
snapshot を実行すると、ここではhard_deletes: new_recordの設定に基づき、以下のようになります。
スナップショットテーブル側で  C003 のレコードが消えるのではなく、削除を表す新しい行（dbt_is_deleted=true）が追加される。また、この行のDBT_VALID_TOの値が現在有効なものを表す「9999-12-31」となっています。
>SELECT * FROM SNAPSHOTS.CUSTOMER_SRC_SNAPSHOT ORDER BY CUSTOMER_ID;
+-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------+
| CUSTOMER_ID | FULL_NAME   | EMAIL                       | STATUS | PLAN       | ADDRESS   | UPDATED_AT              | LOAD_TS                 | DBT_SCD_ID                       | DBT_UPDATED_AT          | DBT_VALID_FROM          | DBT_VALID_TO            | DBT_IS_DELETED |
|-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------|
| C001        | Taro Yamada | taro.yamada+new@example.com | active | free       | Tokyo, JP | 2026-01-12 11:00:00.000 | 2026-01-12 18:43:44.616 | 758f0155771cb2c92ad10cb018384859 | 2026-01-12 11:00:00.000 | 2026-01-12 11:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C001        | Taro Yamada | taro@example.com            | active | free       | Tokyo, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | b950b9f3e56fb2642799ebf9c08d5dac | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 2026-01-12 11:00:00.000 | False          |
| C002        | Hanako Sato | hanako@example.com          | active | enterprise | Osaka, JP | 2026-01-12 10:30:00.000 | 2026-01-12 18:43:44.616 | 4959292bb5b95875ce969f036ffd9ec9 | 2026-01-12 10:30:00.000 | 2026-01-12 10:30:00.000 | 9999-12-31 00:00:00.000 | False          |
| C002        | Hanako Sato | hanako@example.com          | active | pro        | Osaka, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 0c5f4f742122a6254e576a78b107e46e | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 2026-01-12 10:30:00.000 | False          |
| C003        | John Smith  | john@example.com            | paused | pro        | CA, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | c0fefae65dc6e00a2790b7f285259919 | 2026-01-13 06:58:34.726 | 2026-01-13 06:58:34.726 | 9999-12-31 00:00:00.000 | True           |
| C003        | John Smith  | john@example.com            | paused | pro        | CA, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 74f0abc05f8ed0123d5d6f3f9ee1993f | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 2026-01-13 06:58:34.726 | False          |
| C004        | Alice Chen  | alice@example.com           | active | enterprise | NY, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 622035ace12e14073daf2beeb7fbe1ae | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C005        | Bob Lee     | bob@example.com             | active | free       | TX, US    | 2026-01-12 13:00:00.000 | 2026-01-12 22:56:10.267 | 61a7e4ce6b4c50d6ce733ffef8879717 | 2026-01-12 13:00:00.000 | 2026-01-12 13:00:00.000 | 9999-12-31 00:00:00.000 | False          |
+-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------+
削除したキー（ C003 のレコード）を再度インサートしてみます。
INSERT INTO RAW.CUSTOMERS_SRC (CUSTOMER_ID, FULL_NAME, EMAIL, STATUS, PLAN, ADDRESS, UPDATED_AT)
VALUES
  ('C003', 'John Smith', 'john@example.com', 'active', 'pro', 'CA, US', '2026-01-12 15:00:00');
すると、C003 のdbt_is_deleted=falseな行がまた追加され、削除から復活の履歴が追えるようになります。
>SELECT * FROM SNAPSHOTS.CUSTOMER_SRC_SNAPSHOT ORDER BY CUSTOMER_ID;
+-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------+
| CUSTOMER_ID | FULL_NAME   | EMAIL                       | STATUS | PLAN       | ADDRESS   | UPDATED_AT              | LOAD_TS                 | DBT_SCD_ID                       | DBT_UPDATED_AT          | DBT_VALID_FROM          | DBT_VALID_TO            | DBT_IS_DELETED |
|-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------|
| C001        | Taro Yamada | taro.yamada+new@example.com | active | free       | Tokyo, JP | 2026-01-12 11:00:00.000 | 2026-01-12 18:43:44.616 | 758f0155771cb2c92ad10cb018384859 | 2026-01-12 11:00:00.000 | 2026-01-12 11:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C001        | Taro Yamada | taro@example.com            | active | free       | Tokyo, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | b950b9f3e56fb2642799ebf9c08d5dac | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 2026-01-12 11:00:00.000 | False          |
| C002        | Hanako Sato | hanako@example.com          | active | enterprise | Osaka, JP | 2026-01-12 10:30:00.000 | 2026-01-12 18:43:44.616 | 4959292bb5b95875ce969f036ffd9ec9 | 2026-01-12 10:30:00.000 | 2026-01-12 10:30:00.000 | 9999-12-31 00:00:00.000 | False          |
| C002        | Hanako Sato | hanako@example.com          | active | pro        | Osaka, JP | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 0c5f4f742122a6254e576a78b107e46e | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 2026-01-12 10:30:00.000 | False          |
| C003        | John Smith  | john@example.com            | active | pro        | CA, US    | 2026-01-12 15:00:00.000 | 2026-01-12 23:00:09.809 | d7b732ce0f0a50db0ace31b7aeeb5b8b | 2026-01-12 15:00:00.000 | 2026-01-12 15:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C003        | John Smith  | john@example.com            | paused | pro        | CA, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | c0fefae65dc6e00a2790b7f285259919 | 2026-01-13 06:58:34.726 | 2026-01-13 06:58:34.726 | 2026-01-12 15:00:00.000 | True           |
| C003        | John Smith  | john@example.com            | paused | pro        | CA, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 74f0abc05f8ed0123d5d6f3f9ee1993f | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 2026-01-13 06:58:34.726 | False          |
| C004        | Alice Chen  | alice@example.com           | active | enterprise | NY, US    | 2026-01-10 09:00:00.000 | 2026-01-12 18:43:44.616 | 622035ace12e14073daf2beeb7fbe1ae | 2026-01-10 09:00:00.000 | 2026-01-10 09:00:00.000 | 9999-12-31 00:00:00.000 | False          |
| C005        | Bob Lee     | bob@example.com             | active | free       | TX, US    | 2026-01-12 13:00:00.000 | 2026-01-12 22:56:10.267 | 61a7e4ce6b4c50d6ce733ffef8879717 | 2026-01-12 13:00:00.000 | 2026-01-12 13:00:00.000 | 9999-12-31 00:00:00.000 | False          |
+-------------+-------------+-----------------------------+--------+------------+-----------+-------------------------+-------------------------+----------------------------------+-------------------------+-------------------------+-------------------------+----------------+
 さいごにdbt の snapshots 利用時のカスタムスキーマ マクロ関連の設定と基本的な動作を確認してみました。こちらの内容がどなたかの参考になれば幸いです。
dbt snapshots のカスタムスキーママクロの設定変更を試してみた

はじめに

前提条件

dbt snapshots

事前準備

Snowflake 側

dbt platform 側

Snapshots の作成

各環境で実行

カスタムスキーママクロを変更

スナップショットテーブルの基本操作を確認

UPDATE

INSERT

Hard delete

さいごに

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS

はじめに

前提条件

dbt snapshots

事前準備

Snowflake 側

dbt platform 側

Snapshots の作成

各環境で実行

カスタムスキーマ マクロを変更

スナップショットテーブルの基本操作を確認

UPDATE

INSERT

Hard delete

さいごに

関連記事

EVENTS

カスタムスキーママクロを変更
