Chapter 08

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

dbt-tokyo
dbt-tokyo
2021.12.02に更新

概要

マテリアライゼーションとは、dbtのモデルをウェアハウスに保存するための戦略です。dbtには4種類のマテリアライゼーションがあります。それらは以下の通りです。

  • table
  • view
  • incremental
  • ephemeral

マテリアアライゼーションを設定する

デフォルトでは、dbtのモデルは "view"として実体化されます。モデルは、以下のようにmaterializedの設定パラメータを指定することで、異なるマテリアライズを設定することができます。

dbt_project.yml
# The following dbt_project.yml configures a project that looks like this:
# .
# └── models
#     ├── csvs
#     │   ├── employees.sql
#     │   └── goals.sql
#     └── events
#         ├── stg_event_log.sql
#         └── stg_event_sessions.sql

name: my_project
version: 1.0.0
config-version: 2

models:
  my_project:
    events:
      # materialize all models in models/events as tables
      +materialized: table
    csvs:
      # this is redundant, and does not need to be set
      +materialized: view

また、モデルのSQLファイルの中で直接マテリアライゼーションを設定することもできます。これは、特定のモデルに対して「パフォーマンス最適化」の設定を行う場合に便利です(例えば、Redshiftに特化した設定やBigQueryに特化した設定など)。

{{ config(
    materialized='table',
    sort='timestamp',
    dist='user_id'
  )
}}

select *
from ...

それぞれのマテリアライゼーションの説明

View

ビュー・マテリアライゼーションを使用する場合、モデルは実行のたびにビューとして再構築され、create view asステートメントを介して実行されます。

  • 長所: 追加のデータは保存されず、ソースデータの上にあるビューには常に最新のレコードが表示されます
  • 短所: 大きな変換を行うビューや、他のビューの上に重ねられたビューは、クエリに時間がかかります
  • アドバイス
    • 通常、モデルにはビューを使用し、パフォーマンスに問題がある場合にのみ、他のマテリアライゼーションに変更します
    • ビューは、名前の変更やカラムの再構成など、大きな変換を行わないモデルに最も適しています

Table

テーブル・マテリアライゼーションを使用する場合、モデルは実行のたびにcreate table asステートメントによってテーブルとして再構築されます。

  • 長所: テーブルのクエリが速い
  • 短所:
    • テーブルの再構築に時間がかかることがある(特に複雑な変換の場合
    • 基礎となるソースデータの新しいレコードは、自動的にテーブルに追加されない。
  • アドバイス
    • BIツールで照会するモデルにテーブルの実体化を使用して、エンドユーザに高速な操作性を提供すると良いでしょう
    • また、処理が多段になるモデルの流れがある場合、Viewだけで実装すると低速の原因になるためテーブルの実体化を使用してください

Incremental

インクリメンタルモデルは、dbtが最後に実行された時からテーブルにレコードを挿入または更新することができます。

  • 長所: 新しいレコードを変換するだけで、構築時間を大幅に短縮できます。
  • 短所:
    • インクリメンタルモデルには追加の設定が必要であり、dbtの高度な使い方となります。インクリメンタルモデルの使い方についてはこちらをご覧ください。
    • 基礎となるソースデータの新しいレコードは、自動的にテーブルに追加されない。
  • アドバイス
    • インクリメンタルモデルはイベント形式のデータに最適です
    • インクリメンタルモデルは、dbtの実行速度が遅すぎる場合に使用してください

Ephemeral

ephemeralモデルは、データベースに直接組み込まれることはありません。その代わりに、dbtはこのモデルからのコードを、CTE(共通のテーブル)表現として依存するモデルに補間します。

  • 長所:

    • 再利用可能なロジックを書くことができる
    • エフェメラルモデルは、データウェアハウスの乱雑さを解消し、データウェアハウスをきれいに保つのに役立ちます(カスタムスキーマを使用して、モデルを複数のスキーマに分割することも検討してください)
  • 短所:

    • このモデルから直接選択することはできません。
    • 操作(例:dbt run-operationで呼び出されるマクロは、エフェメラルノードをref()できません。)
      また、エフェメラル・マテリアライゼーションを使いすぎると、クエリのデバッグが難しくなります
  • アドバイス: エフェメラル・マテリアライゼーションは次のような場合に使用してください

    • DAGの初期段階での非常に軽量な変換
    • 下流の1つまたは2つのモデルでのみ使用され、かつ直接クエリを実行する必要がない場合