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

Этот урок про ETL — старший брат. Он появился раньше и до сих пор работает в десятках тысяч компаний.

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

ETL расшифровывается как Extract, Transform, Load — извлечь, преобразовать, загрузить. Это три фазы пайплайна, выполняющиеся строго в этом порядке:

Подробнее по шагам:

• Extract — выгрузка данных из источника. Источник может быть чем угодно: OLTP-база, REST API, CSV-файл, очередь сообщений, FTP-сервер. Задача — забрать данные, не нагружая источник насмерть.
• Transform — преобразование данных в формат, который ожидает целевая система. Тут чистят дубли, приводят типы, нормализуют справочники, считают агрегаты, применяют бизнес-правила. Происходит это на промежуточном сервере — отдельной машине или кластере с ETL-движком.
• Load — загрузка готового результата в целевое хранилище. Чаще всего в DWH или OLAP-куб, иногда в operational data store или витрину.

Ключевая идея: в хранилище попадают только обработанные данные. Если что-то отфильтровали или агрегировали — в DWH исходного значения уже нет. Это и преимущество, и ограничение одновременно.

Почему ETL появился именно таким

Чтобы понять ETL, нужно вспомнить, в каком мире он родился. Конец 1980-х и 1990-е годы. Хранилища данных тогда строили на дорогих on-premise серверах: Teradata, Oracle Exadata, IBM DB2, Netezza. Эти железки умели быстро читать и считать аналитику, но имели две особенности:

1. Дисковое пространство стоило дорого. Хранить в DWH сырые логи или копии OLTP-таблиц было неразумно. Каждый терабайт обходился в тысячи долларов в год — с учётом лицензий, поддержки и обслуживающего персонала.
2. CPU-ресурсы были ограничены. Если в DWH одновременно работал отчёт CFO и трансформация ночного батча, отчёт страдал. Поэтому трансформации выносили на отдельный ETL-сервер, чтобы не мешать аналитике.

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

Инструменты эпохи ETL

Если ты увидишь в вакансии что-то про Informatica PowerCenter, IBM DataStage, Microsoft SSIS или Talend Open Studio — это классические ETL-инструменты, и многие из них продолжают работать. Тебе вряд ли придётся писать новый пайплайн в Informatica, но ты можешь столкнуться с легаси в крупных банках, страховых, телеком-компаниях.

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

В каждый блок ты можешь зайти, посмотреть SQL-запрос или выражение трансформации, поменять параметры. Готовый job деплоится на сервер, который запускается ночью по расписанию.

Зачем transform до load: реальные причины

Помимо экономии storage в DWH, у трансформации до загрузки были и есть конкретные применения:

PII-маскинг. Если в источнике лежат номера паспортов, телефоны, email — в DWH часто нельзя пускать их в открытом виде. ETL хэширует или маскирует чувствительные поля до того, как они уйдут в общедоступное хранилище. Это требование GDPR, HIPAA, PCI DSS.

Соответствие схеме DWH. Источник может отдавать данные в любом формате — XML, CSV, вложенный JSON. DWH ждёт плоскую табличную схему. Преобразование форматов и нормализация — задача ETL.

Бизнес-правила и enrichment. Иногда нужно дообогатить данные ещё на этапе загрузки: посчитать категорию клиента, применить курс валют на дату транзакции, привести коды стран к ISO. Эта логика встроена в ETL-job.

Уменьшение объёма. Если из источника приходит миллиард строк сырого web-лога, а в DWH нужны только дневные агрегаты, нет смысла грузить сырьё. ETL агрегирует и заливает результат — это экономит storage в дорогом DWH.

Минусы, которые привели к ELT

ETL хорошо работал и работает, но у него есть болезненные ограничения, которые в 2010-х стали особенно заметны:

Раз преобразовал — назад не вернёшь. Если позже понадобилась другая агрегация или другой фильтр, придётся снова идти к источнику, снова делать extract. Сырые данные в DWH не сохранились.

ETL-сервер — bottleneck. Когда данных стало терабайты в день, скейлить одну Informatica-машину стало дорого. Лицензия, RAM, CPU — всё это росло вертикально, а не горизонтально.

Логика трансформации заперта в чужом GUI. SQL-запросы в Informatica не лежат в git, не проходят через code review, не покрыты тестами в привычном смысле. Версионирование и CI/CD приходится изобретать поверх.

Где ETL живёт в 2026 году

Несмотря на популярность ELT, ETL никуда не делся. Он по-прежнему используется в:

• Регулируемых отраслях. Финансы, медицина, госсектор — везде, где есть жёсткие требования к маскингу PII до попадания в общедоступное хранилище.
• Гибридных архитектурах. Когда часть данных живёт on-premise, а DWH в облаке, преобразование часто делают на стороне источника — это и есть ETL.
• Реверс-сценариях. Когда нужно отправить данные обратно в операционную систему (reverse ETL), часто требуется именно трансформация до загрузки в целевую систему.

Попробуй сам

Открой вакансию любой крупной компании из финтеха или страхования и посмотри в требования к Data Engineer. С большой вероятностью встретишь упоминание Informatica, SSIS, DataStage, IBM iDoc или похожих ETL-инструментов рядом с современными ELT-стеками. Подумай, почему компания может одновременно искать специалиста по новой и старой технологии. Какие пайплайны логично оставить в ETL, а какие переписать в ELT? Это и есть взгляд DE на ландшафт — не «что круче», а «что подходит этой задаче».