Воздушный поток Этот DAG недоступен в объекте DagBag веб-сервера

когда я помещаю новый скрипт Python DAG в папку dags, я могу просмотреть новую запись DAG в пользовательском интерфейсе DAG, но она не была включена автоматически. Вдобавок к этому, похоже, тоже не загружается должным образом. Я могу только несколько раз нажать кнопку «Обновить» в правой части списка и переключить кнопку включения / выключения в левой части списка, чтобы иметь возможность запланировать DAG. Это ручной процесс, так как мне нужно что-то запустить, даже если сценарий DAG был помещен в папку dag.

Кто-нибудь может мне в этом помочь? Я что-то пропустил? Или это правильное поведение в обдуве?

Между прочим, как упоминалось в заголовке сообщения, есть индикатор с этим сообщением «Этот DAG недоступен в объекте DagBag веб-сервера. Он отображается в этом списке, потому что планировщик пометил его как активный в базе данных метданных» с пометкой с заголовком DAG, прежде чем запускать весь этот ручной процесс.

santi 10.01.2017 источник

comment

Попробуйте перезапустить веб-сервер воздушного потока. Если это не помогает, попробуйте сделать airflow backfill '<dag_id>' -s '<date>' -e '<date>' для той же даты, что и начало и конец. Это должно запустить рабочий процесс один раз и устранить проблемы с пользовательским интерфейсом. - Dmitri Safine 10.01.2017

comment

Я думаю, что другие представления зависят от данных, созданных планировщиком, анализирующим файл dag. Если у вас их больше сотни, это может занять несколько минут. Это полностью зависит от того, сколько работы вы делаете в непосредственном контексте всех файлов dag, насколько быстро они могут быть обработаны в цикле. - dlamblin 10.12.2018

Ответы (5)

arrow_upward
16
arrow_downward

Это не вы, это не правильное или ожидаемое поведение. Это текущая «ошибка» с Airflow. Веб-сервер кэширует DagBag таким образом, что вы не можете использовать его должным образом.

"Attempt removing DagBag caching for the web server" остается в официальном TODO как части дорожной карты , что указывает на то, что, возможно, эта ошибка еще не полностью устранена, но вот несколько советов о том, как действовать:

использовать только строители в Airflow v1.9 +

До airflow v1.9 это происходило, когда dag создается функцией, которая импортируется в файл, в котором происходит создание экземпляра. То есть: когда строитель или factory. Некоторые сообщения об этой проблеме на github 2 и JIRA 3 привел к исправление, выпущенное в airflow v1.9.

Если вы используете старую версию воздушного потока, не используйте функции компоновщика.

`airflow backfill`, чтобы перезагрузить кеш

Как предлагает Дмитрий, иногда может помочь выполнение airflow backfill '<dag_id>' -s '<date>' -e '<date>' с одной и той же датой начала и окончания. После этого вы можете столкнуться с (не) проблемой, на которую указывает Приянк, но это ожидаемое поведение (состояние: приостановлено или нет) в зависимости от конфигурации вашей установки.

Guille 12.05.2017

arrow_upward
16
arrow_downward

Перезагрузка airflow webserver решает мою проблему.

cozyss 17.07.2018

comment

это исправило это для меня! - richddr; 21.11.2018

comment

Возникла та же проблема в airflow v1.9 при попытке импортировать настроенный оператор плагина в один DAG и перезапустить веб-сервер airflow, что решило проблему для меня. - Kun Wang; 09.01.2019

arrow_upward
3
arrow_downward

Эта ошибка может вводить в заблуждение. Если нажатие кнопки обновления или перезапуск airflow webserver не устраняет эту проблему, проверьте DAG (скрипт python) на наличие ошибок.

Запуск airflow list_dags может отображать ошибки DAG (в дополнение к перечислению dags) или даже пытаться запустить / протестировать ваш dag как обычный скрипт python.

После исправления ошибки этот индикатор должен исчезнуть.

rahul 24.09.2020

comment

Это было для меня, спасибо. - Abhishek Dalvi; 01.04.2021

arrow_upward
2
arrow_downward

Проблема заключается в том, что группа DAG по умолчанию помещается в DagBag в приостановленном состоянии, так что планировщик не перегружен большим количеством операций обратной засыпки при запуске / перезапуске.

Чтобы обойти эту проблему, измените следующие настройки в файле airflow.cfg:

# Are DAGs paused by default at creation 
dags_are_paused_at_creation = False

Надеюсь это поможет. Ваше здоровье!

Priyank Mehta 17.02.2017

comment

проблема все еще возникает с этой настройкой - hoju; 06.11.2017

comment

Это не проблема OP - cozyss; 18.07.2018

arrow_upward
2
arrow_downward

У меня есть теория о возможной причине этой проблемы в Google Composer. В документации по устранению неполадок для Композитор, в котором говорится:

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

И я пытался загрузить конфигурацию из внешнего источника (что на самом деле занимало незначительное количество времени по сравнению с другими операциями по созданию DAG, но все же что-то сломало, потому что веб-сервер Airflow в композиторе работает на App Engine, что ведет к странному поведению).

Я нашел обходной путь при обсуждении этой проблемы Google, и это создание отдельного DAG с задачей который загружает все необходимые данные и сохраняет их в переменной воздушного потока:

Variable.set("pipeline_config", config, serialize_json=True)

Тогда я мог бы сделать

Variable.get("pipeline_config", deserialize_json=True)

И успешно сгенерировать из этого конвейер. Дополнительным преимуществом является то, что я получаю журналы этой задачи, которые я получаю с веб-сервера, из-за этой проблемы .

Bunyk 13.12.2018

comment

спасибо, что ответили конкретно на Composer. Главный ответ на перезапуск airflow webserver в этом случае не сработает. - cryanbhu; 21.08.2019