Обратное заполнение конвейера под нагрузкой: как не уронить прод

Обратный прогон исторических данных может занять мощности, которыми в это время пользуется текущий конвейер. Если запустить весь диапазон сразу, очередь растёт, свежие данные задерживаются, а база или приёмник получают больше запросов, чем выдерживают. Ниже — как оценить риск и ограничить прогон; примеры организационных решений относятся к Apache Airflow 2.10.x, но не зависят от конкретного командного интерфейса.

Почему исторические задачи мешают текущим

При обычной работе конвейер обрабатывает новые интервалы по мере поступления данных. Обратное заполнение — backfill — запускает тот же процесс для интервалов в прошлом. Например, после исправления преобразования нужно пересчитать несколько месяцев событий. Даже если отдельная задача быстрая, сотни исторических интервалов создают дополнительную конкуренцию за ресурсы.

Нагрузка обычно упирается не только в вычислительные мощности. Задачи могут одновременно читать одни и те же таблицы, открывать соединения, писать данные в один приёмник и обращаться к внешнему API. В результате страдает не обязательно сам backfill: первыми задерживаются свежие запуски, растёт время запросов к хранилищу или срабатывают ограничения принимающей системы.

Термин: идемпотентность — свойство операции, при котором повторный запуск с теми же данными не создаёт лишних эффектов. Для backfill это важно: задачу могут перезапустить после сбоя, а частично записанный результат — придётся обработать повторно.

Сначала определите, что именно защищаете

До запуска зафиксируйте ограничения текущего конвейера. Важно знать не абстрактное количество задач, а узкое место и допустимое для него поведение: задержку свежих данных, доступный пул соединений, лимит запросов или время записи. Пороговые значения берите из наблюдений за своей системой и договорённостей с владельцем хранилища, а не из универсальной рекомендации.

• Проверьте длительность интервалов. Оцените, сколько задач появится за весь период и как долго обычно выполняется одна задача. Не считайте, что исторические интервалы одинаковы: объём данных мог меняться.
• Найдите общие ресурсы. Отметьте базы, очереди, API, файловые хранилища и таблицы, которыми одновременно пользуются текущий поток и пересчёт.
• Определите признак перегруза. Например, это рост задержки свежих запусков, числа ошибок соединения или времени записи. Выберите метрики, которые доступны в вашей системе, и договоритесь, при каком изменении прогон нужно остановить или замедлить.
• Проверьте повторный запуск. Убедитесь, что запись результата не удваивает данные и что можно отличить завершённый интервал от частично обработанного.

В Apache Airflow 2.10.x один из инструментов изоляции задач — pools, то есть пулы слотов для ограничения параллельной работы выбранных задач. Но пул помогает только тогда, когда задачи действительно привязаны к нему, а его размер согласован с ресурсом, который нужно защищать. Ограничение количества активных запусков DAG решает более общий вопрос конкуренции, но само по себе не гарантирует безопасную нагрузку на конкретную базу.

Три режима прогона и их цена

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

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

Как запускать и контролировать прогон

1. Зафиксируйте границы пересчёта. Укажите начальный и конечный интервал, версию логики обработки и ожидаемый результат. Проверьте, что границы соответствуют именно тем временным окнам, которые использует конвейер. Проверка: список интервалов можно сверить с заданием на пересчёт, и в нём нет лишних дат.
2. Начните с небольшого участка. Выберите репрезентативный отрезок, включающий обычные данные и известные тяжёлые периоды. Проверка: результат прошёл сверку по числу записей, контрольным суммам или бизнес-показателям, которые используются в вашем проекте.
3. Ограничьте параллельность на уровне общего ресурса. Если задачи одновременно пишут в одну базу, контролируйте конкуренцию именно за эту базу, а не только число запусков всего конвейера. Проверка: при пробном прогоне свежие задачи остаются в пределах согласованной задержки.
4. Увеличивайте объём постепенно. После пробного участка расширяйте диапазон, сохраняя тот же контроль метрик. Проверка: время выполнения и очередь не ухудшаются от интервала к интервалу, а ошибки не накапливаются.
5. Сверьте итог и зафиксируйте точку остановки. После завершения сравните обработанные интервалы с планом и проверьте состояние приёмника. Проверка: каждый интервал имеет подтверждённый результат, а повторный запуск не создаёт дубликаты.

Увеличивать число одновременных задач стоит только после того, как видно, что именно ограничивает скорость. Если узкое место — лимит запросов к API, добавление вычислителей лишь ускорит достижение этого лимита. Если задачи в основном ждут ввода-вывода, причина может быть в хранилище или сети, а не в нехватке процессорного времени.

Что ломается первым

Новые данные застревают в очереди

Это сигнал, что исторические задачи занимают слоты или ресурсы, нужные свежему потоку. Снизьте параллелизм backfill либо выделите ему отдельные ресурсы. Не ориентируйтесь только на успешное завершение старых задач: важнее, сохраняется ли допустимая задержка актуальных данных.

Приёмник отвечает ошибками или замедляется

Проверьте лимиты соединений, частоту записи и размер отдельных операций. Если система-приёмник ограничивает частоту запросов, нужно учитывать это ограничение явно и согласовать режим с её владельцем. Повторы после ошибки тоже создают нагрузку, поэтому проверьте, не запускаются ли повторные попытки одновременно для большого числа задач.

Повторный запуск создаёт дубликаты

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

Нагрузка различается от интервала к интервалу

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

Где подход ломается

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

Отдельный риск — изменения справочников и логики между исходной обработкой и пересчётом. Backfill может пересчитать прошлые события по новым правилам и получить результат, отличный от того, что система выдала тогда. Решите заранее, нужна ли историческая реконструкция по текущей логике или воспроизведение прежнего результата; это разные требования, и один лишь повторный запуск их не разрешает.

Если используется Apache Airflow другой версии или другой оркестратор, сверяйте доступные ограничения и поведение повторного запуска с документацией именно своей версии. Здесь описана стратегия управления нагрузкой, а не готовая команда для запуска: названия параметров и детали управления backfill зависят от инструмента и релиза.

Что делать дальше

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