dbtの概要と思想

田中VPoE「MDSの全体像が掴めたところで、次はTransformation Layerの中核ツール『dbt』を学ぼう。うちの変換処理は全部シェルスクリプトだったけど、dbtに置き換えることで世界が変わるよ。」

あなた「dbt…名前は聞いたことがあります。SQLで変換を書くツールですよね？」

田中VPoE「それだけじゃない。dbtは『アナリティクスエンジニアリング』という新しい職種を生み出したほどのインパクトがあるツールだ。テスト、ドキュメント、依存関係管理まで含めた、データ変換の包括的なフレームワークなんだ。」

dbtとは

dbt（data build tool）は、SQLベースのデータ変換フレームワークです。ELTの「T」（Transform）を担当し、DWH内でのデータ変換をソフトウェアエンジニアリングのベストプラクティスに則って管理します。

dbtが解決する問題

従来のデータ変換の課題

課題	従来のアプローチ	dbtによる解決
変換ロジックの管理	シェルスクリプト/手動SQL	SQLファイルとしてGit管理
テスト	なし	自動テスト（not_null, unique等）
ドキュメント	別途Excel管理（更新されない）	コードから自動生成
依存関係	暗黙的（実行順序が不明）	ref()関数で明示的に定義
再現性	環境依存	冪等な実行（何度実行しても同じ結果）
コードレビュー	なし	PRベースのレビューフロー

dbtの基本アーキテクチャ

┌─────────────────────────────────────┐
│          dbt Project                │
│                                     │
│  models/          tests/            │
│  ├── staging/     ├── generic/      │
│  ├── marts/       └── singular/     │
│  └── intermediate/                  │
│                                     │
│  macros/          seeds/            │
│  └── utils.sql    └── country.csv   │
│                                     │
│  dbt_project.yml  profiles.yml      │
└─────────────────────────────────────┘
           │
           ▼  dbt run
┌─────────────────────────────────────┐
│       Data Warehouse (BigQuery)     │
│  raw.orders → stg_orders → mart_*  │
└─────────────────────────────────────┘

dbtの主要概念

1. モデル（Model）

モデルは1つのSELECT文を含む.sqlファイルです。dbtはこのSQLを実行してDWH上にテーブルまたはビューを作成します。

-- models/staging/stg_orders.sql
SELECT
    id AS order_id,
    user_id AS customer_id,
    CAST(amount AS NUMERIC) AS order_amount,
    CAST(created_at AS TIMESTAMP) AS ordered_at,
    status
FROM {{ source('raw', 'orders') }}
WHERE status != 'cancelled'

2. ref()関数

モデル間の依存関係を明示的に定義します。

-- models/marts/mart_daily_sales.sql
SELECT
    DATE(ordered_at) AS order_date,
    COUNT(*) AS order_count,
    SUM(order_amount) AS total_amount
FROM {{ ref('stg_orders') }}
GROUP BY 1

{{ ref('stg_orders') }} により、dbtは自動的に実行順序を決定します。

3. マテリアライゼーション

モデルの実体化方法を制御します。

タイプ	説明	ユースケース
view	ビューとして作成	軽い変換、参照頻度が低い
table	テーブルとして作成	集計結果、頻繁に参照
incremental	差分更新	大量データ、日次追加
ephemeral	CTE展開（実体なし）	中間計算、再利用される部分クエリ

4. ソース（Source）

外部データソースを定義し、dbtプロジェクト内で参照可能にします。

# models/staging/_sources.yml
version: 2

sources:
  - name: raw
    database: netshop_raw
    schema: mysql
    tables:
      - name: orders
        loaded_at_field: _etl_loaded_at
        freshness:
          warn_after: {count: 12, period: hour}
          error_after: {count: 24, period: hour}
      - name: customers
      - name: products

5. プロジェクト構成

# dbt_project.yml
name: 'netshop'
version: '1.0.0'

profile: 'netshop'

model-paths: ["models"]
test-paths: ["tests"]
seed-paths: ["seeds"]
macro-paths: ["macros"]

models:
  netshop:
    staging:
      +materialized: view
      +schema: staging
    marts:
      +materialized: table
      +schema: marts

dbt Core vs dbt Cloud

項目	dbt Core	dbt Cloud
料金	無料（OSS）	有料（Developer無料枠あり）
実行環境	ローカル/CI	マネージドSaaS
スケジューリング	外部ツール（Airflow等）	組み込み
IDE	テキストエディタ	Web IDE
CI/CD	自前構築	組み込み
推奨	小〜中規模、エンジニア主体	中〜大規模、チーム利用

dbtのワークフロー

1. git checkout -b feature/add-customer-ltv
2. モデル（SQL）を作成・編集
3. dbt run --select customer_ltv    # モデルを実行
4. dbt test --select customer_ltv   # テストを実行
5. dbt docs generate                # ドキュメント更新
6. git commit & PR作成
7. コードレビュー
8. マージ → 本番環境で dbt run

まとめ

項目	ポイント
dbtとは	SQLベースのデータ変換フレームワーク
核心的価値	テスト・ドキュメント・依存関係管理の統合
ref()関数	モデル間の依存関係を明示的に定義
マテリアライゼーション	view / table / incremental / ephemeral
ワークフロー	Gitベースの開発フロー

チェックリスト

dbtの目的と解決する問題を説明できる
モデル、ref()、ソースの概念を理解している
4つのマテリアライゼーションタイプの違いを説明できる
dbt Core と dbt Cloud の違いを理解している

次のステップへ

dbtの基本概念を理解しました。次は、実際にdbtモデルを設計・実装する方法を詳しく学びましょう。

推定読了時間：30分