У нас одно из слабых мест airflow — это шедулер. Время от времени он не справляется с несовершенством некоторых дагов и падает. Поэтому у нас на Кроне стоит проверка его состояния и перезапуск при необходимости (с несовершенствами мы тоже работаем, конечно :) ). Если бы я кого и подозревала в ситуации, которая у вас сложилась, так это его. Может в его логах можно что-нибудь раскопать?
Ещё я бы посмотрела на параметры вроде этого:
# The scheduler constantly tries to trigger new tasks (look at the
# scheduler section in the docs for more information). This defines
# how often the scheduler should run (in seconds). scheduler_heartbeat_sec = 5
Мы, кстати, довольно много внимания уделяем pool'ам, в которых запускаются задачи и priority_weight, которые помогают ранжировать таски в очереди по приоритетам. Это не совсем в тему данной проблемы, но, например, выделение тяжёлых тасков в отдельный pool с ограничением максимального количества одновременно-запущенных задач может в будущем уберечь от пиков загрузки сервера.
Варианты решения вашей проблемы, которые мне пришли в голову:
* Нужно ли вам, чтобы все дни стартовали одновременно? Если нет, можно выставить параметр дага depends_on_past в True, тогда таски последующих дней не будут становиться в очередь, пока эти же таски в предыдущем дне не выполнятся.
* Параметризация дагов. У нас есть несколько проектов, по которым данные на источнике меняются задним числом. Иногда нам нужно забирать данные за довольно большой период времени. Тогда мы вешаем переключение логики на параметр airflow: обычно это или флаг «пересчитать всю историю» или дата, начиная с которой нужно забрать все данные. И в даге зашиваемся на этот параметр. Но это как раз вариант с баш-скриптом, наверное.
На понимание темы на уровне рекомендаций в разных ситуациях я пока не претендую.
А если рассматривать конкретно наш регламент, это достаточно скучное чтиво вроде чтения ГОСТ'ов. Два главных момента — удобство и последовательное их соблюдения — кажутся очевидными. Можно при случае обсудить.
Это вполне себе вариант, но тогда Airflow вырождается в планировщик задач на Питоне.
Основное преимущество использования всех встроенных возможностей Airflow на мой взгляд — это простая локализация ошибки. Можно с одного взгляда понять, что пропал доступ к источнику или задача в соседнем таске никак не может просчитаться и после починки перезапустить только эту часть.
Что же касается костыликов и хитросплетений, во-первых, у нас есть регламент, согласно которому мы называем задачи и используем те или иные сенсоры и операторы, а во-вторых, тяжёлую повторяющуюся логику мы инкапсулируем в самописные операторы.
У нас код дагов лежат в гите, мы их разрабатываем локально и после внесения изменений обновляем на сервере.
Что касается сбрасывания кеша, я не поняла, что имеется ввиду. Если обновление дага по свежему коду, то пользуемся кнопкой «Обновить» в веб-интерфейсе.
Согласна с seidzi, airflow очень гибкий. Хотя и без недочётов.
У нас гриб появляется в трёх случаях:
— когда в даге что-то не в порядке и тогда мы используем консольную команду list_dags, чтобы выяснить, что именно;
— при маркировке mark success за большое количество дней;
— при большом или неправильном запросе при работе с источниками напрямую, через интерфейс Ad Hoc Query.
Про сабдаги я сказать ничего не могу, мы ими ещё не пользовались.
Что касается альтернативы, из предложенных open source продуктов слышала хорошие отзывы о Luigi. Он попроще, чем airflow, но для некоторых задач подходит лучше.
Присоединяйтесь!
Ещё я бы посмотрела на параметры вроде этого:
# The scheduler constantly tries to trigger new tasks (look at the
# scheduler section in the docs for more information). This defines
# how often the scheduler should run (in seconds).
scheduler_heartbeat_sec = 5
Мы, кстати, довольно много внимания уделяем pool'ам, в которых запускаются задачи и priority_weight, которые помогают ранжировать таски в очереди по приоритетам. Это не совсем в тему данной проблемы, но, например, выделение тяжёлых тасков в отдельный pool с ограничением максимального количества одновременно-запущенных задач может в будущем уберечь от пиков загрузки сервера.
Варианты решения вашей проблемы, которые мне пришли в голову:
* Нужно ли вам, чтобы все дни стартовали одновременно? Если нет, можно выставить параметр дага depends_on_past в True, тогда таски последующих дней не будут становиться в очередь, пока эти же таски в предыдущем дне не выполнятся.
* Параметризация дагов. У нас есть несколько проектов, по которым данные на источнике меняются задним числом. Иногда нам нужно забирать данные за довольно большой период времени. Тогда мы вешаем переключение логики на параметр airflow: обычно это или флаг «пересчитать всю историю» или дата, начиная с которой нужно забрать все данные. И в даге зашиваемся на этот параметр. Но это как раз вариант с баш-скриптом, наверное.
А если рассматривать конкретно наш регламент, это достаточно скучное чтиво вроде чтения ГОСТ'ов. Два главных момента — удобство и последовательное их соблюдения — кажутся очевидными. Можно при случае обсудить.
Основное преимущество использования всех встроенных возможностей Airflow на мой взгляд — это простая локализация ошибки. Можно с одного взгляда понять, что пропал доступ к источнику или задача в соседнем таске никак не может просчитаться и после починки перезапустить только эту часть.
Что же касается костыликов и хитросплетений, во-первых, у нас есть регламент, согласно которому мы называем задачи и используем те или иные сенсоры и операторы, а во-вторых, тяжёлую повторяющуюся логику мы инкапсулируем в самописные операторы.
Что касается сбрасывания кеша, я не поняла, что имеется ввиду. Если обновление дага по свежему коду, то пользуемся кнопкой «Обновить» в веб-интерфейсе.
У нас гриб появляется в трёх случаях:
— когда в даге что-то не в порядке и тогда мы используем консольную команду list_dags, чтобы выяснить, что именно;
— при маркировке mark success за большое количество дней;
— при большом или неправильном запросе при работе с источниками напрямую, через интерфейс Ad Hoc Query.
Про сабдаги я сказать ничего не могу, мы ими ещё не пользовались.
Что касается альтернативы, из предложенных open source продуктов слышала хорошие отзывы о Luigi. Он попроще, чем airflow, но для некоторых задач подходит лучше.