😸

【dbt Docs】Building a dbt Project - Models - Materializations

2022/03/10に公開

対象ページ

https://docs.getdbt.com/docs/building-a-dbt-project/building-models/materializations

Materializations

Overview

dbtがモデルを永続化するためには、次の4つ方式がある

  • table
  • view
  • incremental
  • ephemeral

Configuring materializations

デフォルトでは、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ファイル内のconfigで指定することもできる。

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

select *
from ...

Materializations

View

dbtでのデフォルトはこれ。create view asを使って作られる。

  • 長所
    • 追加のデータは保存されない
    • ソースデータの上にあるビューは常に最新のレコードが含まれる(Viewはあくまでも「型」)
  • 短所
    • クエリが遅くなることがある
  • アドバイス
    • 通常は、viewで開始し、パフォーマンス上問題が起これば、tableにする
    • viewは、列名の変更再キャストなど軽い変換をするのに向いてる。ロジック変換は△

Table

create table asを用いて作られる。モデルは、実データを持つテーブルとして構築される。

  • 長所:クエリが早い、パフォーマンスがたとViewと比較して良い
  • 短所
    • 複雑な返還の場合、テーブルの再構築に長い時間がかかる場合がある
    • 元となるソースデータは自動的に追加されない
  • アドバイス
    • BIツール用のモデルなどには、Tableを使うのが良い
    • また、多くのダウンストリームモデルで使用される低速の変換には、テーブルの実体化を使用します

Incremental

incrementalモデルを使用すると、dbtが実行されてから、dbtがレコードをテーブルに挿入または更新できます。

  • 長所: 新しいレコードを変換するだけで、ビルド時間を大幅に短縮できます
  • 短所:incrementalを使うには追加の設定が必要。dbtの高度な使い方。くわしくはこちら
  • アドバイス:
    • インクリメンタルモデルはイベントスタイルのデータに最適
    • dbt runがすごい時間がかかるようになると incrementalを使うべし

Ephemeral

ephemeralモデルは、データベースに直接組み込まれない。
dbtはこのモデルのコードを共通テーブル式として、依存モデルの間を取り持つ

  • 長所
    • 再利用可能なロジックがかける
    • ephemeralモデルを使うと、DWHをシンプルに保つことができる。
  • 短所
    • 直接使えない
    • 操作できない(dbt run-operationできない) ※よくわからない・・・
    • 使いすぎるとモデルやSQLのデバッグが難しくなるかも
  • アドバイス
    • DAGIの初期段階にある非常に軽量な変換
    • 1つまたは2つのダウンストリームモデルでのみ使用される
    • 直接問い合わせる必要はありません。

Discussion