dbtが『データウェアハウスのSQL変換』を標準化する
dbt（data build tool）はデータウェアハウスのELTパイプラインで、Transformation（変換）レイヤを担うOSSツールです。SQLをコードとして管理し、依存関係解決・並列実行・テスト・ドキュメント生成を自動化します。BigQuery/Snowflake/Redshift/Databricks等の主要DWHで2020年以降急速に普及し、2026年現在はデータエンジニアリングのデファクトとして定着。dbt CloudのSaaS版も展開しています。
採用すべき5つのシグナル
- データウェアハウスにSQLジョブが大量にあり管理が複雑
- データ品質テスト（NULL・重複・参照整合性）を自動化したい
- SQL変換のドキュメンテーションをコード化したい
- BIツール（Looker/Metabase）への提供データを統一管理したい
- データエンジニアとデータアナリストの協業を整理したい
従来手法との比較
SQLスクリプト直書き: シンプル・小規模で十分・規模拡大で破綻。
Airflow + SQL: スケジューラ強い・SQL管理は別途・複雑。
dbt: SQL中心・テスト/ドキュメント標準化・依存解決自動。
Dataform: GCP製・dbtに近い思想・Cloud BigQuery統合。
使い分け: マルチクラウド・OSS重視ならdbt、GCP閉じこもりはDataformも選択肢。
dbtの主要機能
- Model: SELECT文を書くだけで自動的にテーブル/ビューを生成
- Ref:
{{ ref('model_name') }}でModel間の依存を表現 - Test: NULL・unique・参照整合性等のテストを宣言的に
- Source: 上流データソースの定義・チェック
- Doc: ドキュメント自動生成（リネージ図含む）
- Macro: Jinja templatingで再利用可能なSQL
- Snapshot: SCD Type 2の履歴保持
料金感（実務目安）
- dbt Core (OSS): 完全無料・Self-host
- dbt Cloud Developer: $100/月で1ユーザー
- dbt Cloud Team: $100/月/ユーザー
- dbt Cloud Enterprise: 個別契約
本番運用の3つのチェックポイント
- Incremental Model: 大量データを毎回フルテーブル再生成するのは非効率。Incremental設計が重要
- テストの粒度: 全Model にテストを書きすぎると遅い・重要なModelに絞る
- Lineage管理: 上流ソース変更時の影響範囲をdbt docs lineage で可視化
dbtを採用するベストタイミング
- SQLジョブが20本超え・依存関係が複雑になり始めた
- データチームが3人以上・協業の必要性が高まった
- BIツールへのデータ提供が定期的に発生
- データ品質問題が頻発・テスト自動化が必要
- データドキュメントが古くなる問題
30日学習プラン
- 1週目: dbt Coreインストール・BigQueryで最初のModel作成
- 2週目: ref()・テスト・ドキュメント・Lineage
- 3週目: Incremental Model・Macro・パフォーマンス最適化
- 4週目: dbt Cloud or self-host・本番運用・スケジューラ統合
関連リンク
データエンジニアキャリアは データエンジニアキャリア、Airflowは Airflow実践、BigQueryは BigQuery深掘り を参照してください。データ分析は Polars深掘り もどうぞ。