Как-то один из самых главных контрибьюторов в Airflow Ярек Потиюк рассказал, что Airflow 3 станет новым золотым стандартом индустрии. Это довольно смелое заявление. Я же считаю, что в Airflow 3  еще многого не хватает, чтобы действительно стать стандартом.

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

Airflow - это платформа с открытым исходным кодом для написания и управления рабочих процессов. Airflow была основана в 2014 году в AirBnB. С тех пор платформа прошла путь до версии 1.0 в 2015 году, стала Apache Top Level Project в 2019 и плотно обосновалась как Enterprise Production-Ready в 2020 с версией 2.0.

Что мы хотим больше всего

Каждый год в сообществе Apache Airflow проводят опрос. Я этот опрос видел только один раз, случайно заглянув в канал Slack, посвященный Airflow. Один из вопросов поста звучал так: “Какую фичу вы хотели бы видеть в Airflow?”

Вот топ ответов из этого опроса:

Версионирование DAGов

Вот уже третий год подряд этот нерешенный вопрос занимает первую строчку опроса, несмотря на сотни закрытых issues на GitHub со ссылкой на этот AIP (Airflow Improvement Proposal), в том числе и от меня. А фичи до сих пор нет.

Каждому, кто достаточно долго пользуется Airflow, хочется видеть версирование. Мне оно нужно хотя бы для того, чтобы я мог переименовать DAG и сохранить всю историю запусков. 

Больше Data Lineage

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

Мультитенантность

Для больших команд эта функциональность очень полезна. В Google Cloud Composer уже добавили эту фичу, но из коробки мы такого не получаем.

Добавление новых DAGов через API

Это интересный запрос, учитывая, что вся суть создания Airflow DAG заключается в чтении файлов в файловой системе. В своем докладе 4 лайфхака, которые помогут вам эффективно использовать конвейеры AirFlow • Александр Шелютин я рассказывал про несколько способов, которыми можно так сделать.

Изоляция задач

Это тоже один из слонов в комнате. Как мы знаем, worker Airflow имеет полный доступ к базе метаданных, поэтому из задачи мы можем сделать с этой базой все, что угодно - прочитать пароли из любого Connection, получать доступ к выполнению любых задач, и даже удалять таблицы!

Больше поддержки для DataSets и Data-Driven запуски

Лично мне не нравится DataSet API, так как данные приходится вводить дважды: один раз для задачи, второй раз для DataSet API. Поэтому легко допустить ошибку. 

При этом я слышал о нем множество хвалебных отзывовов, в том числе и о помощи с Data Lineage и упрощении Data-Driven запусков (раньше нужно было отдельно вызывать TriggerDagRunOperator).

Что нам обещают

Я специально просмотрел несколько докладов по Airflow 3, которые все, как один, почему-то называются “Airflow 3 is Coming”. Видимо отсылка к “Игре престолов”.

Итак, что же нам обещают?

Версионирование DAGов

“Ура!”, подумал я, прежде чем посмотреть доклад про текущее состояние и реализацию фичи. Судя по докладу, решены далеко не все концептуальные вопросы.

Если коротко, то появилось новое понятие, известное как DAG Bundle. DAG Bundle - это все Python-файлы и другие файлы, которые определяют ваш DAG. Каждый Task Instance будет использовать определенный DAG Bundle для запуска. 

Разработчики считают, что для хранения и обработки всех этих DAG Bundle нужно будет отдельное выделенное пространство и DAG Bundle Backend. Естественно, они упомянули и про то, что Git DAG Bundle Backend станет стандартом для версионирования, но они не хотели зацикливаться на Git.

Также упомянули Blob Bundle Backend, но он не будет готов к релизу. Причем, по состоянию на 12 сентября 2024 года, даже Git DAG Bundle Backend не готов. 

Еще одно новое понятие - DAG Bundle Manifest. Это yaml-файл, который помогает кастомизировать обновление разных директорий из DAG Bundle. Это тоже нововведение, которое позволит хранить разные директории на разных источниках или сервисах.

Но есть одно но: все это не работает, если вы используете внешние источники для формирования DAG, например Variables.

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

Модернизация UI

Эмм, ну ладно.

Изоляция Worker

Это самое большое изменение в новой версии. Как я уже говорил, раньше любой worker имел прямой доступ к базе данных. Чтобы от этого избавиться, приходилось менять архитектуру.

В новой же версии вместе с WebServer у нас будет еще и API Server. Через него worker будет получать лимитированный доступ к информации из базы. На первый взгляд все хорошо, однако и тут не обошлось без усложнений. Worker изолировали настолько, что у него теперь будет отдельная библиотека - Apache-Airflow Task SDK, а для всех остальных Apache-Airflow Core. Названия еще не окончательные.

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

Запуск откуда угодно - и на каком угодно языке

Дополнительная безопасность - это не единственный бонус новой архитектуры. 

Новая архитектура Airflow даёт сразу несколько преимуществ: теперь worker’ов можно запускать где угодно — в любом сервисе, облаке или внутреннем кластере, задачи можно писать нативно на любом языке благодаря поддержке Task SDK для всех языков, а все вместе это подталкивает к идее запускать тяжёлые вычислительные процессы непосредственно на самих worker’ах, а не вынуждено обращаться к внешним сервисам.

Управление зависимостями

Когда для разных задач нужны разные версии библиотек, это ночной кошмар. Нам приходится расчехлять костыли и нагружать DAG операторами Docker или Kubernetes. 

Теперь стало проще иметь разные версии одной библиотеки. Да что там библиотеки - теперь в одном DAG стало проще иметь даже разные версии Python.

Event-Driven запуск

Так же в моем докладе я рассказывал про способ запускать DAG по событиям. На Airflow Summit 2024 ничего существенно нового не показали по этой теме, только добавилась возможность посылать уведомление об обновлении DataSet через API, вместо прямого запуска DAG.

А уже в версии 3.0 событийный запуск будет выглядеть так (ссылка на issue на GitHub):

Из возможных триггеров я видел SQS и File-триггеры, а также появится возможность создавать собственные триггеры — это выглядит действительно многообещающе.

Обновление Airflow

Информации по этой фиче немного. Разработчики обещали сделать процесс обновления проще. Он и сейчас выглядит легко, просто зачем его делать, если все работает? Остается только ждать.

Когда релиз?

Релиз запланирован на март 2025. Однако, но на момент написания статьи из запланированного выполнено только 78%.

Судя по всему, мы все-таки получим долгожданные версионирование DAG, обновление безопасности и парочку очень приятных фич. Назвал бы я Airflow 3 золотым стандартом индустрии? Скорее нет. Но я считаю, что Airflow ближе всех к этому стандарту, и комьюнити активно двигает его к этой цели.