Задача воздушного потока с нулевым статусом - PullRequest
Новая
       21

Задача воздушного потока с нулевым статусом

0 голосов
/ 15 ноября 2018

У меня проблема с воздушным потоком при работе его на 24-часовой машине на EC2.

Должен отметить, что уровень параллелизма равен 256.

В течение нескольких дней дагрун заканчивается со статусом «не удалось» по двум неопределенным причинам:

  1. Некоторая задача имеет статус «upstream_failed», что не соответствует действительности, поскольку мы ясно видим, что все предыдущие шаги были успешными. enter image description here

  2. Другие задачи не имеют статуса «ноль», они еще не запущены и вызывают сбой dagrun. enter image description here

Я должен отметить, что журналы для обеих этих задач пусты

enter image description here

И вот подробности tast для этих случаев:

enter image description here

Есть какие-нибудь решения, пожалуйста?

Ответы [ 2 ]

0 голосов
/ 27 февраля 2019

Другой случай, когда я столкнулся со вторым условием («Другие задачи не имеют статуса« ноль »»), - это когда экземпляр задачи изменился и специально изменил тип оператора.

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

Пример:

  • Экземпляр задачи изначально является экземпляром оператора SubDag
  • Требования приводят к изменению типа оператора с оператора SubDag на оператор Python
  • После изменения оператор Python устанавливается в состояние NULL

Как я могу собрать воедино, то, что происходит:

  • Воздушный поток анализирует оператора, связанного с каждой задачей
  • Каждый экземпляр задачи регистрируется в таблице базы данных. task_instance
    • Эта таблица имеет атрибут с именем operator
  • Когда планировщик повторно анализирует код, он ищет task_instance с правильным типом оператора; не видя его, он обновляет соответствующие записи базы данных как состояние = 'удалено'
  • Когда DAG впоследствии планирует, поток воздуха

Вы можете увидеть задачи, затронутые этим процессом, с помощью запроса: 

SELECT *
FROM task_instance
WHERE state = 'removed'

Похоже, что работали над этой проблемой для потока воздуха 1.10:

При этом, я не уверен на 100% на основании коммитов, которые я могу найти, чтобы решить эту проблему. Похоже, что общая философия по-прежнему "при изменении DAG вы должны увеличить / изменить имя DAG" .

Мне не нравится это решение, потому что оно затрудняет итерацию того, что по сути является одним конвейером. Альтернатива, которую я использовал, состояла в том, чтобы (частично) следовать рекомендациям от астронома и «уничтожить» историю DAG. Для этого вам необходимо:

  • Остановить планировщик
  • Удалить историю из даг
    • Это должно привести к полному исчезновению DAG из веб-интерфейса.
    • Если он не исчезает полностью, где-то планировщик все еще работает
  • Перезапустите планировщик
    • Примечание: если вы работаете с DAG по расписанию, будьте готовы к тому, что он засыпает / захватывает / запускает свое последнее расписание, поскольку вы удалили историю
    • Если вы не хотите, чтобы это делалось, Astronomer может предложить "Fast Forward a DAG"
0 голосов
/ 16 ноября 2018

Это может произойти, когда состояние задачи было изменено вручную (вероятно, с помощью параметра «Отметить успех») или принудительно переведено в состояние (как в upstream_failed), и задача никогда не получает значение hostname в записи ине было бы никаких журналов или PID

...