(data build tool) は 上の変換 (Transform) を SQL ファイルとして書き、 で管理し、依存関係を自動で組み立て、テストする ツールです。2016 年に Fishtown Analytics (現 dbt Labs) が 公開、現在は アナリティクスエンジニアリングという職種を生み出した中心ツールになっています。
dbt 以前、変換ロジックは ツールの や stored procedure に閉じ込められ、 管理されず、テストも書けず、誰がいつ何を変えたか追えなかった。dbt は変換を 「ただの SQL ファイル」 に戻し、ソフトウェア開発の手法（PR レビュー / CI / バージョニング）をデータ変換に持ち込みました。
と ── dbt の前提
古典的な は 「Extract → Transform → Load」 の順で、変換を専用サーバ（Informatica / Talend 等）でやってから DWH に書き込んでいました。 は 「Extract → Load → Transform」 ── 生データをまず に放り込み、変換は の中で で行う発想。 / の安価で巨大な計算リソースが前提です。
dbt は ELT の T 専用ツール。Extract / Load は / Fivetran / 等の別ツールに任せ、dbt は DWH 内の SELECT 文を組み立てる ことに特化します。
dbt が解決する 6 つの問題
| dbt 以前の問題 | dbt が提供する解決 |
|---|---|
| 変換ロジックが GUI に閉じ込められ Git で管理できない | model = 1 つの `.sql` ファイル → Git 管理 |
| テーブル間の依存関係が口伝・ドキュメント頼り | `ref()` で依存を宣言 → DAG 自動構築 |
| スキーマ変更時の影響範囲が見えない | lineage グラフ + 依存テストで追跡可能 |
| 「正しい」テーブルがどれか分からない | model = 正本、 自動生成 |
| テストが書けない | `schema.yml` で unique / not_null / 関係性テストを宣言 |
| 環境（dev/stg/prod）の切替が面倒 | `profiles.yml` でターゲット環境ごとに切替 |
「 + Jinja」 が dbt の中核
dbt の model は Jinja テンプレート + で書きます。`ref()` `source()` `var()` `config()` などの Jinja 関数で、動的な SQL 生成と 依存宣言ができる。
{{ config(materialized='table') }}
WITH source AS ( SELECT * FROM {{ ref('stg_customers') }}),
orders_summary AS ( SELECT customer_id, COUNT(*) AS order_count, SUM(amount) AS lifetime_value FROM {{ ref('fct_orders') }} GROUP BY customer_id)
SELECT s.customer_id, s.name, s.email, COALESCE(o.order_count, 0) AS order_count, COALESCE(o.lifetime_value, 0) AS ltvFROM source sLEFT JOIN orders_summary o USING (customer_id)ポイント: テーブル名を直接書かず、`ref('stg_customers')` と書く。dbt が 環境別の正しいテーブル名（`dev_marts.dim_customers` か `prod_marts.dim_customers` か等）に展開し、依存関係も自動で解析します。
dbt が向くケース / 向かないケース
| 向く | 向かない |
|---|---|
| DWH ( / / Redshift / 等) を持っている | DWH なし、 に直接クエリ |
| ELT 設計で変換は DWH 内で行う | ETL でストアドプロシージャ依存 |
| 分析・レポート用テーブルを 10〜数千個作る | リアルタイム ストリーミング処理（dbt は本来バッチ） |
| ベースの開発フローを組みたい | 「画面だけで運用したい」志向 |
| 複数人で SQL を書き合う | 1 人で完結する小規模 |
dbt が新たに作った課題
- model 数の爆発: 数千 model を超えるとビルド時間と CI コストが急増
- 依存の長さ: 5 段以上の依存だと変更影響が見えづらくなる
- 「dbt おじさん」の出現: 全 model を 1 人が把握、退職で詰まる
- コストの可視化が難しい: 1 つの `dbt run` で何ドル使ったかをすぐ出せない
- Jinja の学習コスト: Pythonっぽいけど SQL に埋め込む独自構文
本シリーズでは「始め方」から「こうした課題への向き合い方」まで体系的に扱います。
シリーズ全体像
- 1dbt とは（本記事）
- 2dbt Core vs dbt Cloud と環境セットアップ
- 3プロジェクト構造と最初の dbt run
- 4ref() と source() で依存関係を組む
- 5materialization 4種の使い分け
- 6テストの書き方：4 つの組込み + custom test
- 7ドキュメント生成：schema.yml と dbt docs
- 8macros：Jinja で SQL を再利用
- 9packages：dbt_utils / dbt-expectations を使い倒す
- 10seeds と snapshots：静的データと SCD Type 2
- 11incremental models：差分更新パターン (近日公開)
- 12CI/CD：Slim CI で安全にデプロイ
- 13dbt Mesh：大規模組織でのプロジェクト分割
- 14Semantic Layer / Metrics：指標の正本管理
- 15アンチパターン 10 選
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。