ETLとELT｜データエンジニアリング

🎓 レベル：基礎　|　重要度：A（必須）

📎 前提：現代データスタックの地図　|　関連：SQL変換とdbt・データウェアハウス

要点（BLUF）

どちらも E（抽出）・T（変換）・L（ロード） の3工程。違いは**変換をロードの前にやるか（ETL）、後にやるか（ELT）**だけ。
ETL：源から抽出 → 別の処理層で変換 → 整形済みをDWHにロード。ELT：源から抽出 → 生のままDWH/レイクにロード → DWHの計算力で変換。
クラウドでストレージが激安・計算が弾力的になり、生データを貯めて後から変換するELTが現代の主流。生を残すので、要件変更時に源へ取りに戻らず変換し直すだけで済む。

概念 ── 変換の場所が違うだけ

flowchart LR
    subgraph ETL["ETL（ロード前に変換）"]
      E1["抽出"] --> T1["変換（別エンジン）"] --> L1["ロード（整形済み）"]
    end
    subgraph ELT["ELT（ロード後に変換）"]
      E2["抽出"] --> L2["ロード（生のまま）"] --> T2["変換（DWH内SQL）"]
    end

工程の文字を並べ替えただけに見えますが、生データを残すか捨てるかという運用上の大差を生みます。

設計の勘所 ── ETL と ELT の比較

観点	ETL	ELT
変換の場所	専用処理層（Spark等）	DWH/レイク内（SQL・dbt）
生データ	残らない（整形後のみ保存）	残る（後から再変換可能）
前提	ストレージ高価・DWH非力	ストレージ安価・DWH強力
機密処理	ロード前にマスキング可能	ロード後（生がDWHに入る点に注意）
典型	オンプレ時代・規制が厳しい領域	現代クラウドデータスタック

なぜそうするか ── 「生を残す」価値

なぜELTが主流になったのか。鍵は**「生データを安く貯められるようになった」**こと。

要件変更に強い：変換ロジックは後から何度でも書き直せる。ETLだと整形後しか残らず、新しい切り口が必要になると源へ取りに戻る羽目に。
責務分離：「運ぶ（EL）」と「整える（T）」を分けられる。取り込みはデータ取り込み（バッチ・CDC）のツール、変換は SQL変換とdbt のSQL、と各々最適化できる。
再現性：生→変換が決定的なら、いつでも同じ結果を再生成できる（→ べき等性と再実行）。

ただしELTは生データがそのままDWHに入るため、個人情報のマスキングや権限管理（→ データガバナンスとカタログ）を後段でしっかり設計する必要があります。規制が厳しくロード前マスキングが必須なら、今もETLが選ばれます。

⚠️ よくある落とし穴

ELTで生を貯めるだけ貯めて整理しない → “データ沼（swamp）”化。層構造（→ メダリオンアーキテクチャ）とカタログで秩序を保つ。
ETL/ELTを「ツールの種類」と思う → 工程の順序の話。同じツールでもどちらにもなる。
ロード後変換でPIIを無防備に置く → ELTでは取り込み直後の権限・マスキング設計が必須。
「変換」を一枚岩で書く → 段階（bronze/silver/gold）に分け、テスト可能な単位に割る（→ SQL変換とdbt）。

対応ラボ

なし（概念回）。実際の取り込み・変換・テストはデータ取り込み（バッチ・CDC）・SQL変換とdbt のラボで扱う。