Условие
Чем 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.
Подводные камни
- «Грузим всё, разберёмся потом» — типичный анти-паттерн ELT. Без модели данных raw превращается в свалку.
- Бизнес-логика в дашбордах. Аналитики копируют один и тот же SQL в 10 дашбордов; при изменении ломаются все. Решение — выносить логику в dbt-marts.
- Тесты данных обязательны. Без
dbt testETL и ELT — обе одинаково падают молча. - Cost surprises. ELT в Snowflake может стать дорого, если кто-то фитит ML-задачу через SQL. Лимиты и quotas обязательны.
Эталонный ответ
Современный стек — ELT + dbt: грузим raw в DWH (Snowflake/BigQuery/ClickHouse), трансформации пишем SQL-моделями с тестами. Преимущества: единая точка правды, легко переиграть, аналитики сами правят бизнес-логику. ETL остаётся для стримов с предагрегацией и регуляторных кейсов с обязательной анонимизацией до записи в DWH.