#airflow #airflow-scheduler
#воздушный поток #воздушный поток-планировщик
Вопрос:
Я использую Airflow 1.10.10 и хотел бы знать, как изменить расписание Aiflow DAG. Я проверил онлайн, и в большинстве комментариев было предложено, чтобы изменить расписание группы баз данных, создать новую группу баз данных с новым dag_id или изменить dag_id существующей группы баз данных и предоставить новое schedule_interval . Попытка изменить расписание существующего DAG не будет работать прямым образом и выдаст ошибку или может создать ошибку планирования.
Однако я попытался протестировать это, чтобы я мог создать сценарий, в котором мое изменение расписания DAG приводит к ошибочным случаям. Это я попробовал, только изменив schedule_interval в файле DAG. Я попробовал ниже изменить расписание в моем DAG, и все работало, как ожидалось. Расписание было изменено правильно, и ошибка не была найдена .
- Начал с @Daily
- Изменено на 10 минут
- Изменено на 17 минут
- Изменено на 15 минут
- Изменено на 5 минут
Может кто-нибудь, пожалуйста, уточнить, какая проблема может возникнуть, если мы изменим schedule_interval в DAG без изменения идентификатора.
Комментарии:
1. Я думаю, что основная проблема заключается в том, что вы пытаетесь выполнить обратную засыпку после того, как вы изменили расписание после нескольких отключений
2. @SimonDarr не могли бы вы поделиться любыми несоответствиями, с которыми вы могли столкнуться, когда вы изменили расписание DAG без изменения dag_id. Я использую catchup=False для предотвращения обратной засыпки, поэтому запуски обратной засыпки для меня не проблема. Но мне интересно, помимо этого, может ли возникнуть какая-либо другая проблема из-за изменения в schedule_interval DAG.
3. Вы должны быть в порядке, если вы не засыпаете
Ответ №1:
Я вижу эту рекомендацию на старой странице слияния потоков о распространенных ошибках.
При необходимости изменить начальную дату и интервал расписания, измените имя базы данных (он же dag_id) — я следую соглашению: my_dag_v1, my_dag_v2, my_dag_v3, my_dag_v4 и т.д…
- Изменение интервала расписания всегда требует изменения идентификатора dag_id, поскольку ранее выполненные TaskInstances не будут совпадать с новым интервалом расписания
- Изменение start_date без изменения schedule_interval безопасно, но изменение на более раннюю start_date не приведет к созданию новых DagRuns за время между новой start_date и старой, поэтому задачи не будут автоматически возвращаться к новым датам. Если вы вручную создаете DagRuns, задачи будут запланированы, если дата DagRun находится после даты начала задачи и даты начала базы данных.
Я не знаю намерения автора, но я полагаю, что изменение schedule_interval может вызвать путаницу у пользователей. Когда они вернутся к этой задаче, они зададутся вопросом, почему текущий schedule_interval не соответствует прошлым выполнениям задачи, потому что эта информация не хранится на уровне задачи.
Изменение schedule_interval не влияет на прошлые dagruns или задачи. Изменение повлияет на создание новых dagruns, что повлияет на задачи в этих dagruns.
Я лично не изменяю идентификатор dag_id при обновлении scheduler_interval в DAG scheduler_interval по двум причинам.
- Если я сохраню предыдущую базу данных, я излишне создаю дополнительную нагрузку на планировщик для обработки DAG, которая не будет включена.
- Если я не сохраню предыдущую базу данных, я, по сути, потеряю всю историю dagrun, где у него был другой schedule_interval.
Редактировать: похоже, что существует проблема с Github, созданная для перемещения страницы Common Pitfall, но она устарела.
Комментарии:
1. спасибо за ваш ответ . Итак, из того, что я понимаю из этого, заключается в том, что изменение schedule_interval в DAG может создать путаницу для пользователей, поскольку запланированные запуски будут выполняться для разных временных меток. Но не могли бы вы также поделиться некоторым светом ниже. 1) Не могли бы вы пояснить, что вы подразумеваете под «Изменением, которое повлияет на создание новых dagruns, что влияет на задачи в этих dagruns». Какое влияние вы имеете в виду здесь. 2) И не возникало ли у вас каких-либо проблем, если вы меняете schedule_interval только для DAG без изменения идентификатора DAG.
2. 1) Изменение, о котором идет речь, является execution_date . execution_date зависит от scheduler_interval. 2) Я не заметил никаких проблем при изменении только scheduler_interval, кроме потенциальных недоразумений, упомянутых выше. Я использовал с 1.8.1 по 2.0.0 и смог изменить schedule_interval, не нарушая мои базы данных.
3. @AlanMa Я попытался обновить schedule_interval и могу видеть его обновленным в столбце «расписание» в пользовательском интерфейсе, но столбец «Следующий запуск» по-прежнему вычисляется из предыдущего schedule_interval. Наблюдали ли вы подобное поведение?