'/%3e%3cpath%20d='M83.8172%20112C100.688%20112%20111.886%2098.2694%20112%2083.8882H44.0245C25.8409%2083.8882%2016.001%2094.3169%2016.001%20112H83.8172Z'%20fill='url(%23paint1_linear_101_577)'/%3e%3cpath%20d='M44.1725%2044.1138H16.0008C15.9465%2051.0963%2018.504%2058.2306%2024.2977%2064.0225L44.1706%2083.8881L52.8986%2075.3569L61.7636%2066.7019C63.2767%2065.2244%2063.2786%2062.7888%2061.7636%2061.3094L44.1725%2044.1138Z'%20fill='%233A5FFF'/%3e%3cpath%20d='M83.8248%2083.8862H111.996C112.051%2076.9037%20109.493%2069.7693%20103.7%2063.9774L83.8267%2044.1118L75.0986%2052.6431L66.2337%2061.2981C64.7206%2062.7756%2064.7187%2065.2112%2066.2337%2066.6906L83.8248%2083.8862Z'%20fill='%233A5FFF'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_101_577'%20x1='16.001'%20y1='30.055'%20x2='111.998'%20y2='30.055'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_101_577'%20x1='111.998'%20y1='97.9451'%20x2='16.001'%20y2='97.9451'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
ETL и ELT
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 — за счёт дешёвых облачных хранилищ и удобных инструментов вроде dbt. Но это не универсальный ответ: при определённых требованиях к безопасности, частоте загрузок или нагрузке ETL до сих пор остаётся правильным выбором.
dbt (data build tool) — популярный инструмент для ELT-преобразований внутри хранилища. Он позволяет описывать модели данных в виде SQL-файлов, выстраивать их зависимости как граф и автоматически тестировать качество. Сегодня это де-факто стандарт «T» в ELT-стеке.