ELT против ETL: где выполняется Transform и почему индустрия перевернулась

Развилка пайплайна: где живёт T

Когда ты проектируешь дата-пайплайн, первый вопрос — не какой инструмент взять, а где выполняется трансформация. Именно от этого решения зависит, будет ли баг однострочным SQL-фиксом или неделей re-extract из источника, который, возможно, уже не держит нужные данные.

Оба паттерна перемещают данные из источников в склад. Единственная реальная разница — порядок средней буквы, и эта одна перестановка меняет всё, что идёт дальше.

ETL (extract, transform, load) родился, когда storage и compute были одной дорогой коробкой. Ты не мог позволить себе сгружать всё в склад, поэтому трансформировал сначала — в отдельном движке (Informatica, кластер Spark/Hadoop, Python-джоб) — чистил, джойнил, фильтровал и агрегировал, а потом грузил только отполированный результат. Склад видел только готовую таблицу.

ELT (extract, load, transform) переставляет два последних шага. Ты грузишь сырые исходные данные в склад первыми, нетронутыми, а потом трансформируешь их на месте в SQL. Трансформация больше не отдельная система — это запросы, выполняющиеся на том же движке, что хранит данные. dbt — доминирующий инструмент для «T»: версионируемые, протестированные, документированные SQL-модели вместо чёрного ящика-пайплайна.

Причина переворота индустрии архитектурная, а не модная. Snowflake и BigQuery разделяют storage и compute. Storage — это дешёвое объектное хранилище; compute — отдельный эластичный ресурс, который ты поднимаешь только когда выполняется запрос. Это полностью ломает старое ограничение — ты можешь позволить себе посадить сырьё, потому что хранить его почти ничего не стоит, а за compute платишь только когда реально трансформируешь.

Почему ELT победил: сырьё воспроизводимо

Самая глубокая причина, по которой ELT стал дефолтом, — не цена, а воспроизводимость (возможность переиграть). В ETL сырые исходные данные выбрасываются после трансформации; склад держит только трансформированный вывод. Поэтому когда (не если) ты находишь баг в трансформации — неверный ключ джойна, ошибку таймзоны, валюту, которую надо было конвертировать, — ты не можешь починить историю. Сырой ввод исчез. Приходится переэкстрагировать из источника, а источник мог измениться, заблокировать тебя по rate-limit или больше не держать старые строки.

В ELT сырьё живёт в складе постоянно. Баг трансформации — это однострочный SQL-фикс плюс перезапуск по данным, которые у тебя уже есть. Никакого re-extract. Это сердце medallion-архитектуры (трёхслойной схемы хранения данных): слой bronze из сырых, append-only (только дозапись, без изменения существующих строк) загруженных данных; слой silver из очищенных, приведённых, дедуплицированных таблиц; слой gold из готовых к бизнесу агрегатов и витрин. Каждый слой пересобираем из нижнего, а bronze пересобираем из источника, только если уж совсем нужно. Контракт такой: никогда не мутируй bronze, всегда трансформируй вперёд.

Стоимость переезжает на счёт склада

ELT не делает трансформацию бесплатной — он переносит стоимость с CapEx-кластера, которым ты владел, на тарифицируемую OpEx-строку в счёте склада, и эта строка зверски чувствительна к тому, как ты пишешь SQL. Hook — каноничный провал: модель, материализованная как полная пересборка таблицы, поставленная часто по расписанию, сканирующая всё на каждом запуске. В Snowflake ты платишь за warehouse-секунду; в BigQuery — за просканированные байты. SELECT * по непартиционированной таблице на 2 ТБ, ежечасно, — это уже сам по себе четырёхзначный пункт месячного счёта.

Фикс — инкрементальные модели. Вместо пересборки всей таблицы ты обрабатываешь только новые или изменённые строки с прошлого запуска. В dbt это макрос is_incremental(), оборачивающий фильтр:

{% if is_incremental() %}
  where event_time >= (select max(event_time) from {{ this }})
{% endif %}

На первом запуске таблица строится полностью; на каждом следующем трогаются только строки новее текущего максимума. Ночной джоб, сканировавший 2 ТБ, теперь сканирует дельту за день — часто несколько ГБ — срезая и время выполнения, и тарифицируемые байты на один-два порядка. Когда ты создаёшь новую dbt-модель, базовая позиция такая: инкрементально по умолчанию, full refresh только когда меняется логика (dbt run --full-refresh), и отдельный warehouse на команду, чтобы тяжёлый трансформ никогда не голодил BI-дашборды на общем compute. Команды, забывающие auto-suspend на простаивающих warehouse, сливают кредиты за compute, который ничего не делает.

Идемпотентность: повтор, который удваивает твои данные

Провал, от которого люди просыпаются ночью, — дублирование данных. EL-инструменты вроде Fivetran и Airbyte, и твои собственные загрузчики, повторяют при временном сбое — это корректное поведение. Но если загрузка не идемпотентна, повтор, перезапускающий частично-успешный батч, вставляет те же строки дважды. Теперь твой итог по выручке завышен, и дашборду никто не верит.

Лекарство — сделать загрузки и инкрементальные трансформации идемпотентными: запустить дважды даёт тот же результат, что запустить один раз. В инкрементальных моделях dbt это стратегия merge с unique_key:

{{ config(materialized='incremental', incremental_strategy='merge', unique_key='event_id') }}

На каждой строке merge обновляет, если unique_key уже существует, и вставляет, если нет — это upsert. Повтор того же батча обновляет строки на месте вместо дублирования. Ловушка: инкрементальная модель без unique_key и без фильтра is_incremental() тихо аппендит весь свой вывод на каждом запуске, поэтому она и дублирует, и пересканирует всё — худшее из двух миров. Microbatch-модели идут дальше, трактуя каждый временно́й батч как атомарную, независимо заменяемую единицу, поэтому упавший батч переигрывается чисто, не трогая соседей.

Все пять стадий вместе образуют medallion-контракт: сырьё сохранено в bronze — поэтому каждый слой выше пересобираем. Без этого порядка, а конкретно без посадки сырья до трансформации, ты теряешь возможность переиграть историю при изменении логики — а это самая дорогостоящая потеря.