😸
【dbt Docs】Building a dbt Project - 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