dbt の性能チューニング: 実行時間短縮のコツ

dbt の実行時間は DAG のクリティカルパス、マテリアライゼーション選択、増分戦略、セレクション、並列度、そして DWH 固有の最適化に強く依存します。闇雲な最適化より、因数分解して対処するのが近道です。

本稿は dbt 公式ドキュメントの安定機能を前提に、試験で問われやすい原則と現場で効く設定の両方を詰め込みました。まずはボトルネックの見える化、その後にマテリアライゼーションとセレクションで作業量を削り、最後に並列度と DWH 機能で底上げします。

実行計画の全体像とボトルネック特定

最適化の前に、どこに時間がかかっているかをデータで把握します。dbt は run_results.json と manifest.json を出力し、各ノードの開始・終了時刻、依存関係を確認できます。クリティカルパス上の重いノードを短縮すると、全体の壁時計時間が最も縮みます。

DAG の形状を意識しましょう。扇形のうち細長い系列がクリティカルパスになりやすく、そこにある巨大な結合・ソート・再集計が主犯です。まずは対象を絞ってから素材（マテリアライゼーション）を替えます。

• run_results.json で各モデルの実行秒数とステータスを確認
• クリティカルパスを優先最適化。扇状の枝の最長系列を短縮
• 不要な再計算を除去。上流での過剰集計や無駄な DISTINCT を削減
• ステージング層は軽量化。選択列の最小化と早期フィルタでデータ量削減

DAG とクリティカルパスのイメージ

 [src] ----> stg_orders ----> dim_customer ----> fct_sales ----> rpt_sales
    \                     \-> dim_product ----/
     \-> stg_events ---------------------------> fct_engagement

  クリティカルパス: src -> stg_orders -> dim_customer -> fct_sales -> rpt_sales

run_results.json から上位ボトルネックを抽出（例）

jq -r '.results[] | {node: .unique_id, time: (.execution_time|tonumber)} | select(.time!=null) | [.time, .node] | @tsv' target/run_results.json \
  | sort -nr \
  | head -n 10

マテリアライゼーション選択と増分モデルの使い分け

最も効くレバーはマテリアライゼーションです。全再計算が発生する view と table の選択、そして初回以降の作業量を削れる incremental の適用可否が実行時間を大きく左右します。増分は unique_key と戦略の整合が前提です（MERGE、DELETE+INSERT、INSERT_OVERWRITE などはアダプタ依存）。

巨大なファクトは incremental、広く参照されるディメンションは table、小規模で頻繁に変わる整形は view か ephemeral が基本線。試験でもこの原則が問われます。

• 増分適用条件を明確化（append-only か、更新ありか、再計算境界はどこか）
• unique_key と is_incremental 条件の整合。重複・欠損で MERGE が失敗しない設計
• 依存する上流が増分でないと効果半減。上流から一貫して増分化
• 小さな参照テーブルは ephemeral で中間書き込みを省く（同一ランに限る）

増分モデルの安全なパターン（アダプタ別戦略の振り分け例）

{{
  config(
    materialized='incremental',
    unique_key='order_id',
    tags=['fact','critical'],
    **(
      {'incremental_strategy': 'merge'} if target.adapter in ['snowflake','databricks','spark'] else {}
    )
  )
}}

with src as (
  select * from {{ ref('stg_orders') }}
  {% if is_incremental() %}
    where _ingested_at >= dateadd(day, -2, current_timestamp)
  {% endif %}
)

select
  order_id,
  customer_id,
  order_date,
  total_amount
from src

セレクションと状態管理で最小実行に絞る

毎回フル DAG を回すのは避け、変更波及の最小範囲だけを選択します。selectors.yml に基準を定義し、state:modified と親子のプラス指定を組み合わせるのが定番です。--defer と --state を併用すると、本番アーティファクトに依存しながら差分だけを開発環境でビルドできます。

dbt build はモデル・シード・スナップショット・テストを一括実行します。短縮が目的なら、変更時のみテストを実行する、重いデータテストは夜間ジョブに回す、などの運用分離が有効です。

• state:modified+ で変更とその下流のみを対象化
• --defer --state で本番モデルを参照しつつ差分ビルド
• 重いデータ品質テストはバッチに分離し、開発ループを短縮
• セレクタで重要タグ（critical）を優先実行

selectors.yml と CLI 例

# selectors.yml
selectors:
  - name: modified_and_downstream
    definition:
      union:
        - method: state
          value: modified
          children: true
        - method: tag
          value: critical

# 差分のみビルド（本番をデファー）
dbt build --select selector:modified_and_downstream --defer --state target

# 開発ループをさらに短縮（テスト除外）
dbt build --select selector:modified_and_downstream --exclude resource_type:test --defer --state target

並列度とジョブ構成の最適化

threads は高ければ速いとは限りません。DWH の同時実行枠・I/O 帯域・ロック競合で頭打ちになります。まずは中程度の並列度から計測し、クリティカルパスを分割できるよう DAG の層を意識します。

中間テーブルの書き込みがボトルネックなら ephemeral に置き換え、書き込みを削減します。逆に重いサブクエリが複数下流で再利用されるなら table 化して再計算を避けます。

• threads は段階的にチューニング（例: 4 → 8 → 16）
• I/O 競合の激しいモデルは並列実行から外す（タグで制御）
• ephemeral で書き込み削減、共有が多い論理は table 化
• 長時間モデルは専用ジョブで先行実行し、後続を並列化

profiles.yml とモデルごとの並列制御例

# profiles.yml（例）
my_project:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: ...
      user: ...
      password: ...
      role: ...
      warehouse: XSMALL
      database: ...
      schema: ...
      threads: 8

-- タグで重いモデルを別ジョブに
# dbt Cloud では Step1: tag:heavy、Step2: tag:not heavy などに分割
# ローカル例
dbt run --select tag:heavy && dbt run --select tag:light

DWH 固有の最適化を安全に取り込む

DWH の機能は計測しながら慎重に使います。Snowflake ならマイクロパーティションの自動クラスタを前提に、必要な場合のみクラスタリングキーを設定。結果キャッシュとウェアハウスサイズのバランスも重要です。Databricks なら Delta Lake の OPTIMIZE や Z-ORDER をポストフックで実行してスキャン量を削減できます。

いずれも効果はデータ分布とクエリパターン次第です。全テーブルに機械的に適用せず、対象列の選定と実測で判断します。

• Snowflake: 結果キャッシュの活用。再実行が多い開発時は効果大
• Snowflake: クラスタリングキーは更新パターンとフィルタ列に限定
• Databricks: OPTIMIZE や Z-ORDER は読み取り主体の大テーブルに
• ポストフックはタグやサイズ条件で限定実行し、過剰コストを回避

ポストフックで DWH 最適化（条件付き）

{{
  config(
    materialized='table',
    tags=['large','read_heavy'],
    post_hook=(
      [
        "OPTIMIZE {{ this }} ZORDER BY (order_date)",
      ] if target.adapter == 'databricks' else []
    )
  )
}}
select * from {{ ref('fct_sales') }}

テストと CI を軽量化して反復を速くする

品質は落とさず、実行回数と重さを最適化します。重いデータテストは夜間、開発ループではスキーマテスト中心に。state:modified に紐づくモデルだけテストを走らせ、全体回帰は日次に分離します。

スナップショットやシードのフルリロードも高コストです。頻度を最小化し、必要なときだけ --full-refresh を使います。

• 開発時: 変更モデルの generic テストのみ実行
• 回帰時: 全テストとドキュメント生成をまとめて夜間実行
• シードは差分ロード方針を検討（サイズと更新頻度次第）
• --full-refresh は計画的に。誤用防止に専用ジョブを用意

テスト選択の例と誤爆防止

# 変更分のみテスト（generic のみ）
dbt test --select state:modified+ test_type:generic --defer --state target

# フルリフレッシュは専用ジョブに限定
dbt build --full-refresh --select tag:allow_full_refresh

問題で確認

よくある質問