Долгожданный релиз Airflow 3 / Хабр

Привет, Хабр! Я Георгий Новожилов, инженер данных в «ДАР» (ГК «КОРУС Консалтинг»). В моём стеке и стеке моих коллег Airflow, можно сказать, незаменим.

Он помогает нам планировать, запускать и отслеживать сотни задач обработки данных, которые крутятся в кластере каждый день: загрузки из источников, трансформации, пересчёты и обновления витрин. Пайплайны визуально контролируются из удобного веб‑интерфейса, в котором можно легко и быстро локализовать сбои. Для инженеров данных Airflow — надёжный инструмент автоматизации всей ETL‑ и ELT‑инфраструктуры.

И вот 22 апреля 2025 года компания Apache выпустила новую версию своего оркестратора, которая была в разработке последние 4 года. Среди ключевых изменений - новый интерфейс, обновлённая и защищённая архитектура, а также стабильный интерфейс разработки.

В этой статье предлагаю рассмотреть, какие ещё нововведения нам привезли в масштабном обновлении Apache Airflow 3.0.0.

Предисловие

В реальных проектах задачи редко выполняются в одиночку. Например:

Сначала данные загружаются из источника (S3, СУБД, API);
Затем проходят очистку и трансформацию (Spark, Python, dbt);
И, наконец, сохраняются в хранилище, и на их основе создаются отчёты.

Без оркестратора придётся писать сложную логику запуска, ждать окончания предыдущих шагов, следить за логами и ошибками вручную. Оркестратор берёт всё это на себя — как режиссёр, который управляет всем процессом «оркестра» из задач.

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

Apache Airflow — это один из самых популярных оркестраторов в мире данных. В нём:

Пайплайны описываются в виде DAG-ов (Direct Acyclic Graph);
Есть Web-UI для мониторинга: удобно видеть, что выполнено, где упало и когда пересчитать;
Можно работать с зависимостями между задачами, повторами, SLA, приоритетами.

Изменения в интерфейсе

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

Теперь логотип не крутится при наведении в интерфейсе, пожалуйста, учитывайте при переезде на новую версию!

Теперь давайте разберём подробнее каждый из новых разделов.

Раздел Home

В новой версии Airflow нас встречает не приевшийся DAG List View, а новый раздел Home, в котором удобно выведены основные показатели по текущему статусу кластера и Healthcheck-и основных сервисов:

В нём присутствуют следующие блоки:

Health: статусы элементов сервиса (про Dag Processor поговорим ниже в разделе Обновлённая архитектура);
Links: ссылки на раздел Dags с быстрыми фильтрами по Упавшим / Работающим / Активным (Включённым) DAG-ам;
History: обзор статусов DAG-ранов, Task Instances и Asset Events за выбранный период.

По умолчанию установлен обзор за последние 24ч, но также доступны: за последний час, последние 12 часов и последнюю неделю. Выбирать конкретные диапазоны дат в релизной версии нельзя.

Также, при первом открытии Airflow 3.0.0 по умолчанию выставлена тёмная тема. Выглядит она следующим образом:

Переключить тему можно в разделе пользователя:

В рамках статьи будем использовать примеры в привычном для всех светлом варианте.

Раздел Dags

Теперь раздел Dags содержит не только общий список DAG-ов в кластере, но также вкладки Runs и Task Instances.

Рассмотрим каждую из вкладок и подробно разберём изменения в Dag Details.

Dag List View

По умолчанию нас встречает новый вариант отображения DAG‑ов — тайловый. По сравнению с предыдущими версиями Airflow он заметно упрощён и потерял свою былую информативность:

Теперь каждая строчка с DAG-ом отображает лишь:

Dag ID и тэги;
Расписание;
Даты последнего и следующего запусков;
Последние статусы DAG-ранов в виде столбчатой диаграммы;
Включение / выключение и ручной триггер.

Пропали такие информативные столбцы как Owner, Recent Tasks, Reparse Dag и быстрые ссылки на овервью DAG-а Links.

Вот как выглядел этот раздел в предыдущей версии Airflow 2.10.4:

Остался и более привычный формат списка DAG-ов, на который можно переключиться в левом верхнем углу. Однако, столбцов в нём не прибавится, лишь Tags выносятся в отдельный столбец:

Изменения коснулись и строки поиска: в новой версии он в реальном времени фильтрует и выводит список DAG-ов на странице, а не названия в боксе поиска.

Теперь давайте зайдём в пару DAG-ов и посмотрим поменялось ли управление в Dag Details.

Dag Details / Overview

Dag Overview встречает нас обновлённым UI и быстрыми ссылками на упавшие таски (Tasks) и DAG-раны (Runs):

В свою очередь, вкладки Runs и Tasks содержат крайнее полезную информацию для быстрой отладки, которой очень не хватало в прошлых версиях Airflow. Примеры UI ��а скринах ниже:

В тасках отображаются типы используемых операторов и статусы последних ранов для каждой из них.

Теперь заниматься быстрым анализом причин падений процессов станет удобнее, ведь не придётся кликать на мелкие квадратики в гриде :)

Dag Details / Graph View

Графовое представление DAG-ов (Dag Graph View) было также заметно улучшено. Теперь можно дополнительно добавлять в граф зависимости (например, используемые Assets), скачивать изображение графа в формате PNG и делать фильтрацию по версиям DAG-а:

Dag Details / Backfill

В новой версии Apache Airflow появился интерфейс для инструмента Backfill, который ранее можно было использовать лишь через Airflow CLI.

Backfill — это создание и запуск DAG-ранов для прошедших дат, которые ранее не были обработаны.

Теперь им можно воспользоваться прямо из обзора DAG-а в Dag Details.

Пример отработавшего Backfill ниже:

На текущий момент Airflow 3.0.0 предоставляет три режима при повторной обработке:

none: новый DAG-ран не будет создан, если для данной даты он уже существует, независимо от его состояния;
failed: новый запуск будет создан, только если предыдущий завершился с ошибкой;
completed: новый запуск будет создан, если предыдущий завершился с ошибкой или успешно.

Для конкретного DAG-а можно контролировать количество одновременных DAG-ранов при помощи параметра max_active_runs, независимо от его глобального ограничения.

По умолчанию Backfills выполняются в хронологическом порядке, но с опцией --run-backwards можно изменить порядок на обратный - начиная с самой последней указанной в CLI / UI даты.

Подробнее - в официальной документации Airflow Backfill.

Dag Details / Versioning

Одно из самых масштабных нововведений в Airflow 3.0.0 — это версионирование DAG-ов.

Оно работает без дополнительной настройки: Airflow сам отслеживает изменения в структуре DAG-ов. Это происходит независимо от того, каким способом DAG был загружен в систему. Каждый раз, когда запускается DAG и при этом его структура изменилась с момента предыдущего запуска, создаётся его новая версия.

Примеры версий указаны на изображении ниже. В нём при добавлении в пайплайн каждой новой таски say_hello_<N> менялась версия DAG-а:

Под структурными изменениями подразумеваются любые правки, которые повлияли на его графическое представление:

Изменение параметров DAG-a;
Изменение или добавление тасок;
Изменение зависимостей (например, Asset);
Изменение task_id.

Также версия DAG-а указывается в интерфейсе при просмотре вкладок Runs, Tasks, Overview, и в Graph View.

Выбор версии Dag-а в графовом представлении

Важно: при запуске DAG-а всегда будет использована его последняя версия, при ручном запуске её также нельзя выбрать!

Runs и Task Instances

Вкладки Runs и Task Instances тоже изменились по сравнению с предыдущими релизами, и самое заметное изменение — крайне урезанная фильтрация.

В релизной версии доступна фильтрация лишь по следующим параметрам:

Статус: Failed / Running / Success / Queued / All;
Тип: Backfill / Manual / Scheduled / Asset Triggered.

Пример фильтрации на изображении ниже:

Похожая ситуация случилась и с Task Instances, в которой для фильтрации доступны лишь все доступные статусы тасок:

Для примера, в предыдущей версии Airflow 2.10.4 присутствовала мощная фильтрация по огромному множеству фильтров и их дальнейшему соответствию поискового запроса:

На данный момент очень не хватает продвинутой фильтрации и возможности применить действие к выбранному множеству отфильтрованных DAG-ранов / тасок.

Раздел Assets

С релизом Airflow 3.0.0 делается серьёзный шаг в сторону Asset-oriented подхода к разработке. Теперь DAG может запускаться не только по расписанию или вручную, но и в ответ на внешние события — например, при появлении или обновлении данных во внешней системе.

Были обновлены Airflow Datasets, которые теперь называются Data Assets. Они являются более универсальными. Вместе с ними представленаи новая сущность — Watchers: они "наблюдают" за событиями и позволяют реагировать на них внутри Airflow.

Каждый Asset идентифицируется уникальным URI (например, 's3://bucket/data.csv') и может содержать дополнительную информацию, такую как метаданные или принадлежность к определённой группе.

Пример определени�� ассета:

from airflow.sdk import Asset

example_asset = Asset(
    uri="s3://asset-bucket/example.csv",
    name="example_asset"
)

Таски могут производить (ориг. produce) или потреблять (ориг. consume) ассеты, указывая их в параметрах outlets и inlets соответственно. Это позволяет Airflow отслеживать, какие задачи создают или используют определённые данные и управлять зависимостями между ними.

Пример использования ассета из официальной документации Airflow:

from airflow.sdk import DAG, Asset
from airflow.providers.standard.operators.python import PythonOperator

example_asset = Asset(
    name="example_asset",
    uri="s3://asset-bucket/example.csv"
)


def _write_example_asset():
    """Write data to example_asset..."""
    pass

  
with DAG(dag_id="example_dag") as dag:
    write_task = PythonOperator(
        task_id="write_example_asset",
        python_callable=_write_example_asset,
        outlets=[example_asset],
    )

В новой версии добавили декоратор @asset, с которым код выше можно упростить буквально до пары строчек:

from airflow.sdk import asset


@asset(uri="s3://asset-bucket/example.csv", schedule="@daily")
def example_asset():
    """Write data to example_asset..."""

Подробнее - в официальной документации Asset Definitions.

Раздел Browse

В релизной версии раздел Browse содержит лишь две вкладки: Audit Log и переехавшая в неё XComs.

Вместе с Runs и Task Instances они лишились продвинутой фильтрации, а в Audit Log ещё и забыли завезти ссылки на упомянутые DAG-раны и таски:

Во вкладке XComs все ссылки рабочие:

Раздел Admin

Раздел Admin по наполнению остался таким же, как и в предыдущей версии, разве что Variables, Pools и Connections также обделены фильтрацией.

Список пуллов теперь выглядит совсем не информативно, ведь он лишился ключевых показателей по загруженности:

Пример обзора пуллов в Airflow 2.10.4:

Вкладка Pools в разделе Admin в Airflow 2.10.4

В режиме редактирования пулла также не будут отображены основные показатели:

Окно редактирования Pools в Airflow 3.0.0

Раздел Security

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

Обновлённая архитектура

Основные изменения в архитектуре новой версии Airflow нацелены на повышение безопасности и внедрение сервисно-ориентированного подхода для быстрого масштабирования в крупных кластерах.

Нынешнее взаимодействие сервисов с базой метаданных происходит следующим образом:

Скриншот взят из видео Astronomer — Introducing Airflow 3: Architecture changes and task isolation.

Также вынесли обработчик DAG-ов в отдельный сервис Dag Processor, и заменили Webserver на ApiServer.

Новые контейнеры в официальном docker-compose.yaml:

service:
  # новый обработчик DAG-ов
  airflow-dag-processor:
    <<: *airflow-common
    command: dag-processor
    healthcheck:
      test: ["CMD-SHELL", 'airflow jobs check --job-type DagProcessorJob --hostname "$${HOSTNAME}"']
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 30s
    restart: always
    depends_on:
      <<: *airflow-common-depends-on
      airflow-init:
        condition: service_completed_successfully

  # apiserver пришёл на замену webserver
  airflow-apiserver:
    <<: *airflow-common
    command: api-server
    ports:
      - "8080:8080"
    healthcheck:
      # Поменялся и Healthcheck, теперь он обращается к эндпоинту
      # на REST API v2, а не базовому эндпоинту localhost:8080/health:
      test: ["CMD", "curl", "--fail", "http://localhost:8080/api/v2/version"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 30s
    restart: always
    depends_on:
      <<: *airflow-common-depends-on
      airflow-init:
        condition: service_completed_successfully

Ниже рассмотрим основные изменения из Airflow 3.0.0 # Release Notes.

Task Execution API и Task SDK

В новом релизе Airflow внедряет Task Execution API и легковесный рантайм Task SDK, которые позволяют выполнять задачи в любых средах и на любых языках программирования.

Это достигается за счет разделения ядра Airflow и среды выполнения задач, что означает:

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

Подробнее — в Airflow 3.0.0 Release Notes # Task Execution Api.

Edge Executor

Edge Executor — это новый executor, разработанный для выполнения задач на периферийных устройствах и в распределенных средах. Он интегрируется с вышеупомянутым Task Execution API и позволяет выполнять задачи ближе к источникам данных или в специфических средах.

Подробнее - в Airflow 3.0.0 Release Notes # Edge Executor.

Ограниченный доступ к базе метаданных

В Airflow 3.0.0 таскам запретили прямой доступ к базе метаданных. Теперь вместо этого они взаимодействуют с системой через защищенные API-интерфейсы на REST API v2, о чём пойдёт речь дальше.

Подробнее — в Airflow 3.0.0 Release Notes # Restricted Metadata Database Access.

Переход на REST API v2

Для версий Airflow 3.0.0+ представлен новый REST API v2 на FastAPI, который заменяет устаревший API v1. Новая версия обеспечивает более высокую производительность, улучшенную документацию и поддержку современных стандартов безопасности.

Подробнее — в Airflow 3.0.0 Release Notes # REST API v2 replaces v1.

Новый стабильный интерфейс для написания DAG-ов (airflow.sdk)

Airflow 3.0.0 представляет airflow.sdk — новый стабильный интерфейс для определения DAG-ов и тасок, который интегрируется с вышеупомянутыми Task SDK и Edge Executor.

Теперь привычные DAG, @dag и @task, нужно импортировать из airflow.sdk, а не других модулей, что обеспечивает улучшенную совместимость кода в будущих версиях, например:

# Предыдущие версии Airflow 2.x
from airflow.models import DAG
from airflow.decorators import task

# Новые версии, начиная с Airflow 3.0.0
from airflow.sdk import DAG, task

Операторы и некоторые хуки также переехали в новый модуль providers.standard:

# Предыдущие версии Airflow 2.x
from airflow.operators.python import PythonOperator
from airflow.operators.empty import EmptyOperator

# Новые версии, начиная с Airflow 3.0.0
from airflow.providers.standard.operators.python import PythonOperator
from airflow.providers.standard.operators.empty import EmptyOperator

Полный список импортов и существующих классов представлен в документации.

Подробнее - в Airflow 3.0.0 Release Notes # New Stable DAG Authoring Interface.

Миграция с прошлых версий

Миграция конфигурации

В Airflow 3.0.0 представили новую систему миграции конфигурации.

При переезде можете прописать команду airflow config migrate, которая автоматически обновит имеющийся airflow.cfg, заменив deprecated парам��тры (большинство deprecated параметров было удалено) на актуальные.

Также, Airflow сам подсказывает, какие параметры нужно заменить, если они всё ещё используются. Например, в логах будет указано, что old_param нужно заменить на new_param, если он всё ещё используется.

Подробнее - в Airflow 3.0.0 Release Notes # Configuration Migration.

Миграция DAG-ов

Чтобы минимизировать трудности при переезде на новую версию Airflow 3, разработчики создали утилиту для проверки ваших DAG-ов, основанную на Ruff.

Лучше использовать последнюю версию Ruff, так как в ней содержатся актуальные правила, а минимальная пригодная для использования — 0.11.6.

Для проверки ваших DAG-ов на несовместимости можете воспользоваться командой ниже (AIR301 — это правило для проверки перехода на Airflow 3):

ruff check dag/ --select AIR301 --preview

Или можете посмотреть предлагаемые исправления:

ruff check dag/ --select AIR301 --show-fixes --preview

Эта команда покажет, что можно изменить, но не будет вносить сами изменения.

Также можно автоматически применить предлагаемые исправления:

ruff check dag/ --select AIR301 --fix --preview

Таким образом, Ruff сам внесёт возможные правки в код.

Подробнее - в Upgrading to Airflow 3 # Check your Airflow DAGs for compatibility.

Заключение

Релиз Apache Airflow 3.0.0 — это шаг вперёд в сторону надёжности, безопасности и современного подхода к построению пайплайнов данных. Новый интерфейс, переработанная архитектура, долгожданное версионирование DAG-ов и появление Task SDK открывают новые возможности для инженеров данных и разработчиков. Переход на REST API v2 и отказ от прямого доступа к базе метаданных делают платформу безопаснее и лучше масштабируемой.

Тем не менее, в релизе 3.0.0 остаётся немало недоработок. Интерфейс местами сыроват: заметны пролаги, отсутствующие ссылки и устаревшие элементы. Продвинутая фильтрация, которая ранее помогала быстро локализовать проблемы, пока отсутствует или реализована лишь частично.

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

Если уже успели поработать с Airflow 3.0.0 — расскажите, как прошло. Делитесь опытом, неожиданностями и наблюдениями, обсудим вместе в комментариях!

Долгожданный релиз Airflow 3