ETL vs ELT 2026年版:データパイプラインアーキテクチャの徹底解説と面接対策

ETLとELTの違い、アーキテクチャ、ユースケース、最新ツール、データエンジニア面接での頻出質問について解説します。

ETL vs ELT データパイプラインアーキテクチャ比較図

ETL vs ELTは、ソースシステムから分析環境へデータを移動する方法を定義します。抽出・変換・ロード(ETL)と抽出・ロード・変換(ELT)のどちらを選択するかは、インフラコスト、データの鮮度、エンジニアリングチームに求められるスキルに影響を与えます。

核心的な違い

ETLはターゲットシステムにロードする前にデータを変換するため、専用のコンピュートリソースが必要です。ELTは生データを先にロードし、その後、宛先ウェアハウスの処理能力を使用して変換を行います。2026年においてクラウドネイティブなデータスタックの多くがELTを採用する理由は、コンピュートがオンデマンドでスケールするためです。

ETLアーキテクチャ:ロード前に変換する

ETLは、データウェアハウスのコンピュート容量が限られており、ストレージが高価だった時代に登場しました。このパターンは理にかなっていました。ウェアハウスの外部でデータをフィルタリングおよび集計し、分析に必要なものだけをロードするという考え方です。Oracle Warehouse Builder、Informatica PowerCenter、Talendがこのモデルに基づいたツールを構築しました。

ETLの変換ステージは中間サーバー上で実行されます。データはソースからステージングエリアに移動し、クレンジングと整形が行われた後、宛先にロードされます。このアプローチはウェアハウスの負荷を軽減しますが、変換レイヤーにボトルネックを生み出します。

python
# etl_pipeline.py
# Traditional ETL pattern with intermediate transformation

import pandas as pd
from sqlalchemy import create_engine

def extract_from_source(connection_string: str, query: str) -> pd.DataFrame:
    """Pull data from source database."""
    engine = create_engine(connection_string)
    return pd.read_sql(query, engine)

def transform_data(df: pd.DataFrame) -> pd.DataFrame:
    """Clean and reshape data before loading.
    
    This runs on the ETL server, not the warehouse.
    """
    # Remove duplicates based on business key
    df = df.drop_duplicates(subset=['customer_id', 'order_date'])
    
    # Convert date strings to proper datetime
    df['order_date'] = pd.to_datetime(df['order_date'])
    
    # Calculate derived metrics
    df['order_total'] = df['quantity'] * df['unit_price']
    df['order_month'] = df['order_date'].dt.to_period('M')
    
    # Filter to relevant records only
    df = df[df['order_status'] != 'cancelled']
    
    return df

def load_to_warehouse(df: pd.DataFrame, warehouse_conn: str, table: str):
    """Load transformed data to destination."""
    engine = create_engine(warehouse_conn)
    df.to_sql(table, engine, if_exists='append', index=False)

# Pipeline execution
raw_orders = extract_from_source(SOURCE_CONN, "SELECT * FROM orders")
clean_orders = transform_data(raw_orders)
load_to_warehouse(clean_orders, WAREHOUSE_CONN, 'fact_orders')

ETLは、変換ロジックが安定しており、データ量が予測可能な場合にうまく機能します。欠点は要件が変更されたときに現れます。変換を修正するということは、履歴データを最初から再処理することを意味します。

ELTアーキテクチャ:先にロードし、ウェアハウス内で変換する

ELTは変換をデータウェアハウス内に移行します。Snowflake、BigQuery、Databricks、Redshiftは、クエリの複雑さに応じてスケールするほぼ無制限のコンピュートを提供します。生データを先にロードすることでソースの状態が保持され、変換はバージョン管理され、再抽出なしで再実行可能なSQLモデルになります。

dbt(data build tool)プロジェクトは、SQL変換をコードとして扱うことでELTを普及させました。ブラックボックスのETLジョブの代わりに、変換は生のテーブルを参照し、派生モデルを構築するSELECT文としてバージョン管理されます。

sql
-- models/staging/stg_orders.sql
-- dbt model: first transformation layer on raw data

with source as (
    -- Reference the raw table loaded by the extraction tool
    select * from {{ source('salesforce', 'orders') }}
),

renamed as (
    select
        id as order_id,
        customer_id,
        cast(order_date as date) as order_date,
        quantity,
        unit_price,
        order_status,
        -- Calculate derived fields in SQL
        quantity * unit_price as order_total,
        date_trunc('month', cast(order_date as date)) as order_month
    from source
    where order_status != 'cancelled'
)

select * from renamed
sql
-- models/marts/fct_monthly_revenue.sql
-- Aggregated fact table built from staging model

with orders as (
    select * from {{ ref('stg_orders') }}
),

monthly_agg as (
    select
        order_month,
        count(distinct customer_id) as unique_customers,
        count(order_id) as total_orders,
        sum(order_total) as revenue
    from orders
    group by order_month
)

select * from monthly_agg

ELTは生データを保持するため、ビジネスロジックが変更された場合の再処理が可能になります。6か月前の計算が間違っていた場合、dbtモデルを修正してフルリフレッシュを実行することで履歴データを修正できます。ETLの場合、同じ修正を行うには、元のレコードがもう存在しない可能性のあるソースから再抽出する必要があります。

比較表:ETL vs ELTのトレードオフ

要素ETLELT
コンピュート場所専用変換サーバー宛先ウェアハウス
生データ保持変換後に破棄されることが多いランディングゾーンに保持
再処理コストソースから再抽出SQLモデルを再実行
スキーマ柔軟性変換時に固定スキーマオンリードが可能
ツール例Informatica、Talend、SSISdbt、Dataform、SQLMesh
適した場面安定した要件、レガシーシステム変化する要件、クラウドウェアハウス
レイテンシ高い(ロード前に変換)低い(ロード後に変換)
データガバナンス容易(ウェアハウス前にフィルタリング)ウェアハウスレベルの制御が必要

Data Engineeringの面接対策はできていますか?

インタラクティブなシミュレーター、flashcards、技術テストで練習しましょう。

ハイブリッドアプローチ:ETLとELTの組み合わせ

現代のデータスタックは純粋なETLまたはELTを使用することは稀です。Apache Airflowは両方のパターンを組み合わせたパイプラインをオーケストレーションします。機密データはロード前に匿名化(ETLステップ)され、集計はウェアハウス内で実行(ELT)されることがあります。

FivetranやAirbyteは変換なしで生データを抽出してロードし、その後dbtがウェアハウス内で変換を行います。しかし、これらのツールは抽出時に軽量な変換もサポートしています:カラム選択、データ型の変換、PIIフィールドのハッシュ化などです。これがETL/ELTの境界を曖昧にしています。

yaml
# airflow/dags/hybrid_pipeline.py
# DAG combining extraction, lightweight ETL, and warehouse ELT

from airflow import DAG
from airflow.providers.airbyte.operators.airbyte import AirbyteTriggerSyncOperator
from airflow.providers.dbt.cloud.operators.dbt import DbtCloudRunJobOperator
from datetime import datetime

with DAG(
    dag_id='hybrid_etl_elt_pipeline',
    start_date=datetime(2026, 1, 1),
    schedule='@daily',
    catchup=False
) as dag:
    
    # Step 1: Extract and load with Airbyte
    # Minor transforms happen here: type casting, PII hashing
    sync_salesforce = AirbyteTriggerSyncOperator(
        task_id='sync_salesforce_orders',
        airbyte_conn_id='airbyte_default',
        connection_id='salesforce-to-snowflake',
        asynchronous=False
    )
    
    # Step 2: Transform in warehouse with dbt
    # Heavy aggregations, joins, business logic
    run_dbt_models = DbtCloudRunJobOperator(
        task_id='run_dbt_transformations',
        dbt_cloud_conn_id='dbt_cloud',
        job_id=12345,
        wait_for_termination=True
    )
    
    sync_salesforce >> run_dbt_models

上記のパイプラインはAirbyteでSalesforceから抽出し(同期中にメールアドレスをハッシュ化可能)、Snowflakeにロードし、その後ビジネス変換のためにdbtモデルを実行します。純粋なETLでも純粋なELTでもありませんが、実用的なアプローチです。

面接質問:データエンジニア向けETL vs ELT

現代のデータスタックを使用する企業のデータエンジニアリング職の技術面接では、パイプラインアーキテクチャの理解を探ります。ETL/ELT面接対策モジュールのパターンに基づき、これらの質問が頻繁に出題されます。

質問1:ELTよりETLを選択するのはどのような場合ですか?

優れた回答は具体的なシナリオを特定します:

  • コンプライアンス要件:GDPRやHIPAAにより、特定のデータは生の形式でウェアハウスに到達してはならないと義務付けられています。PIIはロード前に匿名化または削除する必要があります。
  • レガシーウェアハウスの制約:固定コンピュートを持つTeradataや古いRedshift構成などのオンプレミスシステムは、事前集計されたロードの恩恵を受けます。
  • ネットワークコスト:毎日10TBをクラウドウェアハウスにロードし、変換後に90%を破棄するのは、エグレス帯域幅の無駄です。事前フィルタリングは経済的に合理的です。

弱い回答は「ETLは時代遅れ」と言ったり、具体的なシナリオを提示できなかったりします。面接官はニュアンスを求めています。

質問2:ELTパイプラインでスキーマ変更をどのように処理しますか?

これは生データランディングゾーンの理解をテストします。期待されるトピック:

  • スキーママイグレーションなしで新しいフィールドを吸収するJSONまたは半構造化カラム
  • カラムを明示的に選択し、下流モデルをソース変更から分離するステージングモデル
  • 期待されるカラムが消失した場合にビルドを失敗させるdbtマクロまたはDataformアサーション
  • Monte CarloやGreat Expectationsなどのツールを使用したスキーマドリフトの監視
sql
-- Schema evolution handling in dbt
-- Use VARIANT/JSON columns to absorb unknown fields

with raw_events as (
    select
        event_id,
        event_payload,  -- JSON column from source
        received_at
    from {{ source('app', 'raw_events') }}
),

parsed as (
    select
        event_id,
        event_payload:user_id::string as user_id,
        event_payload:event_type::string as event_type,
        -- New fields appear in JSON without breaking the model
        event_payload:metadata::variant as metadata,
        received_at
    from raw_events
)

select * from parsed

質問3:AirflowでのETLオーケストレーションとdbtでのELT実行を比較してください

この質問は、これらのツールが異なる問題を解決することの理解を探ります:

  • Airflowはタスクをオーケストレーションします:抽出、API呼び出し、ファイル転送、モデル訓練。異種ジョブ間の依存関係を管理します。
  • dbtはウェアハウス内でデータを変換します。SQLモデル間の依存関係を管理し、テストを実行し、ドキュメントを生成します。

完全なパイプラインは両方を使用することが多いです:AirflowがAirbyte同期をトリガーし、完了を待ち、その後dbt実行をトリガーします。どのツールをいつ使用するかを知っていることが、シニア候補者を区別します。

質問4:ELTパイプラインが毎日5億行を処理し、アナリストがクエリの遅延を報告しています

このオープンエンドの質問は診断的思考をテストします:

  1. モデルのマテリアライゼーションを確認:重いモデルがまだビューですか?インクリメンタルモデルやテーブルが役立つかもしれません。
  2. パーティションとクラスタ:BigQueryの場合、ファクトテーブルは日付でパーティション化されていますか?Snowflakeの場合、一般的なクエリパターンに最適化されたクラスタリングですか?
  3. クエリプッシュダウン:アナリストは事前集計されたマートではなくステージングモデルをクエリしていますか?
  4. ウェアハウスサイズ:クエリ時間中にコンピュートは適切にスケールされていますか?
  5. 鮮度要件:変換を営業時間中ではなく夜間に実行できますか?

単一の正解はありません。面接官は体系的なトラブルシューティングを評価します。

2026年のツールランドスケープ

データ統合市場はいくつかのパターンに集約されています:

抽出とロード:Fivetran、Airbyte、Stitch、Meltanoは EL部分を処理します。これらのツールは数百のソースに接続し、カスタムコードなしでクラウドウェアハウスに同期します。

変換:dbtがSQLベースの変換を支配しています。代替としてDataform(現在Google Cloudの一部)、SQLMesh(仮想データ環境を持つオープンソース)、Coalesce(ビジュアルモデリング)があります。

オーケストレーション:Airflowは複雑なパイプラインのデフォルトとして残っています。DagsterとPrefectは、より良いローカル開発とアセット中心のビューを提供する代替手段です。

品質:Great Expectations、dbtテスト、Monte Carlo、Sodaがデータ品質監視を提供します。これらは抽出から下流消費までの間の問題を検出します。

python
# great_expectations checkpoint for ELT quality gates
# Runs after dbt completes, before downstream dashboards refresh

import great_expectations as gx

context = gx.get_context()

checkpoint = context.checkpoints.get("daily_orders_checkpoint")

result = checkpoint.run(
    batch_parameters={"year": 2026, "month": 9},
    expectation_suite_name="orders_suite"
)

if not result.success:
    # Block downstream refresh, alert data team
    raise ValueError(f"Data quality check failed: {result.describe()}")

今すぐ練習を始めましょう!

面接シミュレーターと技術テストで知識をテストしましょう。

新規プロジェクトのパイプラインアーキテクチャ選択

2026年のほとんどのグリーンフィールドプロジェクトでは、ELTがデフォルトです。クラウドウェアハウスのコンピュートは変換サーバーの維持よりも低コストです。生データの保持により遡及的な修正が可能になります。SQLベースの変換は監査可能でバージョン管理されています。

ETLが依然として有効な場面:

  • ウェアハウス入力前のデータ最小化を要求する規制環境
  • 取り込み時に変換が必要なリアルタイムストリーミング(Kafka Streams、Flink)
  • 下流ストレージが限られたエッジコンピューティングシナリオ
  • ソースシステムがエクスポート形式を制御するレガシー統合

面接に対応できる回答は、両方のパターンを認識し、イデオロギー的な偏りなしにトレードオフを説明します。

データパイプラインアーキテクチャの重要ポイント

  • ETLはロード前にデータを変換し、ウェアハウスの負荷を軽減しますが、ロジック変更時に再処理の摩擦を生み出します
  • ELTは生データを先にロードし、履歴データに対してバージョン管理、テスト、再実行可能なSQLベースの変換を可能にします
  • 現代のスタックは通常、両方を組み合わせます:軽量な抽出変換(PIIハッシュ化、型変換)とウェアハウスベースの集計
  • dbtはELT変換の標準となり、SQLモデルをテスト可能でドキュメント化されたコードとして扱います
  • 面接質問は、定型的な定義ではなく、シナリオ選択、スキーマ進化処理、ツールのトレードオフを探ります
  • ELTパイプラインでの生データ保持により、ソースから再抽出することなく履歴計算を修正できます
今日のチャレンジ

Data Engineering のバグを見つけられますか

実際のコード、隠れたバグ、1日1回。アカウントなしで試せます。

Anthony Fillion-Maillet

執筆

Anthony Fillion-Maillet

SharpSkill 創業者

10 年以上フルスタック開発に携わっています。SharpSkill を運営し、ここで公開される内容に責任を負っています。

2026年9月14日 更新

タグ

#etl
#elt
#データパイプライン
#dbt
#データエンジニアリング
#面接対策

共有

関連記事