Apache Airflow 3.0: що нового і чи варто переходити

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Apache Airflow 3.0 — це суттєва еволюція у сфері оркестрації робочих процесів. З релізом у квітні 2025 року Airflow зробив рішучі кроки до модернізації архітектури, масштабування, покращення досвіду розробників і значного посилення безпеки. У цій статті проаналізуємо зміни у версії 3.0, порівняємо їх із серією 2.x.

Передумови

Apache Airflow давно став стандартом у побудові складних робочих процесів, особливо у сфері data engineering та машинного навчання. Серія 2.x принесла стабільність, паралелізм на рівні DAG, task mapping і ефективне планування.

Але з поширенням розподілених, event-driven і багатомовних архітектур з’явилися обмеження: монолітна архітектура 2.x вже не справлялася з новими вимогами. Airflow 3.0 — це не просто оновлення версії, це зміна архітектури, оновлення UI, та навіть зміна філософії роботи з оркестрами. Давайте переглянемо кожну частину детальніше.

Повністю оновлений UI

Мабуть, найпростіша та найприємніша частина. Хоча Airflow має непоганий UI для роботи, він є застарілим і вже давно потребував змін.

Нова архітектура забезпечує значно плавніший досвід взаємодії, особливо в середовищах із сотнями або тисячами DAGів. Сторінки завантажуються швидше, елементи інтерфейсу стали інтуїтивно зрозумілішими, а навігаційна модель є послідовною та чуйною у всіх розділах.

Серед основних покращень інтерфейсу:

• Покращений вигляд сітки (Grid view): краща навігація за часовою шкалою, пошук і фільтрація. Користувачі тепер можуть легше переглядати статус виконання DAGів та діагностувати збої або завислі задачі.
• Покращений графічний вигляд (Graph view): удосконалено масштабування, прокручування і взаємодію з метаданими тасок. Це полегшує розуміння складної структури DAGів з першого погляду.
• Панель асетів (Asset panel): новий інтерфейс, спеціально розроблений для робочих процесів, орієнтованих на асети (тобто саме дані). Дозволяє візуалізувати асети, їхніх продюсерів та консьюмерів, а також відстежувати ланцюжок взаємодії DAGів. Про них детальніше поговоримо далі.
• Вбудована підтримка темного режиму. Хоча версія темного режиму вже була доступна у версії 2.x, це оновлення пропонує повноцінний, спеціально розроблений дизайн-рівень. Це була одна з найзапитуваніших функцій від спільноти.
• DAG runs тепер існують як окрема вкладка. Також можна її кастомізувати. Ввімкнути лише необхідні колонки. Сортувати практично за всіма колонками, навіть за duration (буде доступне з версії 3.1) та conf. Тепер дуже зручне використання для юзерів.
• FastAPI замість Flask-AppBuilder для АПІ. Тут очевидне покращення. Підтримка асинхронного коду для АПІ, кращий перфоманс і робота з валідаціями типів за допомогою Pydantic та багато чого іншого.

Dark mode у дії

Сортування за колонками у DAG Runs

Так виглядає Assets panel

Версіонування DAGів

Одна з найважливіших нових можливостей в Airflow 3.0 — це повноцінна підтримка версій DAG’ів.

У попередніх версіях Airflow DAG’и зчитувалися напряму з файлів з вихідним кодом, і найновіша версія DAGу застосовувалася всюди, навіть до вже виконаних ранів. Це призводило до кількох добре відомих проблем:

• Відхилення у виконанні (execution drift): якщо DAG оновлювали під час його виконання, деякі задачі могли виконуватися з різними версіями коду.
• Відсутність аудитності: Airflow не мав вбудованого механізму для відстеження, яка саме версія DAGу використовувалась при конкретному запуску.
• Історична неточність: інтерфейс завжди показував найновішу версію DAGу, навіть для старих запусків, що спричиняло непослідовну або оманливу історію виконань.

Версійність DAGів відіграє ключову роль у забезпеченні надійності, відтворюваності та відповідності вимогам у роботі з даними. Ось чому це важливо:

• Відтворюваність (Reproducibility): тепер ви можете повторно виконати DAG точно у тій версії, в якій він запускався раніше, навіть якщо поточний код вже змінився.
• Дебаг помилок (Debugging): помилки можна пов’язати з конкретною версією DAGу, що значно полегшує пошук помилки.
• Відповідність (Governance): у регульованих середовищах версійність забезпечує аудит — зберігаючи інформацію, який код, коли і як був використаний.
• Інтеграція з CI/CD: команди, які використовують GitOps, можуть зв’язувати версії DAGів в Airflow із хешами комітів у системі контролю версій, створюючи повністю відстежуваний pipeline.

Що змінює Airflow 3.0

У версії 3.0 впроваджено структуроване відстеження версій DAGів безпосередньо в платформу:

• DAGи версіонуються автоматично при кожному оновленні коду або деплої.
• Історичні запуски зберігаються разом із конкретною версією DAGу.
• Через інтерфейс користувач може вибрати конкретну версію DAGу, та навіть перезапустити з цією версією DAG.

Мені особливо імпонує ця функція, адже на практиці майже неможливо створити DAG, який ніколи не доведеться змінювати. Бізнес-логіка змінюється, з’являються баги або потреба в оптимізації — і вбудована версійність робить цей процес прозорим і контрольованим. На скріншоті нижче зображено новий інтерфейс оркестрації DAGів та випадаючий список історії версій.

Підтримка вірсіонування для DAGів

Asset-driven DAGи

В основі розумного планування в Airflow 3.0 лежить концепція Assets. Натхненні еволюцією датасетів, які були представлені в попередніх версіях, новий декоратор @asset дозволяє користувачам створювати пайплайни, які залежать від стану даних.

Що таке asset

Asset в Airflow — це одиниця даних або результат, який створюється, трансформується або споживається DAGом.

Це може бути:

• таблиця в базі даних;
• файл у хмарному сховищі;
• натренована ML-модель;
• або навіть відповідь від API.

З декоратором @asset:

• Асети оголошуються як Python-функції, які повертають або генерують дані.
• Ці асети стають повноцінними учасниками процесу оркестрації.
• Airflow автоматично відстежує залежності між асетами та DAGами.

На скріншоті нижче показано, як ці асети візуалізуються в консолі Airflow.

Побудова DAG-до-DAG залежності за допомогою асету посередині

Для створення цього прикладу достатньо створити лише 2 DAGа з наступним кодом.

# producer DAG
from airflow.sdk import Asset, dag, task

@dag
def my_producer_dag():
    @task(outlets=[Asset("my_asset")])
    def my_producer_task():
        pass

    my_producer_task()


my_producer_dag()

# consumer DAG
from airflow.sdk import Asset, dag
from airflow.providers.standard.operators.empty import EmptyOperator

@dag(schedule=[Asset("my_asset")],)
def my_consumer_dag():
    EmptyOperator(task_id="empty_task")

my_consumer_dag()

Тепер при запуску продюсера у нас запишуться дані у наш асет і після цього автоматично викличеться консюмер із даними в асеті. Ви можете використовувати «&» (and) та «|» (or) оператори для створення більш складних залежностей з асетами. Щось на кшталт:

from airflow.sdk import Asset, dag

@dag(
    schedule=(Asset("asset1")  | Asset("asset2") | Asset("asset3") | Asset("asset4")),
)
def downstream1_on_any():
    pass
downstream1_on_any()

Дасть можливість викликати наступний DAG навіть коли лише 1 асет зазнає змін. Відображатись у консолі DAGу це буде так:

Приклад conditional asset scheduling

Додаткові ключові можливості assets в Airflow 3.0

• Структуровані метадані. Асети мають імена, URI, ідентифікатори груп та довільні поля метаданих, що дозволяє забезпечити глибоку інформацію для дебагу та спростити пошук.
• Композиційний дизайн. Асети можуть посилатися один на одного для побудови взаємозалежних, модульних пайплайнів.
• Підтримка Watcherів. Асети можна налаштувати з вотчерами, які відстежують зовнішні сигнали (наразі підтримується лише AWS SQS) та запускають DAG у відповідь на ці події. Звісно, обіцяють додати багато інших типів вотчерів.

Використовуючи асети, Airflow трансформується з моделі планування DAGів як «запуск щогодини» до «запуск, коли готові дані». Це відкриває можливості для по-справжньому реактивних робочих процесів, які тісно пов’язані зі станом даних, а не з часом.

Архітектурні зміни в Airflow 3.0

Основна увага приділяється модульності, масштабованості та гнучкості розгортання, що дозволяє Airflow відповідати вимогам гібридних і мультихмарних платформ обробки даних.

Порівняння архітектури Airflow 2 та Airflow 3

API для виконання тасок і Task SDK

Одним з найважливіших нововведень у Airflow 3.0 є впровадження Task Execution API та супровідного Task SDK.

Ці компоненти дозволяють визначати й виконувати таски незалежно від ядра виконання Airflow.

Основні наслідки цього підходу:

• Гнучкість у виборі мови програмування. Таски більше не обмежуються лише Python. Завдяки новому SDK їх можна писати на Java, Go, R та інших мовах, що розширює можливості інтеграції з різними техстеками.
• Виокремлення середовища виконання. Таски тепер можуть запускатися в ізольованих, віддалених або контейнеризованих середовищах, окремо від шедулера і воркерів. Це прибирає конфлікти залежностей і покращує стабільність виконання.
• Спрощений процес розробки. Стандартизований інтерфейс розробки тасок спрощує тестування та деплой, сприяє повторному використанню коду та зменшує час онбордингу нових розробників.

Ця архітектура — значний прорив, що робить Airflow гнучкішим і більш cloud-native. Вона відповідає загальній тенденції в data engineering до різноманіття мов, контейнеризації та відтворюваності на рівні тасок.

Edge Executor

Edge Executor — ще одне нововведення у Airflow 3.0. Він розроблений для підтримки event-driven та географічно розподіленого виконання тасок. Замість того, щоб вимагати виконання всіх тасок у централізованому кластері, Edge Executor дозволяє запускати таски безпосередньо біля джерела даних.

Основні переваги Edge Execution:

• Географічна гнучкість. Таски можуть виконуватись у віддалених або регіональних кластерах, дата-центрах чи навіть на edge-пристроях.
• Миттєва реакція. Ідеально підходить для задач із низькою затримкою, орієнтованих на події — таких як IoT, фінансові стріми або оперативний моніторинг.
• Зменшення мережевої затримки. Обчислення виконуються біля джерела даних, що знижує витрати на передачу великих обсягів даних до центрального кластера.
• Event-driven пайплайни. Edge Executor повністю підтримує нову модель планування, представлену в Airflow 3.0.

Зручна підтримка ML та AI-пайплайнів в Airflow 3.0

Airflow 3.0 робить суттєвий крок уперед, стаючи повноцінним інструментом оркестрації для сучасних робочих процесів машинного навчання (ML) та AI.

DAGи без інтервалів даних

Однією з найбільш трансформаційних змін у версії 3.0 є відмова від обов’язкової прив’язки запуску DAGів до execution_date. У Airflow 2.x та попередніх версіях кожен DAG-запуск вимагав унікального execution_date. Ця модель добре підходила для ETL-задач, орієнтованих на час, але створювала труднощі в ML-сценаріях. У Airflow 3.0 з’являються DAGи без інтервалів даних, які надають справжню незалежність виконання:

Що це дозволяє:

• Експерименти з моделями. Запускайте один і той самий DAG багаторазово з різними конфігураціями моделі або частинами даних — без конфліктів через execution_date.
• Підбір гіперпараметрів. Запускайте паралельно кілька DAGів із різними сітками параметрів або стратегіями пошуку — кожен буде відслідковуватись окремо.
• Inference DAGи. Викликайте DAG багаторазово — для обробки нових даних у реальному часі або пакетного прогнозування, що тригериться зовнішніми подіями чи діями користувача. Ідеально підходить для сценаріїв, де потрібна гнучкість — наприклад, інференс, перевірки якості даних або тригерні задачі користувачем.
• Event-Driven DAGи. Тепер DAGи також тригеряться зовнішніми подіями — наприклад, при появі нового файлу в хмарному сховищі або повідомлення в Kafka. Це дозволяє реалізовувати реактивну оркестрацію в реальному часі.

Це від’єднання логіки виконання DAGів від графіка значно спрощує оркестрацію для ML-інженерів.

Покращення для розробників

Розділення CLI: airflow і airflowctl

У версії Airflow 3.0 розділили CLI на два окремі інструменти, що відповідає новій модульній архітектурі бекенду та розрізняє локальну розробку і віддалену роботу в продакшн-середовищах.

airflow

• Використовується для локальної розробки та тестування.
• Працює з локальними DAGами, базою метаданих та компонентами.
• Підтримує швидке тестування, парсинг DAGів та налагодження через CLI.

airflowctl

• Призначений для продакшн-оркестрації та роботи з віддаленими середовищами.
• Відповідає за керування середовищем, деплоймент та запуск у хмарі.
• Корисний для CI/CD пайплайнів, моніторингу та управління розподіленими кластерами.

Таке розділення спрощує робочі процеси як для окремих розробників, так і для платформенних команд.

Посібник з міграції з Airflow 2.x на 3.0

Мінімальні вимоги:

• Python 3.9+.

Кроки:

1. Оновити до останньої 2.x (рекомендовано 2.7.3+).
2. Перевірити DAGи на deprecated-фічі. Бо вони будуть видалені у версії 3.0.
3. Зробити резервну копію БД.
4. Встановити 3.0 в окремому середовищі.
5. Протестувати DAGи.
6. Впровадити airflowctl для продакшну.

Порівняльна таблиця: Airflow 2.x vs 3.0

Чи варто оновлюватися

Так, якщо ви:

• Потребуєте безпечного, віддаленого виконання задач.
• Хочете зручне версіовання DAGів.
• Будуєте real-time, event-based або asset-оркестрацію.
• Маєте multi-language задачі.

Зачекайте, якщо ви:

• Маєте складну кастомізацію на Flask.
• Не використовуєте подієве планування або Assets.
• Все ще на Python < 3.9 або маєте застарілі залежності.

Підсумок

Airflow 3.0 — це великий реліз із дуже великими та необхідними на часі змінами. Підтримка event-driven та інференс пайплайнів відкриває двері для великої кількості ML/AI проєктів, що додасть ще більшої популярності Airfow. Покращена архітектура робить Airflow гнучким і рухає його до більшої децентралізації. Підтримка версіонування прибере дуже багато головного болю. Введення концепції assetів збільшує розуміння та підтримуваність пайплайнів. Третя версія справді виглядає дуже сильною. І для мене цей реліз є особливо приємним, бо до декількох нових фічів я докладав зусилля особисто. 🙂

Ресурси

• Офіційна документація Airflow 3.0
• Вебінар від Astronomer
• Огляд від NextLytics
• Apache Airflow 3.0: A Comprehensive Preview of the Future of Workflow Orchestration
• Apache Airflow 3.0 Is Here: The Most Significant Release Yet
• Assets and data-aware scheduling in Airflow