ETL — что это и зачем аналитику данных
Что такое ETL
ETL (Extract, Transform, Load) — процесс переноса данных из источников в хранилище. Три шага: извлечь данные из исходных систем, преобразовать их в нужный формат и загрузить в целевое хранилище.
Без ETL данные разбросаны по десяткам систем: CRM, биллинг, аналитика, логи серверов, внешние API. Аналитик не может писать SQL-запросы к каждой системе по отдельности — нужна единая точка, где данные собраны, очищены и готовы к анализу.
Три шага ETL
Extract — извлечение
Забираем данные из источников: продуктовая база данных, API платёжного провайдера, лог-файлы, Google Sheets, внешние сервисы аналитики. Извлечение может быть полным (каждый раз тянем всю таблицу) или инкрементальным (только новые и изменённые записи).
Transform — преобразование
Приводим данные в порядок: убираем дубли, заполняем или обрабатываем NULL, приводим типы (строку «2026-04-09» в дату), объединяем данные из разных источников по ключам, считаем агрегаты. Здесь рождаются «чистые» таблицы — facts и dimensions, с которыми потом работает аналитик.
Практический пример: из таблицы сырых событий raw_events (event_name, user_id, timestamp, properties JSON) получаем факт-таблицу fact_purchases с колонками user_id, purchase_date, amount, currency, utm_source. Из JSON вытащили нужные поля, отбросили тестовых пользователей, привели таймзоны к UTC.
Load — загрузка
Записываем результат в целевое хранилище: ClickHouse, PostgreSQL, BigQuery, Snowflake, Redshift. После загрузки данные доступны для дашбордов и ad-hoc аналитики.
Хранилище данных vs обычная база
Обычная (операционная) база данных оптимизирована для быстрых записей и чтения отдельных строк: оформить заказ, показать профиль пользователя. Хранилище данных (data warehouse) оптимизировано для аналитических запросов: агрегации по миллионам строк, JOIN-ы больших таблиц.
ETL — мост между этими мирами. Операционная БД обслуживает продукт, хранилище — аналитику. Они живут раздельно, чтобы аналитические запросы не замедляли продуктовую базу.
ETL vs ELT
Классический ETL преобразует данные до загрузки. Современный подход — ELT: сначала грузим сырые данные в хранилище, а трансформации запускаем уже внутри него SQL-запросами.
| ETL | ELT | |
|---|---|---|
| Порядок | Extract → Transform → Load | Extract → Load → Transform |
| Где трансформация | На отдельном сервере | В хранилище (SQL) |
| Когда подходит | Legacy-системы, сложные преобразования | Облачные DWH с мощными вычислениями |
| Инструменты | Airflow + Python-скрипты | dbt + Airflow |
ELT стал популярен с развитием облачных хранилищ (BigQuery, Snowflake), которые дёшево масштабируют вычисления. Трансформировать данные SQL-запросами внутри хранилища проще, чем писать скрипты на Python — и аналитик может менять логику трансформаций самостоятельно, без участия инженера.
Инструменты
- Apache Airflow — оркестратор: описывает DAG (граф зависимостей) задач, управляет расписанием и ретраями. Стандарт индустрии.
- dbt (data build tool) — трансформации в хранилище через SQL. Версионируется в Git, есть тесты данных. Идеален для ELT.
- Prefect — альтернатива Airflow, проще в настройке, Python-native.
- Luigi — оркестратор от Spotify, легковесный, но менее популярен.
- cron + Python-скрипты — минимальный вариант. Работает, пока пайплайнов мало. С ростом становится хрупким.
Зачем аналитику знать про ETL
Аналитик обычно не строит пайплайны, но работает с их результатами каждый день. Вот что важно понимать:
Свежесть данных. Если ETL запускается раз в сутки в 3:00, то данные за сегодня появятся в хранилище только завтра. Когда менеджер просит «дашборд с данными за сегодня» — нужно объяснить, почему это невозможно (или запросить изменение расписания пайплайна).
Качество данных. NULL в колонке revenue может означать «покупка бесплатная» или «ETL сломался и не вытащил значение». Аналитик, который понимает пайплайн, быстрее найдёт причину.
Запросы на изменения. Нужна новая колонка в факт-таблице? Нужно добавить источник данных? Аналитик, который понимает ETL, сформулирует запрос data-инженеру на языке, который тот поймёт — с указанием источника, логики трансформации и целевой таблицы.
Типичные ошибки
Не проверяют свежесть данных
Аналитик строит отчёт за вчера, а ETL упал и данные за вчера не загрузились. Отчёт показывает нули или неполные цифры. Совет: всегда проверяйте MAX(created_at) перед анализом.
Игнорируют NULL из-за багов ETL
Сырой источник возвращает пустую строку, ETL конвертирует её в NULL. Аналитик фильтрует WHERE amount > 0 — и теряет записи, где amount IS NULL. В итоге занижены метрики. Правильно: явно обрабатывать NULL через COALESCE или IS NOT NULL.
Не учитывают дубликаты
ETL перезапустился и загрузил часть данных дважды. Если в факт-таблице нет дедупликации, аналитик получит раздутые метрики. Привычка проверять COUNT(*) vs COUNT(DISTINCT id) помогает ловить такие проблемы.
Что спрашивают на собеседованиях
- Что такое ETL и из каких шагов состоит? — Extract (извлечение из источников), Transform (очистка и преобразование), Load (загрузка в хранилище). Упомяните, зачем каждый шаг нужен.
- В чём разница между ETL и ELT? — порядок шагов. ELT грузит сырые данные в хранилище и трансформирует там. Популярен с облачными DWH.
- Какие инструменты ETL знаете? — Airflow (оркестрация), dbt (трансформации SQL), Prefect, Luigi. Назовите хотя бы два и объясните разницу.
- Данные в дашборде выглядят некорректно. Как будете разбираться? — проверить свежесть данных (когда последний раз отработал ETL), проверить на дубли, проверить NULL, сверить с источником.
- Зачем нужно хранилище данных, если есть продуктовая база? — разделение нагрузки. Аналитические запросы тяжёлые и могут замедлить продуктовую базу. Хранилище оптимизировано для агрегаций.
Потренировать вопросы по SQL и продуктовой аналитике можно в Telegram — откройте тренажёр. Больше примеров на странице примеров вопросов.
Читайте также
- Что такое база данных
- SQL для аналитика
- ClickHouse vs PostgreSQL для аналитика
- Примеры вопросов с собеседований
FAQ
Нужно ли аналитику уметь писать ETL-пайплайны?
Зависит от компании. В стартапе аналитик может сам написать простой пайплайн на Python + cron. В крупной компании этим занимаются data-инженеры. Но понимать, как устроен пайплайн — нужно везде: это помогает находить проблемы с данными и грамотно ставить задачи инженерам.
Что такое DAG в контексте ETL?
DAG (Directed Acyclic Graph) — граф зависимостей между задачами. Например: «сначала выгрузи данные из CRM, потом объедини с данными биллинга, потом загрузи в хранилище». Airflow и другие оркестраторы описывают пайплайны именно как DAG.
Как часто запускают ETL?
Зависит от потребностей бизнеса. Классика — раз в сутки (ночью). Для real-time аналитики используют стриминг (Kafka, Flink), но это уже не совсем ETL в традиционном смысле. Большинство аналитических команд работают с данными, обновлёнными раз в сутки или раз в час.
Что будет, если ETL сломается?
Данные перестанут обновляться в хранилище. Дашборды покажут устаревшие цифры. Если пайплайн идемпотентный (можно перезапустить без дублирования) — достаточно перезапуска. Если нет — нужна ручная чистка. Поэтому хорошие пайплайны всегда идемпотентны и имеют мониторинг с алертами.