Собесов

OBenner/data-engineering: ETL vs ELT

Кейсы и метрикиData EngineeringСредняяMiddle

Условие

Чем ETL отличается от ELT? Что выбрать для современного DWH и почему?

Решение

Подход

ETL (Extract → Transform → Load).

Классическая схема: данные вытащили из источника, преобразовали на промежуточном слое (Talend, Informatica, Spark-job, Python), сложили в DWH уже в финальной структуре. Это удобно, когда DWH дорог и медленный, а ETL-движок мощный.

ELT (Extract → Load → Transform).

Современная схема: данные грузим в DWH (Snowflake, BigQuery, Redshift, ClickHouse) «как есть», а трансформации делаем внутри DWH через SQL (часто через dbt). DWH сейчас дешевы и быстры — почему бы не использовать.

Сравнение.

Аспект ETL ELT
Где трансформации На отдельном движке В DWH (SQL)
Хранится ли raw Часто нет Да (raw + staging + marts)
Реплей и аудит Сложно Просто (есть raw)
Стек Сложный (Spark, Airflow, Python) Простой (dbt + SQL)
Кто пишет Data engineer Analytics engineer / аналитик
Стоимость DWH Низкая Выше (там идут трансформации)
Подходит для Узкие пайплайны, legacy DWH Современный облачный DWH

Современный подход: ELT + dbt.

sources (raw)
  └─→ staging  (мелкие правки типов, ребрендинг колонок)
      └─→ intermediate  (joins, основная бизнес-логика)
          └─→ marts  (готовые таблицы для дашбордов и ML)

dbt позволяет писать каждый шаг как SQL-модель с тестами (unique, not_null, relationships) и ref()-связями.

-- models/marts/dim_users.sql
{{ config(materialized='table') }}
 
SELECT
    u.user_id,
    u.email,
    COUNT(o.order_id)                AS total_orders,
    SUM(o.amount)                    AS lifetime_revenue,
    MAX(o.order_date)::date          AS last_order_date
FROM {{ ref('stg_users') }} u
LEFT JOIN {{ ref('stg_orders') }} o ON o.user_id = u.user_id
GROUP BY u.user_id, u.email

Когда всё ещё ETL.

  • Источник стримит данные, и их нельзя дешево загнать в DWH в сыром виде (Kafka → Spark Streaming → DWH с предагрегацией).
  • Регуляторика требует анонимизации до записи в DWH (PII compliance).
  • DWH on-prem с лимитами на compute.

Подводные камни

  1. «Грузим всё, разберёмся потом» — типичный анти-паттерн ELT. Без модели данных raw превращается в свалку.
  2. Бизнес-логика в дашбордах. Аналитики копируют один и тот же SQL в 10 дашбордов; при изменении ломаются все. Решение — выносить логику в dbt-marts.
  3. Тесты данных обязательны. Без dbt test ETL и ELT — обе одинаково падают молча.
  4. Cost surprises. ELT в Snowflake может стать дорого, если кто-то фитит ML-задачу через SQL. Лимиты и quotas обязательны.

Эталонный ответ

Современный стек — ELT + dbt: грузим raw в DWH (Snowflake/BigQuery/ClickHouse), трансформации пишем SQL-моделями с тестами. Преимущества: единая точка правды, легко переиграть, аналитики сами правят бизнес-логику. ETL остаётся для стримов с предагрегацией и регуляторных кейсов с обязательной анонимизацией до записи в DWH.

Хочешь увидеть разбор?

Зарегистрируйся бесплатно — откроется развёрнутое решение этой задачи и ещё 4 на выбор.

Зарегистрироваться и увидеть разбор
Уже есть аккаунт? Войти