Боюсь, что Airflow ПОЛНОСТЬЮ связан с планированием на основе времени.
Вы можете установить расписание на None, а затем использовать API для запуска прогонов , но вы это сделаетевнешне, и, таким образом, поддерживая количество и состояния, определяющие, когда и почему следует запускать извне.
Когда вы говорите, что у вашей группы обеспечения доступности баз данных может быть 5 задач, выполнение которых вы хотите выполнить 10 раз, а запуск занимает 2 часа, а вы не можетепланировать это на основе времени, это сбивает с толку.Мы понятия не имеем, что для вас значит 2 часа, или почему это должно быть 10 запусков, и почему вы не можете запланировать выполнение этих 5 задач один раз в день.При простом ежедневном расписании он будет запускаться один раз в день примерно в одно и то же время, и не имеет значения, что в любой день это займет чуть больше 2 часов.Правильно?
Вы можете установить start_date на 11 дней назад (хотя фиксированная дата не устанавливается динамически) и end_date на сегодня (также фиксированное значение), а затем добавить ежедневную schedule_interval и max_active_runs из 1, и вы получите ровно 10 прогонов, и он будет запускать их спина к спине без наложения, при этом соответственно изменяя execution_date, затем остановится.Или вы можете просто использовать airflow backfill с None запланированной группой обеспечения доступности баз данных и диапазоном времени выполнения.
Вы хотите сказать, что хотите, чтобы он работал непрерывно каждые 2 часа, но иногда он будет работать дольше иВы не хотите, чтобы это перекрывало пробеги?Что ж, вы определенно можете запланировать его запуск каждые 2 часа (0 0/2 * * *) и установить для max_active_runs значение 1, чтобы, если предыдущий запуск не завершился, следующий цикл ожидал, а затем стартует после завершения предыдущего.,См. Последний пункт в https://airflow.apache.org/faq.html#why-isn-t-my-task-getting-scheduled.
Если вы хотите, чтобы ваша группа обеспечения доступности баз данных работала ровно каждые 2 часа на точке [дайте или возьмите некоторую задержку планировщика, да, это так], и оставьте предыдущий запуск в рабочем состоянии, этов основном это поведение по умолчанию, но вы можете добавить depends_on_past к некоторым важным задачам, которые сами не должны выполняться одновременно (например, создание, вставка или удаление временной таблицы), или использовать пул с одним слотом.
Нет функции убить предыдущий запуск, если ваш следующий график готов к запуску.Возможно, можно пропустить текущий прогон, если предыдущий еще не завершен, но я забываю, как именно это делается.
Это в основном большинство ваших вариантов.Также вы можете создать руководство dag_run s для внеплановой DAG;создавая 10 в то время, когда вы чувствуете, что хотите (используя интерфейс или CLI вместо API, но API может быть проще).
Есть ли какие-либо из этих предложений для решения ваших проблем?Поскольку непонятно, зачем вам нужно фиксированное количество прогонов, как часто или с каким расписанием и условиями, сложно дать конкретные рекомендации.