Привет, Хабр! Я Георгий Новожилов, инженер данных в «ДАР» (ГК «КОРУС Консалтинг»). В моём стеке и стеке моих коллег 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-а всегда будет использована его последняя версия, при ручном запуске её также нельзя выбрать!

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:

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

Раздел 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 — расскажите, как прошло. Делитесь опытом, неожиданностями и наблюдениями, обсудим вместе в комментариях!