Проблема

Ночной пайплайн собирал события из нескольких источников в BigQuery и каждую ночь занимал около 6 часов — время, за которое стоимость Slot-часов и риск не успеть к утренним отчётам росли параллельно. Схема не менялась почти год, но объём данных вырос почти в 5 раз.

Диагностика

Профилирование показало три конкретные причины:

  • полное пересчитывание витрин вместо инкрементальной загрузки;
  • один гигантский DAG в Airflow без параллельных веток;
  • отсутствие партиционирования и кластеризации на исходных таблицах.

Что изменили

  1. Партиционирование по дате и кластеризация по ключу события — сканирование сузилось до нужного окна вместо полной таблицы.
  2. Инкрементальная загрузка вместо полного пересчёта: обрабатывали только новые и изменённые записи.
  3. Разбили DAG на независимые ветки, которые Airflow теперь исполняет параллельно, а не последовательно.

Результат

Пайплайн стал укладываться в 35–40 минут — то есть почти в 10 раз быстрее — а стоимость обработки в BigQuery упала примерно на 60%, потому что каждый прогон сканирует на порядок меньше данных.

Если у вас похожая картина — ночной пайплайн, который со временем "распух" вместе с объёмом данных — обычно это тот же самый набор причин. Расскажите о своей задаче, обсудим, что применимо у вас.