21 апреля 2026 г.

ETL vs ELT: что выбрать

Карьерник — квиз-тренажёр в Telegram с 1500+ вопросами для собесов аналитика. SQL, Python, A/B, метрики. Бесплатно.

Короткий ответ

  • ETL = Extract → Transform → Load. Трансформируем данные до загрузки в DWH.
  • ELT = Extract → Load → Transform. Трансформируем после загрузки, уже в DWH.
  • ELT — современный подход, работает с облачными DWH (Snowflake, BigQuery, Redshift).
  • ETL — более старый, но всё ещё актуален для строгой регуляторики и on-premise.

Сравнительная таблица

Критерий ETL ELT
Порядок шагов Extract → Transform → Load Extract → Load → Transform
Где трансформируется В отдельном compute В DWH
Современный подход нет да
Сложность pipeline высокая средняя
Стоимость compute предсказуемая зависит от DWH
Хранение raw data нет да (data lake)
Инструменты Informatica, Talend, old Airflow dbt, modern SQL

Как работает ETL

Источник (Postgres, API, файлы)
  ↓ Extract (вытаскиваем)
Compute сервер (Airflow + Python)
  ↓ Transform (очищаем, агрегируем, джоиним)
DWH (загружаем уже готовое)

Пример: Python-скрипт из Airflow забирает JSON, парсит, чистит, джоинит с CSV, складывает результат в DWH-таблицу.

Как работает ELT

Источник (Postgres, API, файлы)
  ↓ Extract
Data Lake или staging-таблицы в DWH
  ↓ Load (сырые данные)
DWH (Snowflake, BigQuery)
  ↓ Transform (SQL-модели, dbt)
Финальные таблицы для аналитики

Пример: Fivetran-connector забирает сырые JSON из API в Snowflake. dbt запускает SQL-модели, которые очищают и агрегируют прямо в Snowflake.

Когда ETL

Плюсы ETL:

  • Не засоряется DWH сырыми данными
  • Контроль трансформаций до DWH (compliance)
  • Предсказуемый compute (знаем сколько стоит)
  • Подходит для on-premise без мощного DWH

Минусы ETL:

  • Сложный pipeline (отдельный ETL-tool + код)
  • Сырые данные теряются (сложно re-process)
  • Легаси-технологии (Informatica, Talend)
  • Медленная итерация (изменил логику → пересчитать весь pipeline)

Use cases:

  • Регулируемые отрасли (банки, healthcare)
  • On-premise инфраструктура
  • Малый объём данных

Когда ELT

Плюсы ELT:

  • Быстрая итерация (меняешь SQL → сразу результат)
  • Сырые данные всегда доступны (can re-process)
  • Простой stack (dbt + Snowflake / BigQuery)
  • Аналитики могут править трансформации сами (SQL, а не Python)
  • Масштабируется с ростом данных (DWH эластичный)

Минусы ELT:

  • Зависимость от облачного DWH ($$$ на compute)
  • Можно накосячить и затолкать PII в raw таблицы
  • Нужна культура dbt / CI / тестирования

Use cases:

  • Стартапы и scale-up (быстрая итерация)
  • SaaS-продукты
  • Всё на облаке (Snowflake, BigQuery, Redshift)
  • Большие объёмы данных

Современный аналитик

В 2026 году вероятнее всего вы работаете с ELT. Типичный стек:

  • Extract + Load: Fivetran, Airbyte (сам коннектор)
  • Store: Snowflake / BigQuery / ClickHouse
  • Transform: dbt (SQL-модели с тестами)
  • Orchestration: Airflow (минимально, для расписания dbt run)
  • BI: Metabase, Looker, Tableau

Аналитик пишет dbt-модели (SQL + jinja), не Python-ETL.

Пример: ETL на Python vs ELT на dbt

ETL на Python

import pandas as pd
from sqlalchemy import create_engine

# Extract
df = pd.read_sql("SELECT * FROM orders", source_db)

# Transform
df['revenue_rub'] = df['revenue_usd'] * 90
df_agg = df.groupby('category').agg(rev=('revenue_rub', 'sum'))

# Load
df_agg.to_sql('revenue_by_category', dwh_engine)

ELT на dbt

-- models/revenue_by_category.sql
SELECT
    category,
    SUM(revenue_usd * 90) AS revenue_rub
FROM {{ ref('stg_orders') }}
GROUP BY category

dbt автоматически создаст таблицу revenue_by_category в DWH.

Проблемы ELT

Несмотря на тренд, у ELT есть слабости:

Cost explosion

Если забыть ограничить compute на DWH — счета улетают в тысячи долларов. Решение: dbt incremental models, partitioning, good warehouse sizing.

Data swamp

«Загрузим всё сырое, разберёмся потом» → через 2 года сотни таблиц, никто не знает что актуально. Решение: data catalog, naming conventions.

PII в raw слоях

Raw-данные могут содержать персональные данные. Нужны процессы masking / row-level security.

Частые ошибки

Ошибка 1. Выбирать по моде, а не по задаче

ELT крут, но если у вас 10 GB данных на on-premise Postgres — ETL на Python проще и дешевле.

Ошибка 2. ETL без версионирования

Старые ETL-tools не всегда дружат с git. Если логика в GUI — нет ревью, нет rollback.

Ошибка 3. ELT без тестов

dbt позволяет писать тесты данных. Не ленитесь — они ловят проблемы раньше, чем stakeholders.

Ошибка 4. ETL/ELT = весь data engineering

Это только часть. Нужны orchestration, monitoring, alerting, catalog, lineage.

Связанные темы

FAQ

ETL или ELT в 2026?

ELT, если у вас облачный DWH. ETL всё ещё живёт в enterprise / on-premise.

Можно ли смешивать?

Да: reverse-ETL берёт из DWH и пишет в SaaS (операционные системы). EtLT (extract-tiny-transform-load-transform) — лёгкая очистка на extract.

dbt это ELT или ETL?

ELT. dbt трансформирует в DWH с помощью SQL.

Что учить аналитику?

В первую очередь — dbt + SQL для ELT. ETL-концепции на уровне понимания.

Тренируйте data engineering — откройте тренажёр с 1500+ вопросами для собесов.

Тренироваться в Telegram