dbt Materializations の概要: view / table / incremental / ephemeral を実務と試験で使い分ける

dbt の materialization は、モデルを「どのようなデータベースオブジェクトとして、どのタイミングで更新するか」を決める仕組みです。選び方を誤ると、コスト・レイテンシ・可用性に直結します。

この記事では view / table / incremental / ephemeral の違いと適切な使い分けを、実務の現場感と Analytics Engineer 試験の観点の両方から整理します。

dbt materialization の基本と選び方

dbt はモデルごとに materialized の種類を切り替えられます。最終的に作られる（または作られない）DBオブジェクトの種類、更新の粒度、権限・コスト特性が変わります。まずは4種類の性質を俯瞰し、要件（再計算コスト、レイテンシ、下流依存、権限）に合わせて選びます。

大雑把な指針として、軽い探索や中間段階は view / ephemeral、安定した提供テーブルは table、継続的に差分更新するファクトや巨大テーブルは incremental が適します。ただし、パーティションやクラスタ、サポートされる戦略（merge / append / insert_overwrite）はアダプタ依存なので、使用するデータプラットフォームのサポート範囲を確認してください（dbt docs と各アダプタのドキュメントが一次情報）。

• 小さく頻繁に参照、再計算の重さが軽い → view
• 確定版を安定配布、スナップショット的に使う → table
• 巨大で全再計算が高コスト、キーやタイムスタンプで差分適用 → incremental
• 短命な中間整形、DBオブジェクトを増やしたくない → ephemeral

4種類の materialization と依存関係（概念図）

プロジェクト既定とモデル単位の切り替え例

# dbt_project.yml（抜粋）
models:
  my_project:
    +materialized: view    # プロジェクト既定を view に
    marts:
      +materialized: table # サブパスは table で上書き

# models/stg_orders.sql（個別上書き）
{{ config(materialized='ephemeral') }}
select ...

# models/fct_orders.sql
{{ config(materialized='incremental', unique_key='order_id', incremental_strategy='merge') }}
select ... -- is_incremental() で差分を絞り込むのが定石

view: 軽量・柔軟、参照時に計算される

view は CREATE VIEW により論理的なビューを作成します。ストレージを消費せず、参照時に元テーブルへクエリが流れます。開発初期や小規模な中間集計に向きます。

注意点として、重い集計を多段で view に重ねると、下流クエリのたびに上流が再計算され遅くなります。配布用に安定した性能を求める場合は table 化を検討します。アダプタによっては late binding view（依存関係解決を遅延）などのオプションがあり、スキーマ進化時のエラー耐性に差が出ます。必要に応じてアダプタのドキュメントでサポートを確認しましょう。

• 探索フェーズ、データ量が小さい中間段階に最適
• 権限は参照先にも影響。ビューだけ許可しても元テーブルの参照権限が必要な場合がある
• 下流の安定性能が必要なら table へ昇格させる

view モデルの最小構成

{{ config(materialized='view') }}
select
  o.id,
  o.created_at,
  c.country
from {{ ref('raw_orders') }} as o
left join {{ ref('dim_customers') }} as c on o.customer_id = c.id

table: 再作成で安定配布、読み取りが速い

table は dbt 実行時に CREATE TABLE AS SELECT で作成し、モデルの再実行で再作成（既定）されます。読み取り性能と下流の安定性を優先する用途に向きます。

全再作成のコストが無視できない場合は incremental への移行を検討します。パーティション/クラスタの指定はアダプタ依存です（BigQuery の partition_by/cluster_by、Snowflake のクラスタリングキーなど）。指定できる場合は読み取り・再作成コストのバランスを最適化できます。

• 定期配布・BI 参照の安定性能を重視する最終テーブルに適合
• 再作成はシンプルだがコスト/実行時間がかかる点に留意
• 大容量・高頻度更新なら incremental を検討

table モデル（クラスタ指定はアダプタ依存）

{{ config(materialized='table') }}
select * from {{ ref('int_orders_enriched') }}

incremental: 差分のみ反映する戦略と設計の勘所

incremental は初回はテーブルを作成し、以降は差分だけを反映します。差分適用の戦略（incremental_strategy）はアダプタにより異なり、典型的に append（追記）、merge（キーで更新/挿入）、insert_overwrite（パーティション単位の置換）などが使えます。merge では unique_key の指定が重要です。

差分対象の絞り込みは is_incremental() マクロで条件分岐し、更新日時（updated_at）やロード境界（watermark）で制御します。全再計算したい場合は dbt run --full-refresh を用います。スキーマ進化（列追加等）が発生する場合、on_schema_change 設定値（ignore, fail, append_new_columns, sync_all_columns 等。アダプタサポート差あり）を必ず確認してください。

• unique_key は merge 戦略で必須。append では不要だが重複管理は別途必要
• is_incremental() 内で updated_at >= 最大処理済み時刻 などの条件を記述
• パーティション/クラスタを併用して I/O を最適化（アダプタ依存）
• --full-refresh で安全に全再構築。運用手順に組み込む

merge 戦略の典型パターン（キー更新あり）

{{ config(
    materialized='incremental',
    unique_key='order_id',
    incremental_strategy='merge'
) }}

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

select * from src

ephemeral: CTE へインライン展開される中間モデル

ephemeral はデータベースにオブジェクトを作らず、依存先のモデル SQL に共通表式（CTE）としてインライン展開されます。中間ステップをファイルとして分離しつつ、DB 内のオブジェクトを増やしたくない場合に有効です。

注意点として、巨大な処理を多数の ephemeral に詰め込むと、単一クエリの長大化や最適化の難しさに繋がります。また、外部ツールから直接参照したり権限付与したりはできません。挙動の確認には dbt compile で生成 SQL を見るのが手早いです。

• 短命なクリーニング・フィルタ・正規化に適合
• 外部参照・権限付与・インデックス設定はできない
• 重い処理はテーブル化 or ビュー化して分散させる

ephemeral モデルと利用側の例

-- models/_int_orders_ephemeral.sql
{{ config(materialized='ephemeral') }}
select *
from {{ ref('stg_orders_raw') }}
where is_valid = true

-- models/fct_orders.sql（利用側にCTEとして展開される）
{{ config(materialized='table') }}
with cleaned as (
  select * from {{ ref('_int_orders_ephemeral') }}
)
select * from cleaned

運用設計と Analytics Engineer 試験の観点

試験では、どの要件にどの materialization が適するか、差分戦略と unique_key、--full-refresh の意味、ephemeral の特性が頻出です。実務では、開発初期は view/ephemeral、安定後に table/incremental へ昇格する流れが安全です。

環境別（開発/本番）で materialization を切り替える場合は、変数や target.name を条件にして config を分岐させます。依存の広がり・再計算コスト・権限モデルを意識して、計画的に昇格/降格を管理します。

• default はプロジェクト/フォルダで設定し、例外をモデルで上書き
• 大規模モデルは最初から incremental 前提で設計（キー/水位を決める）
• 列追加時の on_schema_change はアダプタのサポート差を確認
• 実行コマンド: dbt run, dbt run --full-refresh, セレクタで部分実行（dbt run -s tag:incremental など）

環境で materialization を切り替える例

{{ config(
    materialized= (target.name == 'prod') and 'incremental' or 'view',
    unique_key= (target.name == 'prod') and 'id' or none
) }}
select * from {{ ref('stg_items') }}

問題で確認

よくある質問