В апреле 2025 года вышел Apache Airflow 3.0 — первый крупный релиз за четыре года. Это самое большое обновление в истории проекта, которое затрагивает практически все аспекты работы с платформой: от пользовательского интерфейса до внутренней архитектуры.
За время с выхода Airflow 2.0 количество пользователей выросло с 25,000 до 80,000 организаций, а месячные загрузки увеличились до 30 миллионов. Airflow давно перерос свою изначальную роль ETL-инструмента: сейчас 30% пользователей применяют его для MLOps, а 10% — для GenAI-процессов. Именно эти новые сценарии использования и стали драйвером для кардинальных изменений в третьей версии.
Что такого особенного в третьей версии?
Если коротко — всё. Airflow 3.0 вводит сервис-ориентированную архитектуру, стабильный интерфейс для создания DAG'ов, расширенную поддержку событийных процессов и ML-задач, а также полностью модернизированный UI на React. Но давайте разберёмся по порядку, потому что за каждой строчкой в описании изменений стоят месяцы работы более чем 300 разработчиков.
Основная философия релиза — превратить Airflow из "просто планировщика задач" в полноценную платформу для современных данных и ИИ. Больше никаких костылей для конвейеров машинного обучения, больше никаких танцев с бубном для событийных архитектур. Теперь это всё работает из коробки.
DAG Versioning: Наконец-то!
Начнём с самого ожидаемого нововведения — DAG Versioning, которое стало самой запрашиваемой функцией согласно ежегодному опросу пользователей Airflow. Если вы когда-нибудь пытались понять, почему ваш DAG сломался после деплоя, или искали логи задачи, которую удалили из пайплайна неделю назад — эта боль наконец-то закончилась.
Как это работает? Довольно просто. DAG будет выполняться до завершения на основе версии, которая была активна в момент запуска, даже если новая версия была загружена во время выполнения. Больше никаких неприятных сюрпризов, когда изменение в коде влияет на уже запущенные процессы.
Но самое приятное — это UI. Теперь в интерфейсе есть dropdown для просмотра предыдущих версий DAG'а. Хотите посмотреть, как выглядел ваш пайплайн месяц назад? Пожалуйста. Нужно понять, какая версия кода генерировала конкретный dataset? Вот она, со всеми задачами, логами и метаданными.
Особенно это полезно для команд, работающих с compliance и аудитом . Раньше нужно было вести отдельную документацию изменений, теперь всё это делается автоматически. Git-интеграция позволяет даже перезапускать старые версии DAG'ов — функция, которая наверняка придётся по душе тем, кто занимается историческими перерасчётами данных.
Новый UI: React приходит в Airflow
Если вы хотя бы раз работали с Airflow в продуктиве, то знаете: старый UI, мягко говоря, мог бы быть получше. Особенно когда у вас сотни DAG'ов, и страница загружается как в начале 2000-х. Хорошие новости — Airflow 3.0 поставляется с полностью переработанным UI на React и FastAPI.
Что это означает на практике? Во-первых, скорость. Загрузка страниц стала быстрее, элементы UI более интуитивны, а навигация ощущается согласованной и отзывчивой во всех представлениях. Особенно это заметно в средах с сотнями или тысячами DAG'ов.
Из конкретных улучшений стоит отметить:
- Представление сетки — улучшенная навигация по временной шкале, поиск и фильтрация. Теперь гораздо проще сканировать статус выполнения DAG'ов и находить проблемные задачи
- Представление графа — лучшее масштабирование, панорамирование и интерактивное исследование метаданных задач. Сложные структуры DAG'ов стало понимать с первого взгляда
- Панель ресурсов — новое представление, специально созданное для процессов, управляемых ресурсами. Позволяет визуализировать ресурсы, их производителей и потребителей
Конечно, как и любое кардинальное изменение UI, это потребует некоторого привыкания от пользователей, которые работали с Airflow годами. Но, честно говоря, новый UI выглядит так, как должен был выглядеть современный workflow orchestrator в 2025 году.
Сервис-ориентированная архитектура: Задачи могут выполняться везде
Пожалуй, самое фундаментальное изменение в Airflow 3.0 — это новый Task Execution API и airflow api-server, которые позволяют выполнять задачи в удалённых средах с улучшенной изоляцией и гибкостью. Звучит технически? Да. Революционно? Тоже да.
Раньше все задачи Airflow должны были выполняться в том же окружении, где работает планировщик. Теперь же Task Execution Interface представляет один из самых значительных архитектурных сдвигов в истории Airflow, позволяя запускать задачи практически где угодно — в других облаках, на edge-устройствах, в изолированных контейнерах.
Что это даёт? Представьте, что у вас есть ML-модель, которая должна обучаться на GPU-кластере в одном облаке, данные для неё лежат в другом облаке, а результаты нужно отправить в локальную систему. Раньше это было болью. Теперь — штатная ситуация.
Особенно интересен Edge Executor — новый исполнитель, который поддерживает распределённые, событийные и edge-вычисления. Это открывает совершенно новые возможности для IoT, real-time обработки данных и гибридных облачно-локальных архитектур.
Assets вместо Datasets: Событийность становится проще
Если вы пытались реализовать событийную архитектуру в Airflow 2.x, то знаете — это было возможно, но требовало немалой изобретательности. В третьей версии концепция Datasets была переименована в Assets с переработкой внутренней модели для лучшей поддержки будущих функций.
Assets в Airflow 3.0 — это не просто переименование. Это полноценная система для создания реактивных конвейеров. Assets поддерживают имена, URI, групповые идентификаторы и произвольные поля метаданных, что позволяет создавать богатую родословную и систему обнаружения.
Но самое интересное — это Watchers. Assets можно настроить с Watchers, которые мониторят внешние сигналы (в настоящее время AWS SQS) и запускают выполнение DAG в ответ. Это трансформирует планирование DAG'ов от "запускать каждый час" к "запускать, когда соответствующие данные готовы".
Представьте: файл попал в S3 → SQS получил уведомление → Watcher отреагировал → DAG запустился автоматически. Никаких cron'ов, никаких polling'ов. Просто чистая реактивная архитектура.
Backfill: Теперь это делается правильно
Если вы когда-нибудь пытались делать backfill в Airflow 2.x, то помните эту боль: команды в терминале, которые могли прерваться при потере сессии, отсутствие видимости в UI, невозможность остановить процесс на полпути. В Airflow 3 backfill'ы стали полноправными гражданами, управляемыми планировщиком и запускаемыми через UI или API.
Теперь backfill — это не отдельная команда, а штатная часть системы. Backfill'ы теперь обрабатываются основным планировщиком, обеспечивая согласованность с обычными запусками DAG'ов. Вы можете мониторить всё прямо в UI, ставить на паузу и даже отменять задания на полпути.
Это особенно важно для ML сценариев, где backfill'ы могут занимать часы или даже дни. Теперь вы можете спокойно запустить backfill перед выходными и быть уверенными, что он не упадёт от случайного закрытия терминала.
Поддержка разных языков: Не только Python
Одно из самых амбициозных нововведений — поддержка задач на разных языках программирования. Airflow 3 включает Python TaskSDK, который обеспечивает обратную совместимость для существующих DAG'ов. TaskSDK для дополнительных языков, начиная с Golang, будут выпущены в ближайшие месяцы.
Важное уточнение: DAG'и по-прежнему пишутся на Python. Но теперь задачи внутри этих DAG'ов могут быть написаны на Java, JavaScript, TypeScript, Go и других языках. Это открывает огромные возможности для интеграции с существующими системами и использования специализированных библиотек.
Представьте: вы можете написать обработку данных на Go для максимальной производительности, вывод ML-модели на Python с TensorFlow, а интеграцию с устаревшими системами на Java. Всё это в рамках одного Airflow DAG'а.
Что ушло из Airflow 3.0
Любой крупный релиз подразумевает не только добавление новых функций, но и удаление устаревших. SLA, SubDAGs, DAG и Xcom pickling, а также несколько внутренних контекстных переменных были удалены. Если вы используете эти функции, команда Airflow предоставила инструменты миграции для обнаружения устаревшего использования.
Также изменилась структура командной строки. airflow теперь используется для локальных команд, в то время как airflowctl обрабатывает удалённые операции, что обеспечивает лучшее разделение между разработкой и развёртыванием.
Не пугайтесь — команда разработчиков предусмотрела подробный гайд по миграции и инструменты для автоматической проверки совместимости ваших DAG'ов.
Стоит ли мигрировать прямо сейчас?
Короткий ответ: зависит от ваших потребностей. Если у вас стабильно работающая система на Airflow 2.x и нет острой необходимости в новых функциях — можете подождать. Airflow 2.x будет поддерживаться ещё долго.
Но если вы:
- Мучаетесь от отсутствия версионирования DAG'ов
- Хотите строить событийные архитектуры
- Планируете multi-cloud или edge deployments
- Активно используете ML/AI workflows
- Устали от медленного UI
То Airflow 3.0 стоит внимательного изучения уже сейчас.
Как начать работу с Airflow 3.0
Самый простой способ познакомиться с новой версией — использовать Docker. Официальная настройка Docker для Airflow уже обновлена до 3.0, достаточно запустить следующую команду для получения последнего yaml файла для composer.
Для продуктива рекомендуется:
- Сначала протестировать миграцию на staging окружении
- Использовать официальные инструменты миграции
- Обновить Python до версии 3.9-3.12 (если ещё не сделали)
- Проверить совместимость ваших пользовательских операторов и сенсоров
Если вы используете управляемые сервисы вроде AWS MWAA или Google Cloud Composer, подождите их официальной поддержки Airflow 3.0.
Взгляд в будущее
Apache Airflow 3.0 — это не просто очередное обновление. Это закладка фундамента для следующего поколения оркестрации данных. Сервис-ориентированная архитектура, поддержка разных языков, событийные возможности — всё это подготавливает Airflow к миру, где данные и ИИ становятся ещё более центральными для бизнеса.
Особенно важно, что команда разработчиков не просто добавила новые функции, а переосмыслила архитектуру с учётом современных потребностей. Edge computing, multi-cloud развёртывания, real-time аналитика — всё это теперь не костыли поверх Airflow, а его естественные возможности.
Конечно, любое крупное обновление приносит свои сложности. Потребуется время на изучение новых возможностей, миграцию существующих DAG'ов, привыкание к новому UI. Но если судить по отзывам первых пользователей, игра стоит свеч.
Apache Airflow 3.0 — это не просто новая версия любимого оркестратора. Это манифест того, каким должна быть инженерия данных в эпоху ИИ. И, кажется, будущее уже здесь.
