ETL vs ELT и как сдвиг к ELT изменил моделирование
Два прошлых урока показали: данные нужно копировать из OLTP-системы в отдельный аналитический warehouse, и этот warehouse устроен иначе физически — поколоночно, со сжатием. Остался вопрос: как именно происходит копирование и кто превращает сырьё из источников в аккуратную аналитическую модель?
Этот процесс прошёл за последние годы тихую, но фундаментальную перемену. Раньше он назывался ETL, теперь — всё чаще ELT. На вид переставлены две буквы. На деле эта перестановка изменила не только инструменты, но и сам подход к моделированию данных: появилась возможность строить модель слоями, постепенно, прямо в warehouse. Этот урок объясняет, что за буквами и почему перестановка так много значит для того, чем вы занимаетесь в этом курсе.
Три буквы: Extract, Transform, Load
И ETL, и ELT состоят из одних и тех же трёх шагов. Различие — в порядке.
- Extract — извлечь данные из источников: production-баз приложений, API внешних сервисов (платёжных систем, CRM), логов, файлов. Источников обычно много, и форматы у них разные.
- Transform — преобразовать: очистить, привести типы, согласовать справочники, посчитать производные поля, соединить разрозненные таблицы, придать данным аналитическую модель — ту самую размерную, которую вы будете строить в следующих модулях.
- Load — загрузить результат в целевую систему, в аналитический warehouse.
Extract всегда первый, Load всегда связан с попаданием в warehouse. Подвижна буква T. Вопрос один: трансформация происходит до загрузки в warehouse или после?
ETL: трансформация до загрузки
ETL — Extract, Transform, Load. Трансформация — в середине, до попадания данных в warehouse. Данные извлекаются из источников, преобразуются на отдельном промежуточном сервере (исторически — мощная машина с инструментом вроде Informatica, или кластер Spark), и в warehouse попадают уже готовыми, в финальной аналитической форме.
ETL: трансформация на отдельном сервере, ДО warehouse
[Источники] --extract--> [ETL-сервер: чистит, считает, моделирует] --load--> [Warehouse: готовые таблицы]Почему так делали? Из-за денег и железа. До эпохи облаков warehouse был дорогим — отдельный физический сервер с дорогими лицензиями и ограниченным, плохо масштабируемым объёмом хранения и вычислений. Хранить в нём сырьё было расточительно: место дорого. Гонять в нём тяжёлые трансформации — значит отнимать вычислительный ресурс у запросов аналитиков. Поэтому трансформацию выносили наружу, на отдельную машину, а в драгоценный warehouse клали только финальный, очищенный, уже смоделированный результат.
У ETL есть цена. Промежуточный сервер трансформаций — отдельная инфраструктура, которую надо поднимать и обслуживать. Логика трансформаций живёт вне warehouse — часто в проприетарном инструменте или в Spark-коде на Scala, который пишут и поддерживают data engineers; аналитик к ней доступа не имеет. И главное: сырьё не сохраняется. В warehouse попадает только то, что трансформация решила оставить. Понадобилось пересчитать историю по новой логике или достать поле, которое раньше отбрасывали, — исходных данных уже нет, нужно заново выгружать из источника, если он вообще ещё их хранит.
ELT: загрузка сырья, потом трансформация
ELT — Extract, Load, Transform. Трансформация переехала в конец, после загрузки. Данные извлекаются из источников и грузятся в warehouse сырыми, как есть — без преобразований. И только затем трансформируются — уже внутри warehouse, средствами SQL.
ELT: сырьё грузится сразу, трансформация ВНУТРИ warehouse
[Источники] --extract--> [Warehouse: сырые данные] --transform (SQL внутри)--> [Warehouse: модель]Что сделало этот переворот возможным? Облачные колоночные warehouse — Snowflake, BigQuery, Redshift, Databricks. Они изменили экономику сразу по двум осям. Хранилище стало дёшево: благодаря колоночному сжатию (прошлый урок) и облачному объектному хранилищу держать сырьё в warehouse больше не расточительство — оно почти ничего не стоит. И вычисления стали эластичными и мощными: warehouse пересчитывает сотни миллионов строк за минуты и масштабируется по требованию. Когда хранить сырьё дёшево, а считать прямо в warehouse быстро — выносить трансформацию на отдельный сервер незачем. Проще загрузить всё сырьё и трансформировать его на месте, языком SQL, который этот warehouse и так исполняет лучше всего.
Как сдвиг к ELT изменил моделирование
Перестановка букв — это инструментальное изменение. Но за ним стоит изменение в самом подходе к проектированию данных, и именно оно важно для этого курса.
Сырьё сохраняется — модель можно переделывать. В ETL трансформация была воротами: что не прошло, того в warehouse нет. Ошиблись в логике или поняли требование иначе — пересчитать не из чего. В ELT сырьё лежит в warehouse постоянно. Изменили определение метрики, нашли ошибку, добавили атрибут — просто перезапускаете трансформацию поверх всё того же сохранённого сырья. Моделирование стало итеративным: модель — не единственный необратимый шанс, а слой, который можно пересобрать.
Трансформация — это SQL, и моделирование стало доступнее. В ETL логика жила в Spark/Scala или проприетарном инструменте — территория data engineers. В ELT трансформация — это SQL внутри warehouse. На SQL размерную модель — fact- и dimension-таблицы — может строить аналитик или analytics engineer, а не только инженер с навыком распределённых систем. Моделирование данных перестало быть узким горлышком одной команды.
Появились слои — modeling стал многоступенчатым. Это, пожалуй, главное следствие. Раз сырьё лежит в warehouse и трансформации — это просто SQL-запросы, создающие новые таблицы, никто не мешает делать их цепочкой. Не «сырьё -> финальная модель» одним прыжком, а серия слоёв, где каждый последующий чуть ближе к аналитике, чем предыдущий. Промышленный стандарт такой раскладки — medallion architecture, три слоя зрелости данных:
- Bronze — сырьё как есть из источников, плюс метаданные загрузки (когда и откуда пришло). Ничего не выброшено. Это «сохранённое сырьё» ELT.
- Silver — очищенные, согласованные, интегрированные данные: приведены типы, состыкованы справочники из разных источников, убраны дубли. Ещё не финальная аналитическая форма, но уже причёсанная.
- Gold — бизнес-готовый слой: денормализованные, оптимизированные под чтение размерные модели — те самые star schema, fact- и dimension-таблицы, агрегаты. То, к чему обращаются дашборды.
Главное: модель данных перестала быть единственной таблицей на выходе пайплайна. Она стала слоистой — на каждом уровне своя степень причёсанности и своя задача. Размерное моделирование, которым займётся весь следующий блок курса, живёт в gold-слое: это финальная, оптимизированная под аналитику форма поверх сохранённого сырья и очищенного silver.
Medallion — про слои зрелости данных, не про конкретный синтаксис модели. Внутри каждого слоя всё равно нужна продуманная модель: bronze повторяет структуру источников, silver часто близок к нормализованной форме или приёму многих источников, gold — это размерная модель. «Bronze/silver/gold» отвечает на вопрос «насколько данные готовы», а не «какой у них дизайн».
ELT не отменил ETL
Важная оговорка, чтобы не получить искажённую картину. ELT стал стандартом для типичной аналитики, но ETL не исчез — у него остались законные ниши.
Чувствительные данные иногда обязаны быть обезличены или отфильтрованы до попадания в warehouse — по требованиям приватности; такую трансформацию нельзя отложить на «после загрузки». Потоковые данные (Kafka и подобное) часто обрабатываются на лету, до приземления. А когда источник лежит на платформе с очень дорогими вычислениями, бывает дешевле трансформировать ближе к источнику, чем тянуть весь объём сырья.
| Аспект | ETL | ELT |
|---|---|---|
| Где происходит Transform | на отдельном сервере, до warehouse | внутри warehouse, после загрузки |
| Сырьё в warehouse | не сохраняется | сохраняется (bronze-слой) |
| Язык трансформаций | Spark/Scala, проприетарные инструменты | SQL |
| Кто моделирует | в основном data engineers | analytics engineers, аналитики |
| Пересчёт по новой логике | заново выгружать из источника | перезапустить SQL поверх сырья |
| Что сделало возможным | дорогой warehouse, дешёвый внешний compute | дешёвое хранилище и эластичный compute облака |
| Стиль моделирования | одним прыжком до финала | итеративно, слоями (medallion) |
Но для подавляющего большинства аналитических задач 2026 года порядок именно ELT — и весь подход «моделируем слоями, gold-слой это размерная модель», который пронизывает остаток курса, держится на этом сдвиге.
Modern Data Stack: ландшафт ELT-инструментов 2026 dbt vs альтернативы: SQL, Spark, Airflow, DagsterЗапоминалка различия: в ETL буква T стоит между E и L, потому что трансформация физически между источником и warehouse. В ELT T стоит после L, потому что трансформация происходит после того, как сырьё уже легло в warehouse. Порядок букв буквально отражает физическое место шага.
Попробуй сам
Представьте компанию с тремя источниками: production-база PostgreSQL интернет-магазина, API платёжной системы, выгрузки рекламного кабинета в CSV. Цель — дашборд «маржа по товарным категориям и рекламным каналам».
Распишите этот пайплайн в логике ELT по трём слоям medallion. Что попадёт в bronze из каждого источника? Что произойдёт в silver — какие типы привести, какие справочники между источниками согласовать, где искать дубли? Как будет выглядеть gold — какая fact-таблица и какие dimension-таблицы (предвосхищая следующий модуль, не страшно, если приблизительно)?
Затем ответьте на главный вопрос урока: что конкретно стало бы невозможно или больно, если бы этот же пайплайн строили по ETL — без сохранения сырья и с трансформацией на отдельном сервере? Привяжите ответ к двум вещам: пересчёту истории при смене определения «маржи» и к тому, кто в команде способен такой пайплайн написать и сопровождать.