ETL и ELT: в чём разница простыми словами

Коротко: ETL и ELT — два порядка одних и тех же трёх шагов: извлечь данные (Extract), преобразовать (Transform), загрузить (Load). В ETL трансформация идёт до загрузки в хранилище, в ELT — уже внутри хранилища, силами самого DWH. Разница в одной переставленной букве, но она меняет всё: где живёт логика преобразований, кто её пишет и как быстро аналитик может её править. Современные колоночные хранилища (ClickHouse, Snowflake, BigQuery) достаточно мощные, чтобы гонять трансформации внутри себя, поэтому индустрия сместилась в сторону ELT.

Что такое ETL и что означает каждая буква?

ETL — это Extract, Transform, Load. Классический конвейер, который родился в эпоху дорогих хранилищ, когда за каждый гигабайт в аналитической БД платили ощутимые деньги, а вычислительные мощности были ограничены.

Разберём по буквам на примере интернет-магазина:

• Extract (извлечь). Забираем сырые данные из источников: транзакции из основной базы на PostgreSQL, логи событий, выгрузки из CRM, данные рекламных кабинетов. На этом шаге ничего не меняем — просто вытаскиваем.
• Transform (преобразовать). На промежуточном сервере (или в оперативной памяти ETL-инструмента) чистим данные: приводим типы, склеиваем таблицы, считаем агрегаты, отбрасываем дубли, нормализуем валюты. Наружу выходит уже причёсанная витрина.
• Load (загрузить). Готовую, преобразованную таблицу кладём в хранилище, откуда её читают дашборды и аналитики.

Ключевая идея ETL: в хранилище попадают только чистые, отобранные данные. Всё «грязное» преобразование происходит по дороге, на отдельном движке. Если хочешь пощупать сам этап трансформации на SQL, это ровно те запросы, что мы гоняем в SQL-тренажёре — JOIN, агрегаты, оконные функции.

Чем ELT отличается от ETL?

ELT — это Extract, Load, Transform. Те же три слова, но Transform и Load поменялись местами. И это не косметика.

В ELT мы сначала заливаем сырые данные в хранилище как есть, а уже потом преобразуем их внутри самого DWH обычными SQL-запросами. Промежуточный сервер для трансформаций не нужен — всю тяжёлую работу тянет хранилище.

Сравним подходы в лоб:

Простая аналогия. ETL — это когда ты приносишь домой уже нарезанный и вымытый салат из кулинарии: холодильник занят по минимуму, но если захотел другую нарезку — иди обратно в магазин. ELT — ты приносишь домой все сырые овощи и режешь как надо прямо на кухне: места в холодильнике уходит больше, зато любой рецепт собираешь на месте за минуту.

Почему современные DWH всё чаще выбирают ELT?

Несколько причин сошлись одновременно, и маятник качнулся в сторону ELT:

• Хранилища подешевели и разогнались. Колоночные аналитические БД считают агрегаты по миллиардам строк за секунды. Держать отдельный трансформационный движок стало незачем — DWH сам справляется.
• Сырьё стоит хранить. Если положить в хранилище только агрегаты, а завтра бизнес спросит новый разрез — данных для него уже нет, их выкинули на этапе Transform. В ELT сырьё лежит целиком, и любую новую витрину можно собрать задним числом, без перезаливки источников.
• Трансформации переехали на SQL. Раньше логику писали инженеры на языках вроде Python или Java внутри ETL-платформы. В ELT преобразования — это обычные SELECT, которые понимает и правит сам аналитик. Порог входа резко упал.
• Появился dbt. Инструмент, который превратил разрозненные SQL-скрипты в управляемый проект с версиями, тестами и зависимостями. dbt — это буква T в ELT, оформленная по-взрослому.

Итог: цикл «придумал метрику → написал SQL → увидел результат» в ELT занимает минуты, а не дни согласований с дата-инженерами. Для продуктовой аналитики, где гипотезы меняются каждую неделю, это решающий фактор. Подробнее про то, как dbt устроен на практике, — в разборе dbt для аналитика: первые шаги.

Как выглядит реальный пайплайн Postgres → ClickHouse → dbt?

Соберём типичный ELT-контур российской продуктовой команды. Источник — боевая база на PostgreSQL, хранилище — ClickHouse, трансформации — на dbt.

Шаг Extract + Load. Забираем таблицу заказов из Postgres и как есть льём в raw-слой ClickHouse. Часто это делает Airflow-таск или специализированный коннектор. Смысл — притащить сырьё без изменений:

-- Raw-слой в ClickHouse: копия таблицы из Postgres, без преобразований
CREATE TABLE raw.orders
(
    order_id      UInt64,
    user_id       UInt64,
    status        String,
    amount        Decimal(12, 2),
    currency      String,
    created_at    DateTime
)
ENGINE = MergeTree
ORDER BY (created_at, order_id);

Инкрементальную выгрузку из Postgres обычно делают по колонке created_at или по возрастающему id — тянут только новые строки с прошлого запуска. Как аккуратно догружать историю, если что-то пропустили, разобрано в статье про бэкфилл данных.

Шаг Transform. Теперь чистим и агрегируем — уже внутри ClickHouse, средствами dbt. Модель на SQL считает дневную витрину выручки, приводя валюты к рублям и отбрасывая отменённые заказы:

-- models/marts/daily_revenue.sql
{{ config(materialized='table') }}

WITH clean AS (
    SELECT
        toDate(created_at)                        AS dt,
        user_id,
        multiIf(
            currency = 'USD', amount * 92,
            currency = 'EUR', amount * 100,
            amount
        )                                          AS amount_rub
    FROM {{ source('raw', 'orders') }}
    WHERE status = 'paid'
)
SELECT
    dt,
    count(DISTINCT user_id)      AS paying_users,
    round(sum(amount_rub), 2)    AS revenue_rub,
    round(avg(amount_rub), 2)    AS avg_check_rub
FROM clean
GROUP BY dt
ORDER BY dt;

Витрина daily_revenue дальше идёт в дашборд. На её основе легко посчитать продуктовые метрики — например, ARPU как revenue_rub / paying_users или следить за DAU платящих пользователей. Проверить логику агрегатов и оконных функций перед тем, как оформлять в dbt-модель, удобно прямо в SQL-песочнице.

Иногда часть трансформации всё же выгодно сделать на Python — например, распарсить кривые JSON-логи или обучить простую модель скоринга перед загрузкой. Тогда получается гибрид: тяжёлую подготовку данных пишут на Python и обкатывают в Python-тренажёре, а бизнес-логику витрин оставляют на SQL в dbt.

Где аналитик встречает ETL, а где ELT?

На практике аналитик почти всегда работает с буквой T — с трансформациями. А вот где именно она стоит, зависит от зрелости команды:

• Чистый ELT (современный стек). Сырьё уже в хранилище, ты пишешь SQL-модели в dbt поверх него. Аналитик здесь фактически владеет всем слоем преобразований. Это самый частый расклад в продуктовых командах последних лет.
• Классический ETL (легаси и энтерпрайз). Данные приезжают в хранилище уже преобразованными через тяжёлую ETL-платформу. Аналитик пишет отчёты поверх готовых витрин, но не всегда может влезть в логику их сборки — это зона дата-инженеров.
• Гибрид (реальность большинства). Часть источников тянется по ELT, часть исторически осталась на ETL. Ты и SQL-модели правишь, и заявки инженерам на изменение старых пайплайнов пишешь.

Важно понимать: ELT не «отменил» ETL. Валидацию, дедупликацию, разбор вложенных структур всё равно кто-то делает — просто в ELT это делается SQL-запросами внутри хранилища, а не отдельным движком снаружи. Классические SQL-приёмы вроде дедупликации через ROW_NUMBER и оконных функций — это и есть тот самый Transform, только на языке аналитика.

Какие инструменты используют для ETL и ELT в РФ?

Стек в российских командах в 2026-м довольно устоявшийся. Разложу по этапам конвейера:

Хранилище (куда грузим).

• ClickHouse — де-факто стандарт для аналитики: колоночный, очень быстрый на агрегатах, отлично тянет ELT-нагрузку. Практический разбор — в гайде по ClickHouse для аналитика.
• PostgreSQL — часто и как источник (OLTP-база продукта), и как небольшое хранилище для витрин.
• Greenplum — там, где нужен MPP на больших объёмах в энтерпрайзе.

Оркестрация (кто запускает по расписанию).

• Apache Airflow — самый распространённый планировщик пайплайнов. DAG описывает порядок шагов: extract → load → dbt run → tests. Разбор рабочих паттернов — в статье про DAG-паттерны в Airflow.

Трансформация (буква T).

• dbt — стандарт для ELT-трансформаций на SQL: модели, тесты, документация, граф зависимостей.
• Собственные Python-скрипты для нестандартной подготовки данных.

Извлечение и загрузка (E и L).

• Коннекторы и самописные скрипты на Python, которые тянут данные из API, продуктовых БД и рекламных кабинетов.
• Потоковые сценарии на связке Kafka + ClickHouse, когда данные нужны почти в реальном времени.

Комбинаций много, но каркас почти всегда один: источник → сырой слой в ClickHouse → dbt-модели → дашборды. Знать названия инструментов полезно, но на собесе спросят не про кнопки, а про то, понимаешь ли ты логику.

Что выбрать под задачу: ETL или ELT?

Универсального ответа нет — выбор диктуют объёмы, стек и требования к данным. Несколько ориентиров:

• Если хранилище колоночное и мощное (ClickHouse, Snowflake), а гипотезы меняются часто — бери ELT. Сырьё в raw-слое плюс dbt-модели дают максимум гибкости.
• Если нужно жёстко ограничить, что попадает в хранилище (чувствительные данные, регуляторка), а объёмы предсказуемы — ETL с преобразованием «на подлёте» проще контролировать.
• Если данных немного и всё живёт в одном PostgreSQL — граница вообще размывается: E и L сливаются в один COPY, а T — это пара вьюх или materialized view.
• Если часть данных приходит потоком и нужна почти в реальном времени, ELT ложится естественнее: заливаешь события в ClickHouse, а витрины пересчитываешь materialized view поверх.

На практике команды редко выбирают идеологически чистый вариант. Чаще решают по каждому источнику отдельно: где-то дешевле дотрансформировать до загрузки, где-то — сложить сырьё и разобрать SQL уже внутри. Умение аргументировать этот выбор на конкретных цифрах — ровно то, что отличает сильного кандидата на собеседовании аналитика.

Что важно знать про ETL/ELT для собеседования?

Вопрос «в чём разница между ETL и ELT» — классика на собеседовании аналитика и дата-инженера. Вот что стоит уметь ответить чётко:

• Расшифровать буквы и назвать порядок. ETL: Extract → Transform → Load, преобразование до загрузки. ELT: Extract → Load → Transform, преобразование внутри хранилища. Это база, её ждут дословно.
• Объяснить, почему индустрия ушла в ELT. Дешёвые и мощные колоночные DWH, ценность хранения сырья, трансформации на SQL, появление dbt.
• Назвать минус ELT. Сырьё занимает больше места и вычисления грузят само хранилище — за это платишь ресурсами DWH. ELT не бесплатен, просто затраты сместились.
• Привести конкретный пример. «Тянем заказы из Postgres, льём сырьём в ClickHouse, витрины считаем dbt-моделями на SQL» — живой ответ ценится выше зазубренного определения.
• Не путать с ETL-инструментами. Airflow — это оркестратор (когда запускать), а не место, где живёт трансформация. dbt — это T, а не хранилище. Путаница здесь выдаёт новичка.

Мини-глоссарий, чтобы термины не плыли:

• DWH (Data Warehouse) — аналитическое хранилище данных, оптимизированное под чтение и агрегаты (ClickHouse, Snowflake, BigQuery).
• Raw-слой — таблицы с сырыми, непреобразованными данными как они пришли из источника.
• Витрина (data mart) — готовая агрегированная таблица под конкретную задачу или отчёт.
• Оркестратор — планировщик, который запускает шаги пайплайна по расписанию и следит за зависимостями (Airflow).
• Инкрементальная загрузка — догружаем только новые строки с прошлого запуска, а не всю таблицу целиком.
• Идемпотентность — свойство пайплайна давать один и тот же результат при повторном запуске, без задвоений.

Отработать эту тему живьём проще всего на практике. Первые пять задач в SQL-тренажёре и Python-тренажёре открыты бесплатно — этого достаточно, чтобы прочувствовать, как выглядит этап Transform на реальных данных; дальше задачи и разборы доступны в Pro. Если хочется сначала подтянуть базу SQL с нуля, загляни в курс по SQL, а прогнать вопрос про ETL/ELT в формате диалога можно в AI-интервьюере — он задаёт уточняющие вопросы ровно как настоящий интервьюер.

Разница между ETL и ELT — это не про моду и не про «какой инструмент круче». Это про то, где стоит буква T и кто ей управляет. В современном стеке ей всё чаще управляет аналитик — а значит, уверенный SQL и понимание, как данные превращаются в витрины, стоят дороже, чем знание любого конкретного инструмента. Хочешь проверить готовность к собесу целиком — собери связку из SQL с нуля и практики, и вопрос про ETL/ELT перестанет быть страшным.