ETL: что это, как работает и чем отличается от ELT

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

Он даёт один повторяемый маршрут для данных из разных систем. Благодаря этому отчёты меньше спорят друг с другом, а аналитика не зависит от ручной чистки перед каждой новой выгрузкой. А когда данные разошлись, команда быстрее находит причину: маршрут один, и видно, где он сломался.

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

Источники падают, присылают исправления и меняют прошлые периоды. Если поток нельзя повторить без дублей и ручной чистки, ему быстро перестают доверять. Поэтому безопасный rerun — часть зрелого ETL, а не приятный бонус. Иначе каждая авария заканчивается ручным ремонтом витрины.

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

Лучше взять один небольшой источник и провести его до целевой таблицы целиком. На таком примере быстрее видно, как работают ключи, дубли, проверки, инкрементальная загрузка и повторный запуск. После этого уже проще разбирать журналы и историю пересчёта.

При полной загрузке пайплайн каждый раз перечитывает источник целиком и перезаписывает таблицу — просто, но дорого на больших объёмах. Инкрементальная забирает только новые или изменённые строки: по полю updated_at, по автоинкрементному id или через CDC. На практике полную загрузку оставляют для маленьких справочников, а факты грузят инкрементально.

CDC — способ ловить изменения в источнике не запросами по расписанию, а чтением журнала транзакций базы: INSERT, UPDATE и DELETE прилетают почти в реальном времени. Так работает Debezium поверх PostgreSQL или MySQL. CDC берут, когда бизнесу нужны свежие данные быстрее, чем раз в час, или когда источник нельзя нагружать тяжёлыми SELECT.

Batch обрабатывает данные пачками по расписанию — раз в час, раз в ночь. Streaming (Kafka, Flink, Spark Structured Streaming) тянет события непрерывно, с задержкой в секунды. Для отчётности и витрин почти всегда хватает batch: он дешевле и проще в отладке. Streaming нужен антифроду, рекомендациям и мониторингу — там, где решение принимают по свежим событиям.

Минимальный набор: строки не потерялись (сверка count источника и приёмника), ключи уникальны, обязательные поля не пустые, значения в допустимых диапазонах, свежесть данных не старше SLA. Проверки вешают после каждого шага: упавший тест останавливает пайплайн раньше, чем битые цифры доедут до дашборда. Инструменты — dbt tests, Great Expectations, Soda.

SCD — приёмы хранения справочников, которые меняются со временем: клиент переехал, товар сменил категорию. SCD1 просто перезаписывает старое значение, SCD2 заводит новую версию строки с датами действия — так сохраняется история, и отчёт за прошлый год считается по тогдашним атрибутам. На собеседованиях по DWH про SCD2 спрашивают почти всегда.

Staging — буфер, куда сырые данные падают как есть, без трансформаций. Он развязывает извлечение и обработку: если трансформация упала, не нужно заново дёргать источник — всё уже лежит в staging. Плюс это точка для сверки с источником и для перезапуска пайплайна с середины, а не с нуля.

Airflow описывает пайплайн как DAG на Python: какие шаги, в каком порядке, что делать при падении. Он запускает задачи по расписанию, ретраит упавшие, показывает историю запусков и шлёт алерты. В московском IT-срезе Airflow — один из самых частых соседей ETL в вакансиях, и связка с ним усиливает оффер.

Ядро стека: Airflow для оркестрации, dbt для трансформаций в хранилище, Spark для тяжёлых объёмов. В enterprise живут SSIS (мир Microsoft) и NiFi (потоковая маршрутизация данных). Плюс коннекторы вроде Airbyte для извлечения. Учить всё сразу не нужно: SQL + Python + Airflow закрывают большинство требований вакансий.

dbt делает только букву T: он трансформирует данные, которые уже лежат в хранилище, через SQL-модели. Извлечение и загрузку он не берёт — их закрывают Airbyte, Fivetran или самописные скрипты. Поэтому dbt — инструмент ELT-подхода: сначала данные загружают как есть, потом dbt строит из них чистые слои и витрины.

Pandas обрабатывает данные в памяти одной машины — до нескольких гигабайт это самый быстрый путь: меньше кода, проще отладка. Spark распределяет работу по кластеру и нужен, когда данные в память не влезают — десятки гигабайт и дальше. Практичное правило: начинайте с pandas или Polars, на Spark переходите по факту роста объёмов, а не заранее.

Дата-инженер строит и сопровождает пайплайны — для него ETL основная работа. Аналитику ETL нужен на уровне понимания: откуда пришли данные, где они могли испортиться, почему цифры в витрине разошлись с источником. В московском IT-срезе ETL чаще всего встречается в вакансиях инженеров данных, реже — у аналитиков данных и BI-аналитиков.

DWH — общее хранилище со всеми данными компании, витрина (data mart) — его срез под конкретную команду или задачу: продажи, маркетинг, финансы. В витрине данные уже агрегированы и названы бизнес-терминами, поэтому дашборды поверх неё работают быстро и не требуют джойнов по десяти таблицам. ETL-пайплайн обычно заканчивается именно витриной.

Идемпотентный пайплайн можно запустить повторно на тех же данных — и результат не задвоится. Достигается перезаписью партиций за период, MERGE по ключу или очисткой целевого диапазона перед вставкой. Без этого каждый ретрай после сбоя плодит дубли, и цифры в отчётах едут. Это один из первых вопросов на собеседовании по ETL.

Три уровня. Технический: задача завершилась, время работы в норме — это даёт Airflow с алертами в Slack или Telegram. Данные: свежесть таблиц, объёмы, доля пустых значений — data quality тесты. Бизнес: выручка в витрине не упала в ноль за ночь. Хороший пайплайн падает громко и сразу, а не молча грузит мусор неделями.

Юнит-тесты покрывают функции трансформаций на синтетических данных: подали кривую строку — получили ожидаемый результат. Тесты данных (dbt tests, Great Expectations) проверяют сами таблицы: уникальность, ссылочную целостность, свежесть. Перед релизом гоняют пайплайн на копии прода и сверяют витрины до и после. Тестов на данные обычно нужно больше, чем на код.

Зарплату определяют роль и грейд, но медиана в вакансиях с ETL — одна из самых высоких на рынке. Связка с Airflow прибавляет к офферу. Junior-позиций мало, рынок ждёт людей с опытом, зато спрос стабильно растёт. Актуальные цифры — в рыночном блоке этой страницы.

В крупных компаниях половина источников — учётные системы: 1С, SAP, самописные CRM. Данные оттуда забирают через выгрузки, OData или репликацию в промежуточную базу, затем чистят и складывают в DWH. Специфика — кривые справочники, ручные правки задним числом и регламентные окна, когда источник трогать нельзя. Здесь же дольше всего живут SSIS и Informatica.

Рабочая траектория: SQL до уверенных джойнов и оконных функций, Python для скриптов, потом Airflow и один учебный пайплайн от API до витрины с дашбордом. Частый вход — из аналитики, поддержки БД или бэкенда: там уже есть половина стека. В вакансиях рядом с ETL SQL стоит в 85% случаев, Python — в 74%, так что эта пара обязательна.

Обычный ETL везёт данные из рабочих систем в хранилище. Reverse ETL двигает их обратно: сегменты клиентов из DWH уезжают в CRM, рекламные кабинеты и рассылки, чтобы менеджеры и маркетинг работали с теми же цифрами, что и аналитики. Инструменты — Hightouch, Census; локальные команды чаще пишут свои коннекторы поверх API.