dbt の delete+insert 戦略を使った再構築アプローチ

delete+insert は、対象テーブルから該当キーの行を一旦削除し、新しい行を挿入して整合性を保つ増分戦略です。MERGE が最適でない、またはサポートが限定的な環境で堅実に動作します。

本記事では、公式ドキュメントの前提に沿い（dbt docs: Incremental models と各アダプタの戦略）、バージョン差異に依存しにくいベーシックな設計・運用パターンに絞って、実務と試験（Analytics Engineer）双方で役立つ視点を提供します。

delete+insert 戦略の要点と再構築の考え方

delete+insert は、ユニークキーで対象行を特定し、古い行を削除して新しい行を挿入することで、結果整合性を保つ増分アップサートを実現します。MERGE のような単一文でのアップサートが使えない、あるいは運用上の理由で避けたい場合に有効です。

再構築アプローチとしては、対象キー範囲を明示しつつ部分的に作り直す、あるいは問題発生時に該当キーの削除と再投入で巻き戻しやすい、という利点があります。トランザクション分離やロックの特性はアダプタ依存のため、ジョブ並列度とテーブル設計（クラスタリング、パーティション）を合わせて検討します。

• 前提: materialized=incremental、unique_key の指定が基本
• データの差分抽出は is_incremental() で制御
• 失敗時のリカバリ: 同一キーを再削除→再挿入で可逆性が高い
• 適用例: Redshift の歴史的実装、Merge 制約のある環境、分割再構築を重視するパイプライン

delete+insert の処理フロー（再構築志向）

最小構成の dbt 増分モデル（delete+insert）

with source as (
  select * from {{ ref('stg_orders') }}
  {% if is_incremental() %}
    where updated_at >= (select coalesce(max(updated_at), '1900-01-01') from {{ this }})
  {% endif %}
),

new_rows as (
  select
    order_id as id,
    customer_id,
    status,
    updated_at
  from source
)

select * from new_rows

-- model config (at top of file, or via config block)
-- {{ config(
--   materialized='incremental',
--   incremental_strategy='delete+insert',
--   unique_key='id'
-- ) }}

要求事項と前提条件：unique_key と差分制御

delete+insert は unique_key がないと成立しません。キーの重複は削除対象の不確定性を生み、誤削除や重複挿入の温床になります。キーは論理一意（複合可）で、ターゲットでもインデックスやクラスタリングの観点から実体化しておくのが実務的です。

差分抽出は is_incremental() で制御します。updated_at やロード境界列で範囲を絞り、delete 範囲と一致するキー集合を生成します。タイムスタンプの遅延着地（late arriving）を考慮し、やや広めのウィンドウを取るか、再実行ポリシーを明確化します。

• unique_key は単一・複合いずれも可、NULL 禁止設計が望ましい
• 差分条件は更新日時、増分フラグ、ハッシュ変化検出などが現実的
• 検証用のユニークテストと非NULLテストを dbt tests で併用
• ターゲット側のキー検索を速くするためのクラスタ/ソート/インデックス設計

差分抽出とキー集合の対応

複合キーとウィンドウ付与の例

{{ config(
  materialized='incremental',
  incremental_strategy='delete+insert',
  unique_key=['id','effective_date']
) }}

with src as (
  select * from {{ ref('stg_line_items') }}
  {% if is_incremental() %}
    where updated_at >= dateadd(day, -1, (select coalesce(max(updated_at),'1900-01-01') from {{ this }}))
  {% endif %}
)
select id, effective_date, qty, price, updated_at from src

実装パターン：モデル定義と構成の切り分け

コンフィグはモデルファイル先頭の config ブロック、または dbt_project.yml の models セクションで管理します。環境差（本番・検証）で戦略を切り替える場合は、vars や target.name を条件に分けると管理が楽です。

一部アダプタでは MERGE がデフォルト化される場合がありますが、delete+insert を明示すれば当該戦略が用いられます。サポート可否や既定挙動はアダプタの公式ドキュメントで確認してください。

• モデル内で戦略・キーを明示し、テストで一貫性を担保
• 環境別で incremental_strategy を変えると検証しやすい
• dbt run-operation でメンテ用スクリプトを補助的に活用

環境別の戦略切替イメージ

dbt_project.yml での既定戦略と上書き

models:
  project_name:
    +materialized: incremental
    +incremental_strategy: delete+insert
    +unique_key: id
    marts:
      orders:
        +incremental_strategy: delete+insert  # explicit
        +unique_key: [id, effective_date]

パフォーマンスと運用上の落とし穴

delete+insert は I/O が増えがちです。削除対象の探索を速くするため、ターゲットテーブルのクラスタリング（Snowflake）、クラスタ/ソートキー（Redshift）、クラスタリング/パーティショニング（BigQuery）、Z-ORDER やクラスター化（Databricks Delta）など、プラットフォーム固有の最適化を組み合わせます。

バルク DELETE のロック影響やタイムトラベル/保持期間のストレージ増分にも注意します。スケジュールをずらして同一キー範囲の併走を避ける、ジョブ単位でキー範囲をシャーディングするなど、運用での工夫が効きます。

• キー列に基づくクラスタリング・分割で DELETE 範囲のスキャンを縮小
• 挿入は COPY/INSERT バッチ化（アダプタ依存）で効率化
• ジョブ並列は同一キー競合を避ける（悲観/楽観ロック差に留意）
• 保持期間や自動クラスタリングのコスト影響を事前見積もり

キーに沿ったクラスタリングでスキャン最小化

クラスタリング/分割の設計例（概念）

-- Snowflake 例（概念）
-- create or replace table T cluster by (id);
-- BigQuery 例（概念）
-- partition by date(updated_at) cluster by id
-- Databricks Delta 例（概念）
-- optimize T zorder by (id)

検証と再実行：可逆な再構築の進め方

delete+insert は、失敗時に該当キーの再削除→再挿入で回復しやすいのが強みです。モデル間の依存関係（ref）で下流が参照するタイミングを管理し、テスト（unique、not_null、関数的重複排除）をパイプライン終端で走らせて不整合を早期検出します。

フルリフレッシュ（--full-refresh）は全件再構築の最後の手段です。まずは影響キーの特定と部分再実行（--select model_name）で切り戻しを試み、必要に応じて再実行ウィンドウを一時的に広げて整合性を取り戻します。

• 失敗の粒度をキー単位に落とし込み、部分再実行で回復
• 検証テストはユニーク/非NULL/関数的重複で三層に
• 本番は read-consistent に配慮し、切替タイミングを制御
• フルリフレッシュはコスト・ロック時間を事前に見積もる

失敗時の可逆フロー

部分再実行とフルリフレッシュの使い分け

# 影響モデルのみ再実行
# dbt run --select my_incremental_model

# フルリフレッシュ（最終手段）
# dbt run --full-refresh --select my_incremental_model

試験対策：Analytics Engineer で狙われるポイント

試験では、増分戦略ごとの適用条件の理解、unique_key が delete+insert で必須であること、is_incremental() の使い方、--full-refresh の意味、アダプタ差に対する保守的な判断が問われます。

また、MERGE と delete+insert の違い、insert_overwrite の前提（パーティション置換）を比較で整理できているかが重要です。

• delete+insert は unique_key が要、差分抽出とテストで堅牢化
• MERGE は単文アップサートだが、環境依存のため常用は要確認
• insert_overwrite はパーティション単位の再構築で効率的
• 失敗時の再実行シナリオとフルリフレッシュの使い分け

戦略間の学習マップ

試験で頻出の設定スニペット

{{ config(
  materialized='incremental',
  incremental_strategy='delete+insert',
  unique_key='id'
) }}
{% if is_incremental() %}
  -- 差分条件を忘れない
{% endif %}

問題で確認

よくある質問