ETL / интеграция данных
Extract, Transform, Load — процесс переноса данных из систем-источников в аналитическое хранилище с очисткой и приведением к единой модели.
Что такое ETL
ETL — процесс регулярного переноса данных из систем-источников (CRM, биллинг, логи, базы данных приложений) в аналитическое хранилище. Расшифровка аббревиатуры:
- Extract — вычитать данные из источника: SQL-запрос к реплике, дамп таблицы, вызов REST API, чтение файлов из хранилища.
- Transform — привести к единому виду: типы, часовые пояса, дедупликация, джойны справочников, расчёт метрик.
- Load — записать результат в целевую таблицу.
«Интеграция данных» — зонтичный термин пошире: ETL, ELT, CDC, репликация и потоковая доставка через Kafka — всё это её варианты.
ETL vs ELT
Отличие в одном: где выполняется трансформация — на отдельном сервере или внутри самого хранилища.
| ETL | ELT | |
|---|---|---|
| Где трансформация | Отдельный движок (Spark, Python) | Внутри DWH, на SQL |
| Порядок шагов | Extract → Transform → Load | Extract → Load → Transform |
| Что лежит в хранилище | Только готовые витрины | Сырые данные + витрины |
| Кто пишет логику | Инженер данных | Аналитик на SQL (dbt) |
| Пересчёт задним числом | Выкачивать источник заново | Сырое уже лежит в DWH |
| Типично для | Informatica, legacy-стек | ClickHouse, Greenplum, Snowflake |
ELT побеждает там, где хранилище само по себе — мощный распределённый движок: гонять терабайты наружу ради трансформации бессмысленно, если ClickHouse или Greenplum посчитают то же самое на месте. ETL остаётся оправданным, когда трансформация не выражается в SQL (парсинг, обогащение через внешний API) или когда сырые данные нельзя класть в хранилище по требованиям безопасности.
CDC и Debezium
CDC (Change Data Capture, захват изменений) — способ забирать из источника не всю таблицу, а только изменившиеся строки. Вместо ночного SELECT * по 200 млн строк читается журнал транзакций СУБД: WAL в PostgreSQL, binlog в MySQL, oplog в MongoDB.
Debezium — самый распространённый open-source CDC-инструмент. Подключается к журналу источника и публикует каждый INSERT/UPDATE/DELETE отдельным сообщением в Kafka:
PostgreSQL (WAL) → Debezium connector → Kafka topic → консьюмер → DWH
Что это даёт на практике: нагрузка на боевую БД почти нулевая (чтение журнала вместо полного скана), задержка падает с часов до секунд, а удаления не теряются — при выгрузке через SELECT удалённая строка просто исчезает, и в хранилище она остаётся навсегда.
Подводные камни: логическая репликация в PostgreSQL требует wal_level = logical и слота репликации, а забытый слот при отставшем консьюмере не даёт чистить WAL — диск источника заполняется до отказа.
Инструменты
| Инструмент | Роль |
|---|---|
| Airflow, Dagster, Prefect | Оркестрация: расписание, зависимости, ретраи |
| dbt | Трансформации на SQL внутри DWH (буква T в ELT) |
| Spark | Тяжёлые распределённые трансформации |
| Debezium | CDC из журнала транзакций |
| Kafka | Транспорт и буфер между источником и приёмником |
| Airbyte, Meltano | Готовые коннекторы к сотням источников |
Оркестратор не обрабатывает данные сам — он запускает задачи и следит за порядком. Airflow, гоняющий гигабайты через собственную память, — классическая ошибка проектирования.
Инфраструктура
Пайплайны — нагрузка пиковая и ночная: 3–4 часа расчёта, потом простой. Отсюда практика: воркеры Spark и Airflow держат на spot-инстансах, сырой слой складывают в object storage вместо дорогих дисков хранилища, а сам ETL-сервер ставят в одной сети с DWH — трансформация упирается в сеть чаще, чем в CPU.
Связанные термины
- DWH / хранилища данных — куда ETL складывает результат
- Kafka — транспорт для CDC и потоковой интеграции
- Hadoop / Spark / Hive — движок для тяжёлых трансформаций
- ClickHouse — типичный приёмник ELT-схемы
- OLAP — режим, ради которого данные и собирают
- Парсинг — извлечение данных из неструктурированных источников
Готовы запустить GPU-задачу?
Запустить GPU-сервер