Мы разобрались, что такое ETL, что такое ELT, и как выглядит современный стек. Теперь главный вопрос инженера: в новой задаче что выбирать. На этот вопрос нет универсального ответа, и любой опытный DE скажет, что зависит от контекста. Этот урок собирает чек-листы, по которым принимают решение в реальной жизни.
Базовое правило 2026 года
Если ты строишь новый аналитический пайплайн в облаке, источники — SaaS или OLTP-базы, нет жёстких compliance-ограничений и нет легаси — по умолчанию начинай с ELT. Это базовая рекомендация, исходящая из того, что ELT-стек:
- Дешевле в инженерном времени (готовые коннекторы Fivetran/Airbyte, SQL вместо проприетарного GUI).
- Эластичнее по compute (платишь за минуты).
- Сохраняет сырьё, что позволяет легко добавлять новую аналитику.
- Использует SQL, который знает большая часть команды.
Это позиция по умолчанию. Дальше — список случаев, когда от неё отступают.
Когда ETL ещё нужен
Сценарий 1: PII и compliance
Если в источнике есть персональные данные — номера паспортов, телефоны, email клиентов, медицинские записи, банковские данные — компания может быть юридически не вправе загружать их в DWH в открытом виде. Особенно если DWH общий для нескольких команд (маркетинг, продажи, продукт), и расширенный доступ есть у десятков аналитиков.
В этом случае логично применить transform до load: маскировать или хэшировать чувствительные поля на отдельном сервере, а в DWH класть уже обезличенный результат.
Чувствительные поля хэшируются на отдельном сервере перед загрузкой в DWH, где их видят все аналитики.
В GDPR и HIPAA-регулируемых сценариях это часто единственно допустимый шаблон. Решения вроде «загрузим в DWH, потом замаскируем» не проходят compliance-аудит: между Load и Transform проходит окно, в которое сырые данные доступны.
Сценарий 2: Legacy on-premise
Если в компании есть DWH на Teradata, Oracle Exadata, IBM DB2 или Netezza, построенный на ETL-парадигме, его не переписывают одним днём. Это десятки тысяч пайплайнов, бизнес-логика, годами выверенные модели — миграция стоит миллионы долларов и занимает годы.
В таком окружении новые пайплайны часто продолжают делать в существующем ETL-инструменте — Informatica, IBM DataStage, SSIS. Это рациональный выбор: гомогенность стека, повторное использование экспертизы команды, готовая инфраструктура мониторинга.
Постепенно такие компании мигрируют отдельные доменные области в ELT (Snowflake + dbt), но это многолетний процесс.
Сценарий 3: Гибридные on-prem + cloud
Бывает, что часть данных по бизнес-причинам нельзя выводить из on-premise (банковская тайна, государственные регуляции, контракты с клиентами). В этом случае часто применяется такая схема:
- В on-prem DWH данные обрабатываются по ETL-парадигме.
- В облако вывозят уже агрегированный или обезличенный результат для общей аналитики.
Это снова случай transform до cloud-load — то есть фактически ETL.
Сценарий 4: Очень дорогой compute в облаке
Если объёмы данных огромны (десятки терабайт ежедневно), и сценарий «загрузить в Snowflake и трансформировать SQL-ом» обходится в шестизначные суммы в месяц, иногда выгоднее вернуться к ETL: запустить Spark-кластер на дешёвых spot-инстансах, прогнать тяжёлую трансформацию там и загрузить только результат в DWH.
Это редкий, но реальный кейс — обычно у компаний с очень специфичной нагрузкой типа потоковых логов, геопространственных данных, биллинговой обработки.
Когда ELT — однозначный выбор
Сценарий 1: Новый проект в облаке с SaaS-источниками
Стартап подключает Stripe, Hubspot, Salesforce, Google Ads, продакшен-Postgres. Никаких legacy. Compliance стандартный (нет регулируемых медицинских/банковских данных). Команда — 1-3 DE.
Это книжный ELT-кейс. Fivetran + Snowflake + dbt + Looker. Поднимается за несколько недель, окупается мгновенно по сравнению с попыткой поднять Informatica.
Сценарий 2: Аналитика поверх продуктовых данных
Продуктовая команда хочет видеть метрики из своей операционной базы — DAU, retention, cohort analysis. Источник — одна или несколько OLTP-баз. Данные — структурированные.
ELT идеален. Реплицируй базу в DWH через CDC (например, Debezium + Snowflake), пиши dbt-модели поверх.
Debezium: CDC как основа real-time ELT из OLTP-источников в DWH К источнику возвращаться не нужно, новые метрики добавляются за час.
Сценарий 3: Команда хочет git и code review
Если в команде уже работают практики git-workflow, pull request, CI/CD — то ELT с dbt сразу даёт привычные инструменты для трансформаций. ETL-инструменты типа Informatica плохо вписываются в эти практики, и команда будет страдать.
Сравнительная матрица
Слева критерий, посередине куда он толкает, справа короткое обоснование.
Реальная картина: гибрид
В крупных компаниях редко встречается чистый ETL или чистый ELT. Чаще всего это гибрид:
- Для PII-сценариев работает отдельный ETL-слой с маскированием до DWH.
- Для регулируемых данных есть on-prem пайплайн, который в облако вывозит только агрегаты.
- Для общей аналитики работает классический ELT с Fivetran/Snowflake/dbt.
- Для тяжёлых сценариев есть Spark-кластер, считающий тяжёлые модели снаружи и загружающий результат в DWH.
Твоя задача как DE — понимать, какой шаблон для какого сценария подходит, и обосновать выбор бизнес-логикой, compliance-ом и экономикой, а не модой.
Опасно строить пайплайн исключительно по принципу «как делают в Netflix» или «как пишут в блоге Snowflake». В каждой компании свой контекст: размер команды, легаси, регуляторика, бюджет, объёмы. Хороший выбор — тот, который оправдан в твоей конкретной ситуации, а не самый модный.
Попробуй сам
Возьми мысленно три компании, которые ты хорошо знаешь как пользователь: маркетплейс, банк, медицинская клиника. Подумай, какие сценарии у каждой требуют ETL, какие ELT, и почему. Маркетплейс: какие источники? есть ли PII? есть ли legacy? Банк: какие compliance-ограничения? куда логично вывозить агрегаты? Клиника: HIPAA-аналог в стране, можно ли вообще что-то отправлять в публичное облако? Это упражнение учит мыслить как DE на собеседовании.