ETL и ELT: как работают конвейеры данных
Основы3 минРедакция Innovialabs
Коротко
ETL сначала преобразует данные, а потом загружает их в хранилище, ELT — сначала загружает сырые данные, а преобразует уже внутри хранилища. Для облачных DWH чаще выбирают ELT, потому что вычисления там дешёвые и масштабируемые.
Коротко о разнице
Конвейер данных (data pipeline) — это автоматический процесс, который забирает данные из источников и доставляет их туда, где их анализируют. Он состоит из трёх шагов:
- Extract — извлечь данные из CRM, базы приложения, API рекламных систем, файлов.
- Transform — очистить, привести типы, убрать дубли, соединить таблицы, посчитать метрики.
- Load — записать результат в хранилище данных.
Разница между подходами — в порядке шагов:
- ETL: извлекли → преобразовали на отдельном сервере → загрузили готовое.
- ELT: извлекли → загрузили как есть → преобразовали SQL-запросами внутри хранилища.
Как устроен каждый этап
Extract. Данные забирают полностью (full load) или только изменения с прошлого запуска (incremental). Инкрементальная загрузка быстрее, но требует надёжного признака изменений: поля updated_at, автоинкрементного ID или журнала изменений базы (CDC).
Transform. Здесь появляется бизнес-логика: что считать активным клиентом, как пересчитать валюты, как связать заявку с оплатой. Именно этот этап чаще всего ломается и требует тестов.
Load. Данные дописывают, перезаписывают целиком или обновляют по ключу (upsert). Важно, чтобы повторный запуск не создавал дублей — это называют идемпотентностью.
Почему облачные хранилища выбрали ELT
Раньше хранилища были дорогими и медленными, поэтому данные готовили заранее на отдельном ETL-сервере и загружали только нужное. Облачные колоночные хранилища вроде BigQuery, Snowflake и ClickHouse изменили расчёт:
- Вычисления масштабируются — тяжёлое преобразование выполняется внутри DWH быстрее, чем на отдельной машине.
- Сырые данные сохраняются — если логика расчёта изменилась, витрины можно пересобрать без повторной выгрузки из источников.
- Трансформации — это SQL — их могут писать и проверять аналитики, а не только инженеры.
- Проще подключать источники — загрузка становится типовой задачей для готовых коннекторов.
ETL при этом не устарел. Он уместен, когда данные нужно очистить до загрузки: убрать персональные данные, которые нельзя хранить в DWH, или сильно сократить объём перед отправкой.
Инструменты
| Инструмент | Роль | Где используется |
|---|---|---|
| Airbyte | Готовые коннекторы для извлечения и загрузки (E и L) | ELT: перенос данных из сотен источников в хранилище |
| dbt | Трансформации в виде SQL-моделей с тестами, документацией и зависимостями (T) | ELT: слой преобразований внутри DWH |
| Apache Airflow | Оркестратор: запускает задачи по расписанию, следит за порядком и повторами | И ETL, и ELT: управляет всем конвейером |
Типичная связка ELT: Airbyte загружает сырые таблицы, dbt строит из них витрины, Airflow запускает оба шага в нужном порядке и сообщает об ошибках.
Пример модели dbt — это обычный SQL-файл:
-- models/marts/revenue_by_day.sql
SELECT
DATE(paid_at) AS day,
SUM(amount) AS revenue
FROM {{ ref('stg_payments') }}
WHERE status = 'paid'
GROUP BY 1
Как выбрать подход
- Облачный DWH и типовые источники — ELT с готовыми коннекторами.
- Строгие требования к персональным данным — ETL или ELT с маскированием на этапе загрузки.
- Пара источников и небольшой объём — достаточно скрипта по расписанию, Airflow можно добавить позже.
Частые ошибки: нет мониторинга, и конвейер молча падает на неделю; бизнес-логика размазана по скриптам без тестов; нет повторяемости запусков, и после сбоя появляются дубли.