ETL против ELT: как меняется архитектура данных в облачную эпоху

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

В статье расскажем, в чём разница между ETL и ELT, как облачные технологии повлияли на их развитие и почему выбор архитектуры критичен для российского рынка с учётом требований 152‑ФЗ. А ещё сравним экономику обоих подходов и рассмотрим, какие инструменты нашей платформы подходят для реализации каждого из них.

Типы нагрузок и источников данных

Выбор между ETL и ELT во многом зависит от характеристик источников и требуемой скорости доставки данных.

Скорость критична прежде всего для операционных контуров, где промедление даже в несколько минут губительно: для платежей и антифрода, RTB‑рекламы и логистики «последней мили». ELT позволяет быстро загрузить сырые данные и сразу предоставить их аналитикам и дата‑сайентистам для проверки гипотез, минуя длительный этап предварительного моделирования.

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

Дальше подробно разберём каждый из подходов, их сильные и слабые стороны, а также типовые паттерны применения.

ETL: классический подход к интеграции

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

Процесс ETL:

• Извлечение. Данные извлекаются из исходных систем и копируются в промежуточную область (Staging Area).
• Трансформация. В этой области данные проходят очистку, валидацию, стандартизацию, обогащение и агрегацию. Применяются сложные бизнес‑правила для приведения данных к целевой схеме (Schema‑on‑Write — схема при записи).
• Загрузка. Обработанные и структурированные данные загружаются в целевое хранилище данных — например, в DWH.

Чтобы усилить преимущества и сгладить ограничения ETL, в продакшене опираются на устоявшиеся практики. К ключевым паттернам относятся pre‑load валидация — проверка соответствия данных ожидаемым форматам и диапазонам значений до начала трансформаций, — а также выстроенное управление качеством данных (DQ) до загрузки: на ранних этапах выявляются аномалии, пропуски и дубликаты, чтобы не допустить их в целевое хранилище.

ELT: облачный подход к интеграции

ELT стал доминирующим подходом с развитием мощных облачных хранилищ данных и платформ больших данных. Он меняет парадигму: сначала данные собираются, а уже затем аналитики решают, как их использовать.

Процесс ELT:

• Извлечение. Данные извлекаются из исходных систем.
• Загрузка. Сырые данные загружаются напрямую в целевое хранилище.
• Трансформация. Выполняется по требованию внутри хранилища, обычно с помощью SQL‑запросов.

Чтобы раскрыть потенциал ELT и при этом держать риски под контролем, в продакшне опираются на устоявшиеся практики. Ключевые паттерны:

• SQL‑pushdown — максимальное выполнение логики трансформации на стороне базы данных с помощью SQL. Это снижает перемещение данных.
• Позднее моделирование — когда модель данных определяется не на этапе загрузки, а при анализе, обеспечивая гибкость интерпретации.

Гибридные архитектуры: Lambda, Kappa и медальоны

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

Архитектуры Lambda и Kappa

Они решают задачу объединения пакетной и потоковой обработки:

• Lambda‑архитектура. Использует два параллельных пути: «горячий» (Speed Layer) для обработки потоковых данных в реальном времени с возможными аппроксимациями и «холодный» (Batch Layer) для точной пакетной обработки исторических данных. Результаты объединяются на уровне сервисного слоя. Это сложная в реализации архитектура.
• Kappa‑архитектура. Упрощённая Lambda. Все данные рассматриваются как поток событий. Текущее состояние и исторические данные обрабатываются единым потоковым движком. Восстановление или пересчёт данных происходит путём повторного проигрывания потока событий.

ETL для мастер‑данных, ELT для аналитики

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

Медальонная архитектура

Это паттерн организации данных в Lakehouse, структурирующий ELT‑процессы по слоям качества:

• Бронза (сырые данные) — загружаются «как есть» из источников.
• Серебро (очищенные и стандартизированные данные) — проходят валидацию, очистку и приводятся к единому формату.
• Золото (агрегированные данные) — готовые для бизнес‑аналитики, отчётности и машинного обучения.

Ключевые различия ETL и ELT

Выбор между ETL и ELT влияет на многие аспекты работы с данными. Сравним ключевые различия.

Безопасность и комплаенс: фокус на 152‑ФЗ

Соблюдение требований регуляторов, в частности российского 152‑ФЗ «О персональных данных», — это один из ключевых факторов при выборе архитектуры:

• 152‑ФЗ и GDPR. Эти законы накладывают строгие требования на сбор, обработку, хранение и передачу персональных данных. 152‑ФЗ также требует локализации баз данных с персональными данными граждан РФ на территории России.
• PII‑маскирование. В ETL маскирование или анонимизация чувствительных данных выполняется на этапе трансформации — до того, как они попадут в общедоступное хранилище. Это снижает риски утечек. В ELT сырые данные, включая PII, загружаются в хранилище, и это требует реализации строгих политик доступа на уровне сырого слоя или использования подхода EtLT — «лёгкой» трансформации перед загрузкой для маскирования.
• Политики хранения. Управление жизненным циклом данных и их удаление по истечении срока хранения должны быть реализованы в обеих архитектурах.
• Аудит. Для комплаенса критична возможность отслеживать, кто, когда и к каким данным обращался. В облачных DWH это реализуется через встроенные механизмы логирования и аудита — например, Yandex Audit Trails.

Экономика процессов

Сравнение совокупной стоимости владения между ETL и ELT зависит от множества факторов.

• Стоимость трансформаций. В ETL вы платите за вычислительные ресурсы ETL‑платформы. В ELT вы используете вычислительные ресурсы DWH. Если трансформации неоптимальны, стоимость выполнения SQL‑запросов в облачном DWH может быть высокой. Но стоимость хранения сырых данных в облаке обычно ниже.
• Расходы на оркестрацию и мониторинг. Обе архитектуры требуют инструментов для планирования запуска задач и мониторинга выполнения пайплайнов.
• Исходящий трафик. При использовании облачных платформ нужно учитывать стоимость исходящего трафика, особенно если данные перемещаются между разными облаками или регионами.
• Хранилища. ELT требует больше места для хранения сырых данных, но использует дешёвые объектные хранилища. ETL требует меньше места в целевом DWH, но нуждается в промежуточном хранилище.

Реализация ETL и ELT в Yandex Cloud

Наша платформа предоставляет полный набор управляемых сервисов для построения как ETL-, так и ELT‑архитектур, соответствующих требованиям безопасности и локализации данных.

Как выбрать подход: чеклист

Выбор между ETL и ELT должен основываться на бизнес‑требованиях, технических возможностях и стратегии работы с данными.