フレームワーク活用ガイドひとことで言うと#
DWH内のデータ変換をSQLファイルとして管理し、バージョン管理・テスト・ドキュメント生成を自動化するフレームワーク。「SELECT文を書くだけ」でパイプラインが構築できるのが特徴。
押さえておきたい用語#
- dbt（data build tool）
- SQLベースでDWH内のデータ変換を管理するオープンソースツール。変換の定義、テスト、ドキュメント化をすべてSQLとYAMLで行う。
- モデル（Model）
- dbtにおけるSQL変換の最小単位。1つのSQLファイルが1つのテーブルまたはビューに対応する。
- ref関数
- dbtモデル間の依存関係を定義する関数。
{{ ref('stg_orders') }}のように書くと、dbtが実行順序を自動解決する。 - テスト（Test）
- モデルのデータ品質を検証する仕組み。
not_null、unique、accepted_values等の組み込みテストと、カスタムテストが使える。
dbt変換モデルの全体像#
こんな悩みに効く#
- DWH内のSQLが散在していて誰がどのテーブルを作ったかわからない
- 変換ロジックの変更でどのテーブルに影響が出るか把握できない
- データの品質テストが手動で、問題発見が遅れる
基本の使い方#
DWHにロードされた生テーブルをソースとして登録し、最初のステージングモデルを作る。
- schema.ymlでソーステーブルの名前・カラム・説明を登録。freshnessチェックも仕込める
- stg_モデルは型変換・カラムリネーム・基本フィルタだけの最小限のSELECT文
- 1つのソースに対して1つのstg_モデルが原則
ステージングを組み合わせて、分析用のテーブルを構築する。
- int_モデルで複数のstg_モデルをJOIN・フィルタ・集約。
{{ ref('stg_orders') }}で依存関係を定義 - mart_モデルはBIやMLに渡す最終テーブル。部門別に
mart_marketing_・mart_finance_と分ける - dbtが
ref()の依存関係からDAGを自動生成し、実行順序を解決する
モデルの品質をテストで保証し、Gitフローに組み込む。
- 組み込みテストは
not_null・unique・accepted_values・relationships - カスタムテストはSQLで自由に書ける（例: 金額がマイナスでないこと）
- CI/CDはPR作成時にdbt test自動実行 → テスト通過後マージ → 本番デプロイ
具体例#
従業員40名のBtoB SaaS。MRRや解約率の計算を毎月スプレッドシートで手作業していた。計算ミスが四半期に1回は発生し、経営会議で報告する数字の信頼性が問題になっていた。
dbtプロジェクトを構築。
| モデル | 内容 |
|---|---|
| stg_stripe_subscriptions | Stripeの契約データを型変換 |
| stg_hubspot_companies | HubSpotの企業データをリネーム |
| int_subscription_events | 契約開始・解約・アップグレードを時系列化 |
| mart_monthly_mrr | 月次MRR、新規MRR、解約MRR |
全モデルにnot_null、uniqueテストを設定。PR時にdbt testが自動実行される仕組みを導入。手作業の集計時間が月 12時間 → 0時間 に。計算ミスはゼロになり、経営会議の数字に対する信頼が回復した。
年商25億円のEC企業。BigQueryに100本以上のスケジュールクエリが存在し、どのクエリがどのテーブルを参照しているか誰も把握できていなかった。
dbtに移行し、命名規則を統一。
- stg_: 18モデル（source 1:1）
- int_: 25モデル（ビジネスロジック）
- mart_: 12モデル（BI向け最終テーブル）
DAGの可視化で依存関係が明確になり、「このソースを変更したらどのテーブルに影響するか」が一目瞭然に。dbt docsのドキュメント自動生成で、新メンバーのオンボーディング時間が 2週間 → 3日 に短縮された。
人材マッチングプラットフォーム（従業員200名）。外部パートナーからのデータフィードが不定期に壊れ、ダッシュボードの数字がおかしくなっても平均 3日 気づかなかった。
dbtのfreshnessチェックとカスタムテストを導入。
- freshnessは最終更新が6時間以上前でwarning、24時間以上でerror
- カスタムテストで「前日比レコード数が50%以上減少したらfail」を設定
- dbt testの失敗はSlackの#data-alertsチャンネルに自動投稿
導入後、外部フィードの異常を 平均1.5時間 で検知できるようになった。3日間おかしな数字のまま経営判断が進むリスクがなくなり、データチームへの信頼度が大きく向上。
やりがちな失敗パターン#
- ステージングを飛ばしていきなりマートを作る — ソーステーブルを直接JOINするとソース変更時にすべてのマートが壊れる。stg_層を挟むことで変更の影響を局所化する
- テストを後回しにする — 「まずモデルを作って、テストはあとで」と言って永遠にテストが書かれないパターン。モデルとテストはセットで作る
- 命名規則がバラバラ —
stg_、int_、mart_のプレフィクスなしにモデルを作ると、どの層のテーブルかわからなくなる。プロジェクト開始時に規則を決めて強制する - マートが増殖する — 部門ごとに似たようなマートが乱立すると指標の定義が割れる。共通のint_モデルから部門別martを派生させ、指標の定義を一元管理する
まとめ#
dbt変換モデルは、DWH内の変換を「SQLファイル＋テスト＋ドキュメント」としてGit管理するフレームワーク。ref()で依存関係が自動解決されるので、100本のクエリが散在している状態から「この変更でどこが壊れるか」が一目でわかる状態になる。dbt docsを初めて開いたときの「全部つながって見える」感覚は、使ってみないとわからない。