dbtのマテリアライゼーションを整理したい【株式会社ライトコード】

はじめに

1月よりデータ推進室に配属になりました。
毎日業務でdbtを触っているのですが、マテリアライゼーションについて一度自分の中で整理する意味も含めて今回記事にまとめます。

マテリアライゼーションとは

dbtにおけるマテリアライゼーションとは、dbtモデルの変換結果をデータウェアハウス内にどのように保存するか決める戦略のことです。

どのマテリアライゼーションを選択するかによって、以下の要素に大きく影響します。

• ビルド時間（dbt runの実行にかかる時間）
• クエリ性能（エンドユーザーがデータを取得する速度）
• データの鮮度（データソースの変更がどれだけ早く反映されるか）
• ストレージ/スキャンコスト（BigQueryのオンデマンド料金等）

dbtには、標準で5つのマテリアライゼーションが組み込まれています。

種類

BigQuery上のオブジェクト

データの保存有無

view

ビュー

なし（SQLのみ）

table

テーブル

あり

incremental

テーブル（増分更新）

あり

ephemeral

なし

なし

materialized_view

マテリアライズどビュー

あり

マテリアライゼーションの種類

1. view

データは保存せず、クエリ時に毎回SQLが実行されます。CREATE VIEW ASでビューを再作成します。
また、dbtのデフォルト設定であるため、何も設定しなければ自動的にビューとして作成されます。

• 特徴
• • ビルド時間：一瞬（データの保存ではなく、SQLの保存のみのため）
  • クエリ性能：遅い（クエリの度に変換処理を再実行するため）
  • データ鮮度：常に最新（クエリ時にソースから直接読み取るため）
  • コスト：ストレージは不要だが、クエリごとにスキャンコストが発生する
• メリット:
  追加ストレージが不要であり、常にソースの最新状態を参照できる
• デメリット:
  頻繁にアクセスされるとスキャンコストが増大する
• 最適なユースケース:
  リネーム・キャストなどの軽量な変換や、staging モデルに最適

2. table

変換結果を静的データとして保存します。CREATE TABLE ASでテーブルをフルビルドします。

• 特徴
• • ビルド時間：データ量に比例して増加（毎回全データを再計算するため）
  • クエリ性能：早い（計算済みのデータを返すだけのため）
  • データ鮮度：run時点のデータまで（次のrunまでソースの最新状態は反映されない）
  • コスト：ストレージ費用が発生。ビルド時に全スキャンするが、クエリ時は読み取りのみ
• メリット:
  クエリが常に高速。partition_byやcluster_byと組み合わせることで最適化が可能。
• デメリット:
  データ量が多いとビルドに時間がかかる。ソースの変更がリアルタイムに反映されない。
• 最適なユースケース:
  ダッシュボード向けのmart層モデルや、多くの下流モデルから反復参照される重い変換を持つモデルに適している

3. incremental

初回は全データでテーブルを作成し、2 回目以降はis_incremental()でフィルタされた差分データのみを追加・更新します。
特にデータ量の多いテーブルにおいては、tableよりも大幅なコスト削減が見込めます。

• 特徴
• • ビルド時間：差分の処理のみで劇的に短縮（初回はテーブルと同等）
  • クエリ性能：tableと同等（実態はテーブルであるため）
  • データ鮮度：run時点のデータまで。
  • コスト：ストレージはtableと同等、スキャン対象は差分データのみ
• メリット: 　ビルド時間とスキャンコストが大幅に短縮できる
• デメリット: 　設定がやや複雑になる。条件を誤ると、過去データの変更を取りこぼしたり重複取得するリスクもある
• 最適なユースケース: 　イベントログなどの時系列データ。tableではビルドが遅延する場合の移行先となる

incrementalモデルの具体的な実装方法はこちら

BigQueryで利用可能なIncremental Strategy

• merge
  unique_keyで行を照合し、新規ならばINSERT、既存ならUPDATEを行う（unique_keyの設定が必須）
• insert_overwrite
  行単位の比較は行わず、パーティションを丸ごと上書きする（partition_byの設定が必須）

4. ephemeral

BigQuery 上にオブジェクトを作成せず、参照元モデルの SQL 内に CTE（共通テーブル式） として展開されます。

• 特徴
• • ビルド時間：　なし（BigQuery にオブジェクトを作成しないため）
  • クエリ性能：　展開先のモデルの性能に依存する。
  • データ鮮度：　常に最新（展開先モデルの実行時にソースから読み取られる）
  • コスト：　　　ストレージ不要。スキャンコストは展開先のクエリに含まれる
• メリット: 　BigQuery上のオブジェクトを増やさずにロジックを再利用できる
• デメリット: 　直接SELECTできないためデバッグが困難。多用するとコンパイル後のSQLが巨大化してパフォーマンスに悪影響
• 最適なユースケース: 　1〜2個下流のモデルからのみ参照される軽量な中間ロジック

5. materialized_view

BigQuery のマテリアライズドビュー機能を利用します。ベーステーブルの変更から、デフォルトで5分以内に自動リフレッシュ（最短30分間隔）されます。

• 特徴
• • ビルド時間：　dbt runはコードデプロイのみ（データ更新は BigQuery が自動実行）
  • クエリ性能：　table に近い（データを物理的に保存するため）
  • データ鮮度：　ほぼリアルタイム（BigQueryが自動で増分更新）
  • コスト：　　　ストレージ費用は発生するが、増分更新により全スキャンを回避できる
• メリット: 　dbt のバッチ実行なしでもデータが更新される
• デメリット: 　SQL に制約がある。SQL 変更時は-full-refreshでの再構築が必要となる
• 最適なユースケース: 　incremental で十分要件を満たせるが、リフレッシュ管理を BigQuery に任せたい場合に適している

マテリアライゼーションの設定方法

設定には3つのレベルがあり、優先順位が高い設定が上位の設定をオーバーライドします。

…

記事の続きは下のURLをクリック！

https://rightcode.co.jp/blogs/54665

もっとワクワクしたいあなたへ

現在、ライトコードでは「WEBエンジニア」「モバイルエンジニア」「データエンジニア」「ゲームエンジニア」「デザイナー」「WEBディレクター」「営業」などを積極採用中です！

ライトコードは技術力に定評のある受託開発をメインにしているIT企業です。

有名WEBサービスやアプリの受託開発などの企画、開発案件が目白押しの状況です。

• もっと大きなことに挑戦したい！
• エンジニアとしてもっと成長したい！
• モダンな技術に触れたい！

現状に満足していない方は、まずは、エンジニアとしても第一線を走り続ける弊社代表と気軽にお話してみませんか？

ネット上では、ちょっとユルそうな会社に感じると思いますが（笑）、
実は技術力に定評があり、沢山の実績を残している会社ということをお伝えしたいと思っております。

• ライトコードの魅力を知っていただきたい！
• 社風や文化なども知っていただきたい！
• 技術に対して熱意のある方に入社していただきたい！

一度、【Wantedly内の弊社ページ】をのぞいてみてください。

Wantedly：https://www.wantedly.com/companies/rightcode