ELT vs ETL｜クラウド時代に”変換を後回し”にすべき理由と例外

ETLとELTの違い――「変換のタイミング」がすべて

ETL(Extract→Transform→Load)とELT(Extract→Load→Transform)の違いは、「変換をデータ格納の前に行うか、後に行うか」の一点に集約されます。ETLは外部の変換サーバーでデータを加工してからDWHに格納し、ELTは生データをそのままDWHにロードしてからDWH上のSQLで変換します。

この順序の差が、アーキテクチャの柔軟性・コスト・スキルセットに大きな影響を与えます。クラウドDWHが普及した現代では、多くのケースでELTが推奨されますが、ETLが適する例外も存在します。

ETL・ELTの処理フロー比較図

【ETL】
ソースDB/SaaS
    │
    ▼ Extract(抽出)
変換サーバー(Informatica / Talend / SSIS)
    │
    ▼ Transform(変換・クレンジング・集計)
DWH(Teradata / Oracle等)
    │
    ▼ Load(格納)
分析・BI

【ELT】
ソースDB/SaaS
    │
    ▼ Extract + Load(抽出・格納)
クラウドDWH(BigQuery / Snowflake / Redshift)
    │
    ▼ Transform(dbt等のSQLで変換)
Marts / BI層

ETLの時代――なぜ「先に変換」していたのか

2000年代まで主流だったETLアーキテクチャには、当時のインフラ制約に根ざした合理的な理由がありました。

ストレージコストが高価: オンプレミスDWH(Teradata・Oracle等)のストレージは高価であり、不要なデータは変換段階で除外して格納量を最小化するのが当然でした。「生データをすべて入れる」という発想自体がコスト的に非現実的でした。
DWHの処理能力が限定的: 変換処理には膨大なCPUが必要でしたが、DWH本体の処理リソースは分析クエリのために温存する必要がありました。外部ETLサーバーで変換を担うことで、DWHへの負荷を抑えました。
バッチウィンドウの制約: 夜間バッチのみで処理できる時間枠が限られており、変換処理を外部に出すことでDWHのバッチ実行を効率化していました。

代表的なETLツールとして、Informatica PowerCenter(エンタープライズ標準)、Talend(OSSベース)、Microsoft SSIS(SQL Server環境)が挙げられます。これらはGUIでのマッピング設計が中心であり、データエンジニアではなく専任のETLエンジニアが担当するのが一般的でした。

ELTの台頭――クラウドDWHが変えたゲームルール

2010年代後半からクラウドDWHが普及し、ETLの前提を覆す3つの変化が起きました。

ストレージが安価になった: AWS S3やGoogle Cloud Storageは1GBあたり数円以下で利用できます。生データをそのまま保存してから変換するコストは、オンプレミス時代とは桁違いに低くなりました。「まず全量入れる」が現実的な選択肢になりました。
コンピュートが弾力的にスケール: BigQueryやSnowflakeはクエリ実行時にコンピュートリソースを自動スケールします。変換処理をDWH上で実行しても分析クエリを圧迫しない構成が可能になりました。
SQLベースの変換がDWH上で高速に実行可能: クラウドDWHのSQLエンジンは数百GBのデータに対しても数秒〜数分でクエリを完了します。Pythonで外部変換するより、DWH上のSQLの方が速い・安い・シンプルというケースが増えました。

この変化を受けて生まれたのが「モダンデータスタック」の概念です。ELTアーキテクチャの典型的な組み合わせは、Fivetran(EL部分) + dbt(T部分)、またはAirbyte(EL部分) + dbt(T部分)です。EL(抽出・格納)はSaaSコネクタに任せ、T(変換)はSQLとバージョン管理で行うという明確な役割分担が特徴です。

ELT vs ETL 徹底比較

比較軸	ETL	ELT
変換のタイミング	DWH格納前(外部サーバー)	DWH格納後(DWH上でSQL)
スキルセット	Python / Java / GUIツール操作	SQL中心(dbt)
スケーラビリティ	変換サーバーのスペックに依存	クラウドDWHが自動スケール
元データの保全性	変換後のみ保持(元データ消える)	raw層として全量保持可能
開発速度	遅い(ETLツールの習熟・テスト工数大)	速い(SQLとdbtで短サイクル)
コスト構造	ETLサーバー・ライセンスコスト	DWHのストレージ+クエリコスト
適するデータ量	小〜中規模(変換後の圧縮前提)	中〜大規模(raw全量保持が前提)
代表ツール	Informatica, Talend, SSIS	Fivetran/Airbyte + dbt
適する組織・ユースケース	法規制対応・個人情報マスキング必須環境	クラウドDWH中心のモダン構成

ELTが「正解」でないケース――ETLを選ぶべき例外

ELTはクラウド時代のデファクトですが、以下のケースではETLの方が適します。安易なELT一択は禁物です。

個人情報のマスキングが必要な場合: GDPRやPIPA等の規制により、氏名・メールアドレス等の個人情報をDWHに格納する前に匿名化・仮名化が義務づけられるケースがあります。この場合、DWHに生データを入れるELTはそもそも規制違反になりえます。
データ量が極端に多くコストが問題になる場合: IoTセンサーデータや高頻度ログデータは1日で数百GBに達することがあります。全量をDWHにロードすると、ストレージ・クエリコストが問題になります。ストリーミング層での前処理(Kafka + Flink等)でサマリーに絞ってからロードするアプローチが有効です。
非構造化データの前処理が必要な場合: 画像・動画・音声ファイルのメタデータ抽出、PDFからのテキスト抽出など、SQLで処理できない非構造化データの変換はETL(外部処理)が必要です。
レガシーシステムとの連携: 独自バイナリフォーマットや特殊なエンコーディングを持つレガシーシステムとの連携では、標準コネクタが存在せず、カスタム変換ロジック(Python/Java)が必要なケースがあります。

ETL/ELT 選定判断マトリクス

条件	ETL推奨	ELT推奨
個人情報をDWH格納前に匿名化する必要がある	✅	❌
クラウドDWH(BigQuery/Snowflake)を使用している	❌	✅
データエンジニアがSQLを主なスキルとしている	❌	✅
画像・音声・動画等の非構造化データが主体	✅	❌
データ量が1日1TB以上でコスト最適化が必須	△(前段フィルタ)	△(集計後ロード)
元データをすべて保持して後で再変換したい	❌	✅
レガシーDWH(オンプレ)環境を維持している	✅	△

モダンデータスタックにおけるELTの実装

ELTの典型的な実装構成は以下の通りです。EL(抽出・格納)はFivetran or Airbyteがコネクタを担当し、T(変換)はdbtがSQL+バージョン管理で担当します。オーケストレーションにはAirflowまたはDagsterが使われます。

Airbyte接続設定例(YAML)

source:
  name: PostgreSQL本番DB
  type: postgres
  host: db.example.com
  port: 5432
  database: mydb
  username: airbyte_user

dbtによる変換処理例(staging → marts)

-- models/staging/stg_orders.sql
SELECT
    id            AS order_id,
    customer_id,
    created_at,
    status,
    amount
FROM {{ source('raw', 'orders') }}
WHERE status NOT IN ('test', 'cancelled_before_process')

dbtはこのSQLをBigQuery/Snowflake上で実行し、stg_ordersビュー/テーブルを生成します。さらにintermediate層でJOINや集計を行い、最終的にmarts層でBI向けのファクト・ディメンションテーブルを生成するレイヤー構造(staging → intermediate → marts)を取ります。変換ロジックはすべてSQLファイルとしてGitで管理され、テスト・ドキュメント生成もdbtが担います。

オーケストレーション(Airflow/Dagster)は、Fivetranの同期完了後にdbt runを実行するDAGを管理します。これにより、ELTパイプライン全体が自動・スケジュール化されます。

まとめ――「まずELT、必要ならETLを追加」が現代のセオリー

クラウドDWH時代のデータ統合では、ELTをデフォルト選択肢とし、ETLが必要な例外ケースを見極める判断力が重要です。

ETLとELTの違いは「変換のタイミング」の一点に集約される
クラウドDWHの普及により、ELT(Fivetran/Airbyte + dbt)がモダン構成の標準となった
個人情報マスキング・非構造化データ処理・超大量データにはETLが適する
ELTはSQLスキルで変換でき、元データをraw層に保持できる柔軟性が強み
「まずELTで構築し、ETLが必要な処理だけ手前に追加」が現実的なアプローチ

次に読むべき関連記事: dbt入門(B-01) / Airbyte vs Fivetran(B-06) / CDC(A-19)

よくある質問(FAQ)

Q. ELTとETLのどちらを選ぶべきですか?

A. クラウドDWH(BigQuery/Snowflake等)を使うなら、まずELTが推奨です。ただし、DWH格納前に個人情報のマスキングが必要な場合や、非構造化データの前処理が必要な場合など、ETLが適するケースもあります。「条件によって使い分ける」が正確な答えです。

Q. ELTの「T」にはどのツールを使いますか?

A. dbtが最も普及しています。SQLでデータ変換を定義し、テスト・ドキュメント・バージョン管理を一体で行えるため、ELTアーキテクチャの標準ツールとなっています。クラウドDWH(BigQuery/Snowflake/Redshift)にネイティブ対応しており、学習コストも比較的低いのが特徴です。

Q. ETLからELTに移行する際の注意点は?

A. 既存のETL処理をそのままELTに移植するのではなく、「変換ロジックの整理」から始めることが重要です。不要な変換の排除、dbtでのモデル再設計(staging → intermediate → marts)を行うことで、移行後の保守性が大きく向上します。また、元データ(raw層)の保持ポリシーとストレージコストの試算も事前に行うことを推奨します。