dbt入門――SQLベースのデータ変換ツールでできること・始め方

dbt(data build tool)とは、SELECT文だけでデータ変換パイプラインを構築し、テスト・ドキュメント・依存関係管理までを一体で扱えるオープンソースのツールです。ELTアーキテクチャの「T(Transform)」を担う役割として、SnowflakeやBigQueryといったクラウドDWHと組み合わせて利用するのが定番の構成となっています。本記事では、dbtの基本機能、仕組み、モデル定義の書き方、そして最初のプロジェクトを立ち上げるまでの5ステップを、実際のSQL・YAML・コマンド例を交えながら解説します。読み終える頃には「なぜいまdbtがデータ変換のデファクトスタンダードと呼ばれるのか」が、腑に落ちるはずです。

dbtとは何か――「SQLだけでデータ変換パイプラインを構築する」ツール

dbt(data build tool)は、SELECT文を書くだけでDWH内部にテーブルやビューを生成し、そのテーブルに対してテスト・ドキュメント・依存関係管理を同時に行えるオープンソースのデータ変換ツールです。開発元は米Fishtown Analytics社(現dbt Labs社)で、2016年頃から本格的に広まりました。

dbtは、現代のELTアーキテクチャにおける「T(Transform)」の層を担います。Fivetranやcustom ingestion scriptでDWHにデータが取り込まれた後、dbtがその生データをクリーニング・結合・集計してビジネス利用可能な分析テーブルを作る、という分業です。

「Python等の汎用言語ではなく、なぜSQLなのか」という問いに対するdbtの回答は明快です。第一に、SQLはアナリストからエンジニアまで広く使える共通言語だからです。第二に、DWH側でクエリを実行するため処理性能を最大化できるからです。第三に、バージョン管理・コードレビュー・CI/CDといったソフトウェアエンジニアリングの作法を、SQLの世界にそのまま持ち込めるからです。結果としてdbtは「データ変換の民主化」を実現するツールとして広く採用されるに至りました。

dbtでできること5つ

dbtの価値は、単なるSQL実行ツールにとどまらず、データ変換に必要な周辺機能を一体化した点にあります。ここでは中心となる5つの機能を整理します。

1. モデル定義：SELECT文を1ファイル1モデルとして書くだけで、dbtがそれをビューまたはテーブルとしてDWH上に実体化します。CREATE TABLE文を書く必要はありません。モデル間のref()関数による参照が、そのまま依存関係の定義になります。

2. テスト：not_null、unique、accepted_values、relationshipsなどの組み込みテストをYAMLで宣言するだけで、データ品質の自動チェックが走ります。カスタムテストもSQLで記述可能です。

3. ドキュメント：schema.ymlにカラム説明を書くと、dbt docs generateコマンドで静的サイト形式のドキュメントが自動生成されます。リネージグラフも含まれるため、データの流れを視覚的に追えます。

4. リネージ：ref()関数の呼び出し関係からDAG(有向非巡回グラフ)を自動生成し、モデル間の依存を可視化します。影響範囲の調査や並列実行の最適化に役立ちます。

5. スナップショット：SCD Type 2(Slowly Changing Dimension Type 2)を自動実装します。dbt snapshotコマンド1つで、履歴テーブルの更新が完結します。

機能	概要	対応コマンド	ユースケース
モデル定義	SELECT文でテーブル/ビューを定義	dbt run	生データから分析用テーブルへの変換全般
テスト	not_null、unique等のデータ品質チェック	dbt test	主キー一意性、外部キー整合性の検証
ドキュメント	カラム説明とリネージの自動生成	dbt docs generate	データカタログとしての共有
リネージ	モデル間の依存関係の可視化	dbt run –select	影響範囲調査、障害時の上流特定
スナップショット	SCD Type 2による履歴管理	dbt snapshot	顧客ステータス履歴、商品マスタの変更追跡

dbtの基本的な仕組み

dbtの処理フローは驚くほどシンプルです。開発者はSQLファイルを書き、dbt runコマンドを実行するだけで、あとはdbtがSQLをコンパイルし、DWHに対して正しい順序で実行してくれます。

【dbtのワークフロー】

[SQLファイル作成] --> [dbt run] --> [コンパイル: Jinja展開]
                                         |
                                         v
[DWH上でSELECT実行] <-- [依存関係順に実行制御]
          |
          v
[テーブル/ビュー生成] --> [dbt test] --> [データ品質検証]

※ dbt本体はメタデータ管理とSQL生成に専念し、重い計算はDWH側で実行する

プロジェクトのディレクトリ構造も明快です。modelsフォルダにSQLファイル、testsにカスタムテスト、macrosにJinjaマクロ、snapshotsにSCD定義、そしてdbt_project.ymlに設定を置きます。この規約によって、どのdbtプロジェクトを見ても「どこに何があるか」がすぐに把握できます。

my_dbt_project/
├── dbt_project.yml
├── models/
│   ├── staging/
│   ├── intermediate/
│   └── marts/
├── tests/
├── macros/
└── snapshots/

dbtのモデル定義――SELECT文だけでテーブルを作る

dbtプロジェクトでは、モデルを「staging」「intermediate」「marts」の3層に分ける設計が定番です。各層の役割を段階的に見ていきましょう。

stagingモデルは、ソーステーブルの型変換・カラム名統一・NULL処理などのクリーニングに特化します。1:1でソースと対応させるのが原則です。

-- models/staging/stg_orders.sql
select
    id as order_id,
    user_id as customer_id,
    order_date::date as ordered_at,
    status,
    amount::numeric(10,2) as amount_jpy
from {{ source('raw', 'orders') }}
where status != 'cancelled'

intermediateモデルは、stagingモデルを組み合わせて中間的なビジネスロジックを実装します。複数テーブルの結合や再利用される計算をここに集約します。

martsモデルは、BIツールから参照される最終的な分析テーブルです。JOIN・集計・ディメンション付与など、ビジネス利用を前提とした構造に整えます。

-- models/marts/fct_customer_orders.sql
select
    c.customer_id,
    c.customer_name,
    count(o.order_id) as order_count,
    sum(o.amount_jpy) as total_amount
from {{ ref('stg_customers') }} c
left join {{ ref('stg_orders') }} o
  on c.customer_id = o.customer_id
group by 1, 2

さらにschema.ymlを書けば、カラムの説明とテストを同じ場所で宣言できます。dbtが最も高く評価される理由の1つが、この「変換コードとテスト・ドキュメントの近接配置」にあります。

version: 2
models:
  - name: fct_customer_orders
    description: "顧客単位の注文サマリ"
    columns:
      - name: customer_id
        description: "顧客の一意識別子"
        tests:
          - not_null
          - unique
      - name: total_amount
        description: "当該顧客の合計購入金額(円)"
        tests:
          - not_null

dbtの始め方――5ステップでHello World

dbtは比較的学習コストが低いツールです。DWHアカウントとローカルのPython環境さえあれば、30分もあれば最初のモデルを実行できます。以下の5ステップで手を動かしてみましょう。

ステップ1：インストール。dbtはアダプタ方式を採っているため、利用するDWHに対応するパッケージを入れます。Snowflakeならpip install dbt-snowflake、BigQueryならpip install dbt-bigqueryです。

ステップ2：プロジェクト初期化。dbt initコマンドを実行すると対話的にプロジェクト名と接続先を尋ねてくれます。

ステップ3：profiles.yml設定。~/.dbt/profiles.ymlにDWHの認証情報を記述します。環境ごとにdev/prodを分けられます。

my_project:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: xxxxx.ap-northeast-1.aws
      user: my_user
      password: "{{ env_var('DBT_PASSWORD') }}"
      database: ANALYTICS_DEV
      schema: dbt_my_user
      warehouse: TRANSFORM_WH

ステップ4：最初のモデル作成。models/example/my_first_model.sqlに簡単なSELECT文を書きます。

ステップ5：実行とドキュメント生成。以下の3コマンドで、モデル実行、テスト、ドキュメント生成を順に走らせます。

dbt run
dbt test
dbt docs generate
dbt docs serve

最後のdbt docs serveでローカルにドキュメントサイトが立ち上がり、リネージグラフを視覚的に確認できます。

dbt Core vs dbt Cloud

dbtには「dbt Core」と「dbt Cloud」という2つの利用形態があります。前者はCLIで動くOSS本体、後者はスケジューラとWeb IDEを備えたSaaSです。dbt自体の機能は共通で、違いは運用体験とインフラの担い手にあります。詳細な比較は別記事で扱いますが、ここでは最低限の対比を押さえておきましょう。

項目	dbt Core	dbt Cloud
実行環境	自前のサーバー・CI/CD	マネージドな実行環境
Web IDE	なし(ローカル開発)	あり(ブラウザ完結)
スケジューリング	Airflow等が別途必要	組み込みジョブスケジューラ
CI/CD	GitHub Actions等を自作	組み込みCI機能
料金	完全無料	Developer無料／Team $100/シート〜

まとめ――dbtは「データ変換の民主化」を実現するツール

本記事の要点を振り返ります。

dbtはSELECT文だけでデータ変換を定義するOSS。ELTの「T」を担う
モデル・テスト・ドキュメント・リネージ・スナップショットが一体化
staging → intermediate → martsの3層構造がベストプラクティス
pip installからdbt runまで30分で最初の実行が可能
Coreは無料、Cloudは運用体験を買うSaaS。まずCoreから始めるのも有効

次に読むべき記事は、dbt Core vs Cloudの詳細比較、3層アーキテクチャの設計指針、そして品質テスト自動化の実践編です。DE-STKでは、dbtを軸としたデータ変換基盤の設計・実装から、組織への展開支援までを一貫して行っています。導入の相談は専門家へぜひお気軽にどうぞ。

よくある質問(FAQ)

Q. dbtとは何ですか?

A. dbt(data build tool)は、SELECT文でデータ変換を定義し、テスト・ドキュメント・リネージを一体管理するオープンソースのデータ変換ツールです。ELTアーキテクチャの「T(Transform)」を担います。

Q. dbtを使うのにPythonのスキルは必要ですか?

A. 基本的な利用にはSQLの知識だけで十分です。高度なカスタマイズ(マクロ・カスタムテスト)にはJinja2テンプレートの知識があると便利ですが、Python自体は不要です。

Q. dbtはどのDWHに対応していますか?

A. Snowflake、BigQuery、Redshift、Databricks、PostgreSQLなど主要なDWH/データベースに対応しています。アダプタ方式で拡張でき、コミュニティ製アダプタも多数あります。