Airflow "Эта DAG недоступна в веб-сервере DagBag object"

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

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

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

Ответ 1

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

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

использовать только строителей в воздушном потоке v1. 9+

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

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

перезагрузка `airflow backfill` для перезагрузки кеша

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

Ответ 2

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

Чтобы обойти это изменение, установите ниже в файле airflow.cfg:

# Are DAGs paused by default at creation 
dags_are_paused_at_creation = False

Надеюсь это поможет. Ура!

Ответ 3

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

Ответ 4

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

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

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

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

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

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

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

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