← データエンジニアリング 一覧

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：ETLとELT・データ品質とテスト　|　関連：メダリオンアーキテクチャ・ワークフローオーケストレーション

要点（BLUF）

• dbt（data build tool）は、ELTの「T（変換）」をSQLのSELECT文として宣言的に書くフレームワーク。1モデル＝1つのSELECT＝1つのテーブル/ビュー。
• モデル間の依存を ref() で書くと、dbtが依存順を自動解決してDAGを作り、正しい順序で実行する。変換にテスト・ドキュメント・リネージが付く。
• 本質は「変換をソフトウェア工学の作法（バージョン管理・テスト・モジュール化）で扱う」こと。SQLが書ければ、信頼できる変換パイプラインが作れる。（ツールは動きが速いので要最新確認）

概念 ── 変換を「SELECTの宣言」にする

従来、変換は手続き的なスクリプトに散らばりがちでした。dbtは発想を変え、「最終的に欲しいテーブルを定義するSELECT文」を書くだけにします。どう作るか（CREATE TABLE、依存順）はdbtが受け持つ。あなたは「何が欲しいか」をSQLで宣言します。これは SQLの基礎（結合・集約・サブクエリ） の宣言的思想の延長です。

仕組み ── モデル・参照・DAG

flowchart LR
    SRC["source（生データ）"] --> STG["staging（型整え・命名統一）"]
    STG --> INT["intermediate（結合・整形）"]
    INT --> MART["mart（提供用の集計）"]

各段が ref() で前段を参照します（疑似コード）:

-- models/mart_active_customers.sql
SELECT cust_id, MIN(email) AS email
FROM {{ ref('stg_customers') }}
WHERE status = 'active' AND email IS NOT NULL
GROUP BY cust_id

ref('stg_customers') がモデル間の辺になり、dbtは依存DAGを作ってstaging → intermediate → mart の順に実行します。手で実行順を管理する必要はありません（→ ワークフローオーケストレーション のDAGと同じ発想）。

ラボでは、この「変換モデルをテーブル化し、一意性テストを通す」流れをSQLiteで再現しました。

実行結果（実機・SQLite）:

mart_active_customers: [(1, 'a@x.com'), (2, 'b@x.com')]
一意性テスト(cust_id): 重複 0 件 -> PASS

汚れた元データ（重複・NULL・想定外status）から、active顧客だけの整形済みマートを作り、**一意性テストが0件失敗（PASS）**を返す——変換と検証がセットで回ります。

設計の勘所 ── dbtが付けてくれるもの

incrementalマテリアライズは、データ取り込み（バッチ・CDC） の増分とべき等性と再実行 の冪等を組み合わせ、「差分だけ・再実行安全に」変換を更新します。

なぜそうするか ── 変換にエンジニアリングを持ち込む

なぜSQLスクリプトでなくdbtなのか。**変換をコードとして扱える（バージョン管理・レビュー・テスト・再現）**からです。「誰かのSQL」が散在する状態では、数字の出所が追えず、壊れても気づけない。dbtは変換をGit管理のモデルにし、依存を明示し、テストとドキュメントを強制することで、変換層を“信頼できるソフトウェア”に変えます。アナリティクスエンジニアという役割（→ データエンジニアリングとは・役割）が成立したのも、この道具立てのおかげです。

⚠️ よくある落とし穴

• 1モデルに巨大SQLを詰める → テスト・再利用ができない。staging/intermediate/martに段階分割。
• ref()を使わず直接テーブル名を書く → 依存DAGが壊れ、実行順とリネージが失われる。
• テストを書かない → dbtの価値が半減。最低限unique/not_nullを主キーに。
• すべてをtableマテリアライズ → 計算コスト増。鮮度要件で view/incremental を使い分ける。

対応ラボ

data-engineering-study/labs/04_etl_pipeline.py（PYTHONIOENCODING=utf-8 で実行・変換モデルのテーブル化と一意性テストPASSを確認済み）。

関連

• ELTにおける変換の位置づけは ETLとELT、テストの一般論は データ品質とテスト
• 段階的な層構造（bronze/silver/gold）は メダリオンアーキテクチャ
• 依存DAGの実行・スケジュールは ワークフローオーケストレーション

← 第4章 ETLとデータパイプライン 目次