Ну проще запустить параллельно 2 airflow и поочередно переносить даги,

не? Сломался - тут же разбираешься почему. А да! Обновления AF как-то кривовато работает. Хызы почему. Не стали разбираться

Можно, но один общий Airflow на всю компанию этот процесс только усложняет (изначальный поинт именно в этом). Во-первых, он резко перестает быть одним, все начинают путаться, что у них где, что перенесено и что нет. Во-вторых, всех подгоняют с обновлением на новую версию, потому что старый инстанс будет отключен через N дней. Но не все команды могут выделить время на такие процедуры, им нужно перенести ресурсы с остальных своих задач, и обновление затягивается. В-третьих, в новых версиях могут быть баги в самом Airflow или операторах, которые не позволяют некоторым командам перейти на новую версию, и они вынуждены оставаться на старой. И чем больше разных пользователей в одном Airflow, тем больше там разных операторов, и выше вероятность таких проблем, соответственно перенос затягивается ещё сильнее. Добавим сюда ещё и вопрос постоянной синхронизации connection, variables между разными инстансами (кто главнее, старый инстанс или новый?). В общем, зачастую такие подходы превращаются в какое-то мессиво с непонятным сроком окончания, все орут и толкаются, как в электричке на дачу в пятницу вечером. А если у каждой команды свои Airflow, то они сами могут решать, с какой скоростью они могут все обновить. У них меньше дагов для переноса, соответственно меньше разных операторов, connection, variables, и связанных с ними проблем.

ну вообще, имхо. все зависит от количества дагов и бюджета (как обычно). месиво может быть, но по сути это вопрос организационный. проблемы уменьшаются, если переводом на новую версию занимается одна команда а не несколько. о том, что "будет отключен через N дней" тема еще та. зачем торопливость нужна, не понимаю. Но вообще согласен - один airflow на всю компанию, несколько неудобно.через определенное время разбираться в чужих дагах очень сложно. особенно если их накопилось много.

> если переводом на новую версию занимается одна команда Только команда, которая написала даг, знает в деталях, как он работает, и соответственно как решать проблемы, связанные с его переносом на новую версию Airflow. Откуда все эти нюансы знать команде поддержки самого Airflow? > зачем торопливость нужна Без дедлайна никто переходить на новый инстанс не будет, всегда есть дела поважнее

в большинстве случаев, коренного различия нет между версиями. ну может разве синтаксис питона поменяется 😉. Классы базовые не особо меняются. пока особо не встречал. чтобы что-то не работало прям совсем. Если хардкода нет в дагах, то плюс-минус все лечится. а зачем вообще кого-то оповещать о том что они будут переходить на новый инстанс? перевели даг - сказали, перевели - сказали. новые даги - пишут только под новую версию. Вопрос организационный , не более.. Проблема может возникнуть если денег не дают на два параллельных инстанса AF. Вот в этом случае да, тут 100500 раз подумаешь надо ли переводить. А в целос, я пока только сплошные бенефиты вижу от перевода на более новые версии. Динамический маппинг тасков, потом динамический маппинг групп появился. ну и т.д.

> зачем вообще кого-то оповещать о том, что они будут переходить на новый инстанс? Лол, как это должно работать? Адрес нового инстанса в мозг телепатией передается? Никто не будет задавать вопросы, какие даги вообще актуальные и нужно переносить, и будет перенесено все подряд, даже нерабочее старье? А если даг сейчас в активной фазе доработки, но его уже перенесли в старой версии, не консультируясь с DE? Как насчёт TriggerDagOperator? Как насчёт мониторинга запусков дагов и тасок?

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

CICD

Давайте на чистоту, многие DE давно поняли, что airflow - это оркестратор, а не etl. Поэтому, в большинстве своем, у нормальных людей таски в изоляции контейнеров и никак не зависят от самого airflow... Править надо только логику, если она меняется у самого airflow, возможно проблемы с коннектами к другим базам из-за смещения провайдеров. Все остальное, что вы описали как проблема - не проблема 😬

У вас большие проблемы с пониманием ci/cd и его реализацией...

И это прекрасно, если все так и обстоит. Но реальность бывает менее радужная, а давать советы вида "у нас один Airflow на всех, и нам норм" так вообще за гранью

Громкие слова

Ну перенос настроек теоретически тоже можно впихнуть в cicd. Но настройки делаются один раз при настройке AF. Далее, тут происходит путаница. Одно дело апгрейд AF, другое - написание дагов и третье деплой этих дагов. Надо разделить эти вещи и все. Для меня лично, один или несколько af это всего-лишь вопрос управления AF. Отслеживать 30 дагов намного легче чем 400. Поэтому да, я бы использовал несколько. Но исключительно из-за удобства.

Разделение да, но обновление Airflow затрагивает все части пазла

Так раздельные инстансы шедулеров и всего остального как раз помогают. Команда Ы взяла и перешла. Команда Х еще два года сидит на старом стеке и путоне 2 т.к. на техдолг нет времени Все довольны 🤷‍♂

Начистоту если - все давно поняли, но никто ничо с этим не делает, пишут как писали до. И все в одном виртуалэнв монстре 😁

С чего помогает? Все усложняется поддержкой 100500 стендов со 100500 версий и психологию людей этим не обойти...

Зависит от того, как исторически сложилось. В разных командах вообще разные шедулеры могут быть, каждая свой поддерживает а на остальных плевать Все сцепленно только внешними триггерами и данными в таблицах

Эт если 1 централизованная команда дагописателей