22 апреля 2025 вышел долгожданный крупный релиз Apache Airflow. Знакомимся с главными новинками версии 3.0: изменения архитектуры и пользовательского интерфейса для повышения устойчивости и безопасности фреймворка.
Еще раз про версионирование DAG в Apache AirFlow 3.0
Недавно мы писали про бета-релиз Apache AirFlow 3.0. Теперь мажорная версия вышла официально и доступна для использования. Ее главными новинками считаются следующие:
- версионирование DAG;
- улучшение обратной заливки исторических данных за прошлые периоды;
- изоляция задач без прямого доступа в базу данных метаданных;
- удаленное исполнение с помощью Edge Executor;
- поддержка выполнения результатов обучения ML-моделей;
- планирование на основе событий;
- изменения пользовательского интерфейса.
Раньше в Airflow выполнялась только последняя версия DAG, что приводило к следующим ограничениям:
- отсутствие историчности изменения версий DAG в сетке и графическом представлении пользовательского интерфейса фреймворка;
- конфликты версий во время отправки кода: если код DAG изменился во время своего выполнения, некоторые задачи одного и того же запуска могли быть выполнены с использованием старой версии, в то время как другие использовали более новую версию. Такая ситуация несла в себе значительный риск непреднамеренных последствий. Например, в предыдущей версии DAG одна задача извлекала имя таблицы в реляционной базе данных, а вторая – вставляла данные эту таблицу. Если при обновлении DAG имя таблицы было изменено, данные могли быть вставлены не в тут таблицу, либо не вставлены вовсе из-за несовпадения типов данных и названий столбцов.
Для решения таких проблем в Airflow 3 были введены пакеты DAG и управление версиями DAG. Теперь каждый запуск DAG привязан к определенному снимку кода, а версии DAG поддерживаются в пользовательском интерфейсе Airflow. Изменения в DAG отслеживаются автоматически и не зависят от того, какой пакет DAG используется. Новая версия DAG создается каждый раз, когда создается запуск DAG, измененного с момента последнего запуска, включая изменения в самом DAG или его задачах (параметры, зависимости, идентификаторы), а также добавление новых или удаление прежних задач из конвейера. При инициализации нового запуска DAG планировщик использует его последнюю версию.
Код DAG И вспомогательные файлы упаковываются в DAG bundle с указанием бэкэнда, используемого для хранения кода. Например, LocalDagBundle использует локальную файловую систему для хранения кода DAG, а GitDagBundle — репозиторий Git. Некоторые пакеты DAG версионируются, например GitDagBundle. Версия пакета DAG создается путем версионирования базового бэкэнда. Например, новая версия GitDagBundle создается каждым коммитом Git , независимо от изменений DAG. Как это работает, покажу в другой раз. По умолчанию версия LocalDagBundle не версионирована. Использование другого пакета DAG, вместо LocalDagBundle требует внесения изменений в конфигурацию Airflow. Сетка DAG теперь сохраняет историю для всех задач, даже если они были удалены в последней версии DAG. В пользовательском интерфейсе можно выбрать, какую версию кода DAG отобразить на вкладке кода.
Обратная заливка: повторные запуски DAG за прошлые периоды
В инженерии данных часто приходится сталкиваться с наполнением хранилища историческими данными за прошлые периоды. Это называется обратная заливка (или засыпка) – backfill. Для этого в Apache AirFlow есть соответствующая команда, которая повторно запускает все экземпляры DAG для всех интервалов в пределах указанных дат начала и окончания. Также можно повторно запускать определенные задачи в рамках DAG. До версии 3.0 выполнять такую заливку данных можно было только через CLI-интерфейс, о чем мы писали здесь. Однако, доступ к командной строке есть не всегда. Кроме того, при разрыве соединения, сбое сеанса или CLI-процесса обратная заливка прекращалась, прерывая выполнение запущенных DAG.
По своей сути, CLI-команда backfill фактически была вторым планировщиком Airflow, который потенциально мог конфликтовать с базовым. Поэтому в версии 3.0 backfill стал управляться единым планировщиком и запускаться через пользовательский интерфейс, а также API. Благодаря этому можно отслеживать ход выполнения backfill-процесса непосредственно в пользовательском интерфейсе и управлять им, включая приостановку и отмену заданий в процессе выполнения. Также есть REST API для инициирования и мониторинга backfill-процессов, что полезно для автоматизации обратной заливки исторических данных и повторного запуска DAG.
Программные и архитектурные изменения
Для повышения безопасности в Airflow 3.0 изменена архитектура доступа к базе данных метаданных. Теперь рабочие процессы не обращаются к ней напрямую, а взаимодействуют через REST API фреймворка, используя JWT- или ID-токены в заголовке HTTP-запроса для аутентификации. Это позволяет применять минимальные привилегии с помощью безопасных вызовов API, которые легче отслеживать и проверять. Такое фундаментальное изменение архитектуры закладывает основу для удаленного запуска задач с помощью Edge Executor. Разработанный для событийно-управляемых и периферийных вычислений, Edge-исполнитель интегрируется с API выполнения задач для поддержки оркестровки задач за пределами среды выполнения Airflow. Это усовершенствование упрощает гибридные и кросс-средовые шаблоны оркестровки, позволяя исполнителям задач работать ближе к данным или уровням приложений.
Таким образом, Airflow теперь поддерживает сервисно-ориентированную архитектуру, позволяя выполнять задачи удаленно через новый API выполнения задач. Этот API отделяет выполнение задач от планировщика и вводит стабильный контракт для запуска задач вне среды выполнения Airflow. Для этого в новом релизе добавлен Task SDK — облегченная среда выполнения для запуска задач во внешних системах, таких как контейнеры, пограничные или другие среды выполнения. Это обеспечивает независимость от языка, улучшенную изоляцию, переносимость и расширяемость рабочих процессов. Фреймворка включает новое пространство имен airflow.sdk, которое включает основные интерфейсы для определения DAG и задач. Теперь такие объекты, как DAG, @dag, и @task надо импортировать из airflow.sdk, а не из внутренних модулей. Это обеспечивает стабильный и совместимый интерфейс для DAG в будущих версиях Airflow.
Наконец, Airflow 3.0 теперь имеет автономный процессор для парсинга DAG. Этот повышает производительность планировщика, изоляцию и наблюдаемость, а также упрощает архитектуру фреймворка, четко разделяя разбор DAG от логики планирования. Разделение процессора DAG от планировщика позволяет гарантировать, что планировщик не имеет доступа к файлам DAG и не может выполнить код, предоставленный автором DAG. Это повышает безопасность и устойчивость конвейеров обработки данных.
Планирование запусков на основе событий позволяет выполнять задачи вывода моделей машинного обучения без ограничений по предопределенным расписаниям. При этом можно использовать AI SDK, о котором мы писали здесь. Кроме того, Airflow 3.0 устраняет уникальное ограничение на логическую дату запуска DAG, что поддерживает варианты использования выполнения ML-вывода, позволяя выполнять одновременные запуски DAG. Это особенно полезно для сценариев, где несколько запросов вывода должны обрабатываться одновременно.
Разумеется, все это не единственные изменения в новой версии самого популярного оркестратора рабочих процессов. Более подробно о других новинках читайте в наших следующих статьях. А освоить тонкости администрирования и эксплуатации Apache AirFlow вы сможете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
