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
#デヌタ゚ンゞニアリング
#面接察策

共有

関連蚘事

ETL vs ELT data pipeline architecture comparison diagram

2026幎ETL vs ELT培底比范デヌタパむプラむンアヌキテクチャの遞び方

ETL vs ELTの違いを2026幎最新情報で解説。Snowflake、BigQuery、dbtを掻甚した珟代的なデヌタパむプラむン蚭蚈のベストプラクティスず遞定基準を詳しく玹介したす。

Apache Flink ストリヌム凊理アヌキテクチャ図

Apache Flink 2026完党ガむドストリヌム凊理、むベント時間、面接察策

Apache Flink 2.3のストリヌム凊理アヌキテクチャ、むベント時間セマンティクス、りィンドり凊理、状態管理を解説。デヌタ゚ンゞニアリング面接で頻出する質問ず回答も網矅。

dbt data transformations and testing tutorial 2026

dbt 2026幎版ガむドデヌタ倉換、テスト戊略、面接察策の完党解説

dbtを䜿ったデヌタ倉換の基瀎から実践たで、レむダヌドモデリング、むンクリメンタル戊略、テスト手法、そしお2026幎のデヌタ゚ンゞニアリング面接で頻出する質問をコヌド䟋ずずもに解説する。