ELT против ETL: почему трансформации в хранилище

В уроке про ETL и ELT ты чинил часовые пояса прямо в хранилище, одним запросом. Отто понравилось, и теперь он хочет такую сводку каждый день, а финансы хотят ту же чистку для своей выручки. Запрос в блокноте уже не годится: преобразование надо сохранить в хранилище, чтобы им пользовались все. Давай попробуем сделать это руками, без dbt, и посмотрим, где станет больно.

Сборка мебели на месте

Раньше мебель собирали в мастерской и привозили целиком. Если шкаф не влез в проём, его везли обратно. Теперь привозят детали в коробках и собирают прямо в комнате. Не подошла полка: переставил. Детали никуда не делись, можно пересобрать по-другому.

С данными случилось то же. В ETL данные чистили по дороге, на отдельном сервере, и в хранилище привозили готовый результат. В ELT сырые данные кладут в хранилище как есть и собирают из них нужное уже там.

Почему трансформации переехали в хранилище

Про то, что сырые данные остаются под рукой и историю можно пересчитать, ты уже знаешь. Есть ещё три причины.

Вычисления стали дешёвыми. Современные облачные хранилища вроде Snowflake, BigQuery или ClickHouse умеют за секунды перемалывать миллиарды строк и берут деньги за время работы. Отдельный сервер для чистки данных стал не нужен: хранилище справляется само.

SQL знают все. Преобразование на Python или Java может поправить только программист. Преобразование на SQL может прочитать и поправить аналитик. Чем больше людей понимает код, тем быстрее находят ошибки.

Всё в одном месте. Сырые таблицы, промежуточные шаги и витрины лежат в одной базе. Чтобы понять, откуда взялась цифра, не нужно искать скрипт на чужом сервере.

Цепочка представлений руками

Самый простой способ сохранить преобразование в хранилище это представление. Сделаем два шага, как настоящий конвейер:

1. clean_orders: только чистые доставки, время доставки в местном поясе;
2. zone_daily: по зонам и дням, сколько доставок и сколько опозданий.

Второе представление читает первое. Это уже цепочка: каждый шаг маленький и понятный, а финансы могут взять clean_orders для своей выручки и не чистить данные заново.