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

Orchestration

Оркестрация пайплайнов

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

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

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

  • Задачи должны быть идемпотентны: повторный запуск не должен ломать данные.
  • Backfill — обязательная возможность: пересчитать историю после исправления логики.
  • Airflow, Dagster, Prefect различаются моделью: задачи против ассетов данных.
Тема также относится к главам:MLOpsПайплайны и версии

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

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

1

Идемпотентные задачи

Главное требование к шагу пайплайна.

Задача должна давать один и тот же результат при повторном запуске за тот же период. Обычно это достигается перезаписью партиции целиком (INSERT OVERWRITE PARTITION) вместо добавления строк.

# плохо: повторный запуск задваивает данные
df.write.mode("append").parquet(path)

# хорошо: перезапись конкретной партиции
df.write.mode("overwrite").option("partitionOverwriteMode", "dynamic").parquet(path)
2

Backfill и зависимости

Как пересчитать историю и не сломать прод.

  • Пайплайн должен принимать дату как параметр, а не использовать today() внутри.
  • Пересчёт запускается по диапазону дат с контролем параллелизма — иначе кластер ляжет.
  • Зависимости между задачами описываются явно: витрина не считается раньше источника.
  • Датчики (sensors) ждут появления данных, а не запускаются по слепому расписанию.

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

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

Warehouse, Lake, Lakehouse80%

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

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

File Formats80%

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

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

Partitioning80%

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

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

Analytical SQL80%

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

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

ETL vs ELT80%

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

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

Batch and Streaming80%

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

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

Spark80%

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

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

Kafka80%

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

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

ML Pipelines80%

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

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

Data Versioning80%

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

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