ETL и ELT — не противоположные технологии, а разные точки в устройстве конвейера данных. Выбор обычно зависит от того, где у вас узкое место — в источниках или в хранилище.
ETL
- Логика преобразований — на отдельном слое или сервере.
- Хранилище получает уже готовые, приведённые в порядок таблицы.
- Хорошо подходит, когда нельзя или дорого считать в хранилище.
- Обычно дольше внедряется и сложнее меняется.
ELT
- Сырые данные сначала попадают в хранилище.
- Все преобразования — внутри хранилища (например, через dbt).
- Гибче: можно пересчитать модель данных без переподключения источников.
- Требует мощного и относительно дешёвого хранилища: BigQuery, Snowflake, Redshift, ClickHouse.
- Новый проект и современное облачное хранилище — обычно подходит ELT
- Большой корпоративный набор систем с уже работающим ETL — менять подход редко имеет смысл
- Очень тяжёлые преобразования с особыми требованиями — иногда ETL до сих пор удобнее
- Маленький проект без аналитики — не нужен ни один из подходов: хватит прямого SQL-запроса к рабочей базе
Молодая SaaS-компания строит аналитику с нуля. Источники — база продукта на Postgres, Stripe, Amplitude, рекламные кабинеты. Команда выбирает ELT: Fivetran выкачивает сырые данные в BigQuery, dbt описывает все преобразования SQL-моделями, а Metabase строит отчёты поверх готовых витрин. На каждый новый источник нужен день, на новую модель данных — час. С классическим ETL это заняло бы заметно больше времени и потребовало бы отдельной команды инженеров данных.
В небольшой команде проще начать с ELT: готовые коннекторы (Fivetran, Airbyte) забирают данные из источников, а преобразования описываются моделями в dbt. Это снимает с команды большую часть инженерной работы и позволяет сосредоточиться на самих моделях данных и метриках.