の materialization は「model の がどう に物理化されるか」を決める設定。`view` `table` `incremental` `ephemeral` の 4 種から選びます。
4 種の挙動と選び方
| 種類 | 毎回の挙動 | ストレージ | クエリ速度 | 向く用途 |
|---|---|---|---|---|
| view | VIEW として作成、参照時に裏の SQL 実行 | ほぼ 0 | 遅い (毎回計算) | staging、軽量変換 |
| table | テーブルを毎回 DROP & CREATE | 高い | 速い | marts、 が直接参照 |
| incremental | 新規/更新分のみ INSERT/MERGE | 高い | 速い + ビルド速い | 大規模イベントログ |
| ephemeral | 下流の CTE として展開、テーブル化なし | 0 | 下流に依存 | 再利用される共通変換 |
1. view ── 軽量でいつでも最新
config で view を指定
SQL
{{ config(materialized='view') }}
SELECT charge_id, customer_id, amount, charged_atFROM {{ source('stripe', 'charges') }}WHERE status = 'succeeded'- 長所: ビルド速い、ストレージ消費なし、常に最新
- 短所: 参照のたびに裏の SELECT 全実行、 ダッシュ向きでない
- 典型用途: staging 全般、軽い rename/cast のみのモデル
2. table ── 速さ最優先
table materialization
SQL
{{ config( materialized='table', cluster_by=['date', 'customer_id'] -- BigQuery のクラスタリング) }}
SELECT DATE(charged_at) AS date, customer_id, SUM(amount) AS daily_revenueFROM {{ ref('stg_stripe__charges') }}GROUP BY 1, 2table の典型問題
毎回フルリビルドするため、ソースが大きいと コスト×時間が跳ねる。100 万行レベルなら問題ないが、1 億行を超え始めたら incremental を検討する。
3. incremental ── 大規模ログの差分更新
incremental の最小例
SQL
{{ config( materialized='incremental', unique_key='event_id', on_schema_change='sync_all_columns') }}
SELECT event_id, user_id, event_type, occurred_atFROM {{ source('events', 'raw') }}
{% if is_incremental() %} -- 初回フルビルド時はこのブロックは無視される WHERE occurred_at > (SELECT MAX(occurred_at) FROM {{ this }}){% endif %}`is_incremental()` は「過去にビルドされていて差分実行中」かを返す Jinja 関数。初回または `--full-refresh` 時は false。incremental の差分更新パターンは EP.11 で深掘り予定。
4. ephemeral ── テーブルにせず CTE 展開
ephemeral model
SQL
-- models/intermediate/int_orders__cleaned.sql{{ config(materialized='ephemeral') }}
SELECT order_id, customer_id, amount, COALESCE(refund_amount, 0) AS refund_amountFROM {{ ref('stg_orders') }}WHERE deleted_at IS NULLephemeral model を `ref()` した は、下流で CTE として展開される。テーブル化されないので ストレージ 0、ただし下流での実行時間が長くなる。複数の下流で同じ計算をする場合は table or view にした方が良い。
判断フロー
decision tree
Text
Q1. 行数は？├─ 〜100万行 → table か view (頻度で決める)├─ 100万〜1億行 → table か incremental└─ 1億行〜 → incremental ほぼ必須
Q2. 直接参照される？├─ BI ダッシュから直接 → table か incremental└─ 他 model からだけ → view (軽い) or ephemeral (再利用)
Q3. 鮮度要件は？├─ 即時最新が必要 → view├─ 1時間遅れOK → incremental (頻繁)└─ 1日遅れOK → table (1日1回 full)デフォルト materialization のプロジェクト設定
dbt_project.yml で配下のデフォルト指定
YAML
# dbt_project.ymlmodels: analytics: staging: +materialized: view # staging はすべて view intermediate: +materialized: ephemeral marts: +materialized: table # marts はすべて table finance: +materialized: incremental # finance だけは incremental次の話
EP.06 では dbt のテスト機能 (4 つの組込み + custom) を扱います。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。