ETL или ELT: различия и выбор процесса загрузки данных

Обновлено 2 сентября 2026 года.

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

Два процесса на одном примере

Предположим, нужно объединить заказы CRM и расходы рекламы в ежедневном отчёте. У источников разные даты, валюты, идентификаторы кампаний и правила обновления записей.

Определения и место преобразований разобраны в сравнении IBM. Название относится к границе выбранной целевой системы: один проект может включать несколько процессов и сочетать оба подхода.

Чего ETL и ELT сами по себе не гарантируют

• Скорость. Быстро загрузить исходные данные — не то же самое, что быстро подготовить корректный отчёт. В ELT преобразования тоже занимают время.
• Параллельность. Она возможна в обоих подходах. Microsoft прямо описывает параллельное выполнение этапов ETL в руководстве по архитектуре интеграции.
• Линейное масштабирование. Удвоение ресурсов не обещает удвоение скорости. Ограничением могут стать API, сеть, конкурирующие запросы или запись в одну таблицу.
• Сохранность истории. ETL может сохранять исходные выгрузки. ELT может потерять историю, если загрузчик перезаписывает строки, пропускает удаления или слишком рано очищает исходный слой.
• Качество. Оно зависит от правил и проверок. Данные в исходном слое ELT ещё не готовы для бизнес-решений.

Когда удобнее ETL

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

Другой учебный сценарий — загрузка дневных агрегатов в систему с небольшим ресурсом на преобразования. Внешний процесс подготавливает результат, а целевая база обслуживает чтение. Цена такого решения — сопровождение внешнего вычислительного процесса и необходимость заранее продумать, как пересчитать результат при изменении правил.

Когда удобнее ELT

Рассмотрите ELT, если целевая платформа эффективно выполняет необходимые преобразования, исходные данные допустимо хранить в ней, а несколько команд строят разные витрины из одной истории. Например, отделы продаж и маркетинга используют один набор заказов, но по-разному группируют его для своих задач.

Слои исходных, очищенных и подготовленных данных позволяют разделить загрузку и использование. Один из вариантов такого устройства показан в архитектуре озера данных Microsoft. Наличие трёх слоёв не заменяет правила доступа, хранения и проверки результатов.

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

Как обрабатывать изменения без двойного счёта

Учебный пример: заказ №100 сначала имел сумму 1 000 рублей, затем его исправили на 1 200. Если обе выгрузки просто добавить в таблицу текущих заказов, отчёт покажет 2 200 вместо 1 200. Ошибка одинаково возможна при ETL и ELT.

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

• Задайте ключ записи: при нескольких порталах CRM это может быть пара «портал + ID заказа».
• Сохраните дату изменения или другую доступную версию источника, время извлечения и идентификатор запуска.
• Определите обработку отмен, удалений и исправлений старых периодов. Фильтр только по дате создания их пропустит.
• Сделайте повторный запуск безопасным: повторная доставка того же пакета не должна повторно увеличивать выручку.
• Сдвигайте отметку успешной загрузки после подтверждённой записи результата. Учитывайте одинаковые временные отметки и поздно поступившие изменения.

Как сравнить стоимость и задержку

На небольшом пилоте измерьте полный путь от изменения в источнике до готовой витрины. Отдельно запишите время извлечения, преобразования, записи и обновления BI. Если отчёт обновляется раз в сутки, ускорение промежуточной загрузки с десяти минут до одной само по себе не сделает его ежеминутным.

Проверка перед рабочим запуском

1. Сверьте число уникальных заказов и контрольную сумму с источником за закрытый период.
2. Повторите тот же пакет: итог должен остаться прежним.
3. Измените тестовый заказ и убедитесь, что новая сумма заменила старую в витрине текущего состояния.
4. Проверьте отмену, удаление и запоздавшее изменение за предыдущий месяц.
5. Имитируйте ошибку в середине процесса. Пользователь не должен увидеть смесь старой и частично новой витрины.
6. Покажите в отчёте дату данных и статус последнего успешного обновления.

Результат выбора — схема с понятным местом преобразования, владельцем процесса, правилами повторного запуска и измеренным временем готовности данных. Универсального победителя между ETL и ELT нет: полезнее проверить конкретную нагрузку и требования на своём наборе данных.