Инженерия данных

ETL vs ELT

ETL и ELT

актуальноТекущий рабочий стандарт

Преобразовывать данные до загрузки или уже внутри хранилища — и почему индустрия сместилась ко второму.

Ключевые тезисы

  • ELT: грузим сырое, трансформируем SQL внутри хранилища — проще отлаживать и переигрывать.
  • Сырой слой нужно сохранять всегда: он позволяет пересчитать витрины после исправления логики.
  • Слои bronze / silver / gold — удобная и распространённая организация.

Подробный разбор

2 подтем — раскройте любую, чтобы увидеть объяснение, формулы, примеры и интерактивные графики.

1

Почему индустрия перешла к ELT

Три причины, все практические.

  1. Хранилища стали дешёвыми и быстрыми — трансформации выгоднее делать внутри них.
  2. Сырой слой позволяет пересчитать всё заново после исправления логики; в ETL исходные данные утеряны.
  3. SQL-трансформации версионируются и тестируются как код (dbt), а не живут в GUI ETL-инструмента.
2

Трансформации как код

Модель работы, ставшая стандартом.

-- models/silver/orders.sql
{{ config(materialized='incremental', unique_key='order_id') }}
SELECT order_id, user_id, amount, event_ts::date AS event_date
FROM {{ source('raw', 'orders') }}
{% if is_incremental() %}
  WHERE event_ts > (SELECT max(event_ts) FROM {{ this }})
{% endif %}
  • Зависимости между моделями выводятся автоматически из ссылок.
  • Тесты (unique, not_null, свои SQL-проверки) выполняются на каждом запуске.
  • Документация и граф происхождения данных генерируются из того же кода.

Связанные темы

Платформа данных

Warehouse, Lake, Lakehouse80%

Хранилище, озеро, lakehouse · Инженерия данных

Три способа хранить аналитические данные: строгая схема, сырые файлы или гибрид с транзакциями поверх объектного хранилища.

File Formats80%

Форматы хранения · Инженерия данных

Колоночные форматы против строковых: почему Parquet почти всегда лучше CSV для аналитики.

Partitioning80%

Партиционирование · Инженерия данных

Разделение данных по ключу (обычно по дате), чтобы запрос читал минимум файлов.

Analytical SQL80%

Аналитический SQL · Инженерия данных

Оконные функции, агрегации и CTE — основной инструмент подготовки признаков на больших данных.

Batch and Streaming80%

Батч и стриминг · Инженерия данных

Обработка по расписанию против непрерывной обработки событий. Разные задержки, разные гарантии, разная стоимость.

Orchestration80%

Оркестрация пайплайнов · Инженерия данных

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

Spark80%

Spark · Инженерия данных

Распределённая обработка больших объёмов данных: тот случай, когда данные не помещаются на одну машину.

Kafka80%

Kafka · Инженерия данных

Распределённый журнал событий: основа потоковой архитектуры и источник данных для онлайн-признаков.

ML Pipelines80%

ML-пайплайны · MLOps

Оформление обучения как воспроизводимой последовательности шагов вместо разрозненных ноутбуков.

Data Versioning80%

Версионирование данных · MLOps

Данные меняются чаще кода — без их версий эксперимент не воспроизвести.