Растущий стартап выбирает архитектуру данных: классический ETL с отдельным трансформационным слоем или ELT поверх облачного DWH с dbt. Как принять решение и какие здесь компромиссы?

Короткий ответ

Единственно верного ответа нет — выбор зависит от объёма и разнообразия источников, требований к скорости доступа к сырым данным для разных команд и зрелости SQL-компетенций в аналитике; ELT обычно быстрее развернуть и масштабировать в облаке, но требует дисциплины в управлении трансформациями внутри DWH, а классический ETL даёт больше контроля над качеством данных до их попадания в хранилище ценой более медленной разработки.

Как это работает подробнее

В ETL трансформация и валидация происходят до загрузки — в хранилище попадают уже «чистые» данные, что снижает риск для потребителей, но любое изменение логики требует изменений вне хранилища и повторного прогона внешнего процесса. В ELT сырые данные сразу доступны внутри DWH, трансформации пишутся как SQL-модели (например, в dbt), что ускоряет итерации, но означает, что «грязные» сырые данные временно видны внутри хранилища.

Пример кода

architecture.txtКопировать

Вариант A (ELT): raw_events (BigQuery) -> dbt staging -> dbt marts, итерация модели = 1 PR
Вариант B (ETL): Airflow DAG с Python-трансформацией -> только чистые данные в DWH

Что использовать на практике

• На практике. Для стартапа с небольшой командой аналитиков и облачным DWH (BigQuery/Snowflake) ELT+dbt обычно даёт более быструю разработку и более дешёвое масштабирование вычислений; для организации с жёсткими требованиями комплаенса, где сырые данные не должны покидать определённый периметр до маскирования чувствительных полей, этап Transform до Load может быть обязателен по регуляторным причинам.
• Проверка. для принятия решения — посчитать время на изменение одной бизнес-метрики «от идеи до прод» в обоих вариантах на пилотном кейсе и сравнить с требованиями комплаенса к сырым данным.

Подводные камни

• Частые ошибки. Выбирают архитектуру по «модности» инструмента, а не по реальным ограничениям (объём данных, регуляторные требования, компетенции команды); либо смешивают подходы хаотично — часть логики в ETL-скриптах, часть в dbt — без единого стандарта, что усложняет lineage и отладку.
• Компромисс. ELT ускоряет разработку и снижает порог входа для аналитиков, но временно хранит необработанные (иногда содержащие PII) данные внутри DWH и требует дисциплины тестирования dbt-моделей, иначе «грязные» данные легко утекут в продакшен-витрины. ETL даёт больше контроля и безопасности до загрузки, но замедляет итерации и требует отдельной инфраструктуры трансформации. Выбор — это компромисс между скоростью разработки и контролем/комплаенсом, и он может быть гибридным (например, маскирование PII на этапе Extract, остальная трансформация — в ELT).