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