Коротко: Apache Airflow — це відкрита платформа для оркестрації data pipeline, де логіка описується як Python-код у вигляді DAG (Directed Acyclic Graph). Стаття охоплює встановлення Airflow локально, написання першого робочого DAG і типові помилки, яких варто уникати з самого початку. Підходить тим, хто вже знає Python базово і хоче автоматизувати ETL або побудувати перший data pipeline.
Вступ
Більшість data pipeline починаються однаково: скрипт на Python, запуск через cron, і спочатку все виглядає зручно. Але з часом скриптів стає більше, між ними з’являються залежності, і відстежити що, коли і чому впало — стає справжнім болем.
Apache Airflow вирішує саме цю проблему. Він дозволяє описати pipeline як код, запускати задачі за розкладом або залежностями, моніторити виконання через UI і перезапускати окремі кроки без повного рестарту.
У цій статті розберемо: що таке DAG і як він працює, як встановити Airflow локально за кілька команд, як написати перший ETL-pipeline з нуля і яких помилок найчастіше припускаються початківці. А якщо Python для вас ще не зовсім рідна мова — спочатку рекомендуємо звернути увагу на курс «Програмування на Python» від Data Lab, щоб писати DAG впевнено.
Що таке Apache Airflow і навіщо він потрібен дата-інженеру?
Від cron до оркестрації: чому cron вже не вистачає
Cron — чудовий інструмент для простих задач. Але він нічого не знає про залежності між задачами, не вміє повторити кроки після збою, і не покаже вам наочно, де саме зупинився pipeline о третій ночі.
Оркестратор — це вже інший рівень. Він керує не просто розкладом, а логікою виконання: яка задача запускається після якої, що робити при помилці, як передати дані між кроками.
Apache Airflow — open-source інструмент оркестрації pipeline даних, який підтримує Apache Software Foundation. Він дозволяє описувати pipeline як Python-код, версіонувати його через Git, моніторити стан задач у веб-інтерфейсі і перезапускати окремі кроки без впливу на весь граф.
Airflow у стеку сучасного data engineer
Airflow посідає одне з ключових місць серед Must-have інструменти Data Engineer — поряд з dbt, Spark і хмарними сховищами даних. Він використовується в командах різного розміру: від невеликих стартапів до великих платформ з сотнями pipeline.
Головна перевага — pipeline як код. Це означає code review, версіонування, тестування і стандартний Git-workflow. Для команди це значно зручніше, ніж GUI-конфігуратори або таблиці в Confluence.
Що таке DAG в Airflow і як він працює?
DAG, Task, Operator — три кити Airflow
DAG (Directed Acyclic Graph) — це направлений ациклічний граф задач. Простіше кажучи: набір кроків із чітко визначеним порядком виконання, де немає циклів. DAG описує що робити і в якому порядку, але сам по собі нічого не виконує.
Task — одна атомарна одиниця роботи всередині DAG. Наприклад: завантажити файл, трансформувати таблицю, надіслати повідомлення.
Operator — шаблон задачі, який визначає як виконується конкретний крок. Найпоширеніші:
PythonOperator— виконує Python-функціюBashOperator— виконує bash-командуEmailOperator— надсилає emailSQLExecuteQueryOperator— виконує SQL-запити через SQL-провайдери (зокрема до PostgreSQL, MySQL та інших сумісних БД)
Як Airflow виконує задачі: Scheduler, Executor, Worker
Scheduler — компонент, який постійно моніторить DAG-файли і вирішує, які задачі готові до запуску. Він перевіряє розклад, залежності та стан попередніх задач.
Executor визначає як задачі виконуються технічно. Тут є кілька варіантів:
LocalExecutor— паралельне виконання на одній машиніCeleryExecutor/KubernetesExecutor— розподілене виконання на кількох вузлах
Worker — процес, який безпосередньо виконує код задачі.
Metadata DB зберігає стан усіх DAG і задач: коли запустилися, який статус, логи. За замовчуванням це SQLite, але для серйозного використання потрібен PostgreSQL або MySQL.
Таблиця: ключові компоненти Airflow та їх роль
| Компонент | Роль | Аналогія для розуміння |
|---|---|---|
| DAG | Опис pipeline: задачі та залежності | Маршрутна карта |
| Task | Один крок у pipeline | Крок маршруту |
| Operator | Шаблон виконання задачі | Інструмент для кроку |
| Scheduler | Вирішує коли і що запускати | Диспетчер |
| Executor | Визначає як задачі виконуються технічно | Виконавець |
| Worker | Процес, що безпосередньо виконує код | Робітник |
| Metadata DB | Зберігає стан DAG і задач | Журнал обліку |
Як встановити Apache Airflow локально: покроковий tutorial
Вимоги перед встановленням
- Python 3.10 або новіший (мінімально підтримується 3.9, але рекомендується 3.10+)
- pip актуальної версії
- Linux або macOS — або WSL2 на Windows (нативний Windows не рекомендується для Airflow)
- Мінімум 4 ГБ RAM для комфортної роботи
Встановлення через pip у віртуальне середовище
Airflow має складне дерево залежностей, тому встановлення без constraint-файлу часто призводить до конфліктів версій. Constraint-файл фіксує перевірені комбінації пакетів для конкретної версії Airflow.
# Створюємо і активуємо віртуальне середовище
python3 -m venv airflow-env
source airflow-env/bin/activate
# Встановлюємо змінну для домашньої директорії Airflow
export AIRFLOW_HOME=~/airflow
# Визначаємо версію Airflow і Python
AIRFLOW_VERSION=3.2.0
PYTHON_VERSION="$(python --version | cut -d " " -f 2 | cut -d "." -f 1-2)"
# Формуємо URL constraint-файлу
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt"
# Встановлюємо Airflow з constraint-файлом
pip install "apache-airflow==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"
Ініціалізація бази даних і запуск веб-сервера
Варіант 1 – найпростіший старт:
# Одна команда запускає все: ініціалізує БД, створює користувача,
# стартує scheduler, api-server і triggerer
airflow standalone
# Після запуску у терміналі буде показано логін і пароль адміністратора.
# UI доступний на http://localhost:8080Варіант 2 – ручний запуск окремих компонентів
# Ініціалізуємо та мігруємо метабазу (замість застарілого db init)
airflow db migrate
# Створюємо адміністратора
airflow users create \
--username admin \
--firstname Admin \
--lastname User \
--role Admin \
--email admin@example.com \
--password admin
# Запускаємо веб-сервер (у першому терміналі)
airflow api-server --port 8080
# Запускаємо scheduler (у другому терміналі)
airflow scheduler
# Запускаємо DAG processor (у третьому терміналі)
airflow dag-processorПрактична порада: SQLite підходить тільки для локального навчання. У продакшені використовуй PostgreSQL або MySQL — вони підтримують паралельне виконання задач і стабільніші під навантаженням.
Перший погляд на Airflow UI
Відкрий http://localhost:8080 і увійди з кредентіалами, які задав при створенні користувача (або які airflow standalone показав у терміналі). На головній сторінці — список DAG з їх статусами.
Основні елементи UI:
- Graph View — візуальне відображення залежностей між задачами
- Grid View — матриця запусків з вбудованим Gantt-чартом; рядки — задачі, колонки — запуски
- Calendar View — повернувся в Airflow 3.1 після відсутності в 3.0; показує запуски у вигляді календаря з фільтрацією за станами
- Кольори статусів: зелений — success, червоний — failed, жовтий — running, сірий — skipped
Пишемо перший DAG на Python: airflow dag python приклад з поясненням
Структура файлу DAG: що обов’язково, а що опціонально
Файл DAG — звичайний Python-файл, який Airflow парсить при кожному скані папки dags/. Airflow регулярно парсить DAG-файли як звичайні Python-модулі: код на рівні модуля виконується під час такого парсингу, а потім із файлу завантажуються об’єкти DAG. Тому будь-яка важка логіка (підключення до БД, HTTP-запити, читання великих файлів) на верхньому рівні модуля сповільнюватиме роботу планувальника і DAG processor.
Мінімальний DAG складається з:
- Імпортів
- Об’єкта
DAGз параметрами - Хоча б одного оператора (Task)
- Визначення залежностей між задачами
Визначаємо задачі та залежності між ними
Ось повний робочий приклад простого ETL-pipeline:
from datetime import datetime
from airflow.sdk import DAG
from airflow.operators.bash import BashOperator
from airflow.operators.python import PythonOperator
# default_args застосовуються до всіх задач у DAG
default_args = {
'owner': 'data-lab',
'retries': 1,
}
def transform_data():
"""Трансформація даних — тут буде реальна логіка"""
print("Трансформація: очищення та нормалізація даних")
def load_data():
"""Завантаження даних у сховище"""
print("Завантаження: запис результатів у базу даних")
with DAG(
dag_id='first_etl_pipeline', # унікальний ідентифікатор DAG
description='Простий ETL-pipeline для демонстрації',
schedule='@daily', # розклад запуску (schedule_interval deprecated у 2.x)
start_date=datetime(2024, 1, 1), # фіксована дата початку
catchup=False, # не запускати пропущені runs
default_args=default_args,
tags=['tutorial', 'etl'],
) as dag:
# Task 1: Extract — завантаження даних
extract = BashOperator(
task_id='extract',
bash_command='echo "Завантаження даних з джерела..." && sleep 2',
)
# Task 2: Transform — трансформація
transform = PythonOperator(
task_id='transform',
python_callable=transform_data,
)
# Task 3: Load — запис результатів
load = PythonOperator(
task_id='load',
python_callable=load_data,
)
# Визначаємо порядок виконання
extract >> transform >> load
Оператор >> задає залежності: extract виконується першим, після нього — transform, потім load. Якщо потрібно розгалуження, можна писати extract >> [transform_a, transform_b] >> load.
Примітка: Починаючи з Airflow 3.0, рекомендується імпортувати DAG та декоратори з нового стабільного namespace airflow.sdk. Старий імпорт from airflow import DAG поки працює для зворотної сумісності, але airflow.sdk гарантує стабільність API у майбутніх версіях.
5 параметрів DAG, які треба знати з першого дня
dag_id— унікальний ідентифікатор DAG у межах всього Airflow-інстансу. Дублікати призведуть до конфлікту.schedule— розклад запуску: cron-вираз ('0 6 * * *'), preset ('@daily','@hourly') абоNoneдля ручного запуску.start_date— дата, з якої Airflow починає відраховувати розклад. Завжди вказуй фіксовану дату, а неdatetime.now().catchup— якщоTrue, Airflow запустить всі пропущені runs відstart_dateдо поточного моменту. Для нових DAG зазвичай встановлюйFalse.default_args— словник параметрів за замовчуванням для всіх задач:owner,retries,retry_delay,email_on_failureтощо.
Запускаємо DAG і читаємо результат у UI
Збережи файл у папку ~/airflow/dags/. Через кілька секунд DAG з’явиться в UI або у виводі команди:
airflow dags listЩоб запустити DAG вручну через CLI:
airflow dags trigger first_etl_pipelineАбо натисни кнопку “Trigger DAG” у UI. Після запуску перейди в Graph View і клікни на будь-яку задачу — там є кнопка “Log”, де видно весь вивід виконання.
Позиція автора: що варто зрозуміти про DAG з першого разу
DAG — це декларація залежностей, а не послідовний скрипт. Airflow парсить DAG-файл регулярно (кожні кілька секунд), щоб оновити граф у метабазі. Тому код на рівні модуля виконується при кожному парсингу, а не тільки при запуску pipeline.
На практиці це означає: вся бізнес-логіка має бути всередині операторів або callable-функцій, а не на верхньому рівні файлу. Це одна з тих речей, яка не очевидна з першого погляду, але стає зрозумілою після першого ж інциденту з повільним scheduler’ом.
Типові помилки початківців в Apache Airflow і як їх уникнути
Помилки при написанні DAG
Помилка 1: catchup і поведінка за замовчуванням залежить від версії.
У Airflow 2.x параметр catchup за замовчуванням мав значення True — якщо встановити start_date=datetime(2023, 1, 1) і не вказати catchup=False, Airflow запускав усі пропущені runs за весь цей час. У Airflow 3.0 це виправлено: catchup_by_default тепер False за замовчуванням. Проте явно вказувати catchup=False у коді DAG — досі хороша практика для читабельності та сумісності з різними версіями.
Помилка 2: datetime.now() у start_date.start_date обчислюється при кожному парсингу DAG-файлу. Динамічна дата призводить до непередбачуваної поведінки планувальника. Використовуй фіксовану дату: datetime(2024, 1, 1).
Помилка 3: важкі операції на рівні модуля.
Підключення до бази даних, HTTP-запити або читання файлів поза межами операторів — все це виконується при кожному парсингу DAG. Scheduler починає гальмувати, і причину знайти непросто.
Помилка 4: використання execution_date у Airflow 3.x.
У Airflow 2.x execution_date відповідав початку розкладного інтервалу, а не моменту реального запуску — це часто плутало початківців. У Airflow 3.0 execution_date повністю видалений з контексту task instance і його використання викличе помилку DAG. Замість нього використовуй logical_date (або data_interval_start / data_interval_end для роботи з інтервалами)
Помилка 5: ігнорування ідемпотентності.
Задачі мають давати однаковий результат при повторному запуску з тими самими параметрами. Якщо задача вставляє рядки без перевірки на дублікати — повторний запуск зламає дані.
Помилки при налаштуванні середовища
Помилка 6: секрети в коді DAG.
Паролі, токени та ключі API прямо в DAG-файлі — серйозна проблема безпеки. Використовуй Airflow Connections і Variables через UI або CLI, або зовнішні secret backends (AWS Secrets Manager, HashiCorp Vault).
Помилка 7: запуск тільки api-server без scheduler.
Без активного scheduler жоден DAG не запуститься автоматично. Типова ситуація: UI відкривається, DAG видно, але runs не з’являються. Перевір, чи запущений airflow scheduler в окремому процесі.
FAQ: питання про Apache Airflow для початківців
Питання: Що таке Apache Airflow і навіщо він потрібен?
Відповідь: Apache Airflow — це відкрита платформа для програмного створення, планування та моніторингу pipeline даних. Вона дозволяє описувати послідовності задач у вигляді DAG на Python, версіонувати їх через Git і відстежувати виконання через веб-інтерфейс. Airflow широко використовується в data engineering для автоматизації ETL-процесів і оркестрації складних потоків даних — там, де cron вже не справляється з логікою залежностей і обробкою помилок.
Питання: Як створити перший DAG в Apache Airflow?
Відповідь: Щоб створити перший DAG, встанови Airflow через pip з constraint-файлом, підготуй метабазу командою airflow db migrate і напиши Python-файл з описом задач та їх залежностей.. Мінімальний DAG містить об’єкт DAG з параметрами, хоча б один оператор (наприклад, PythonOperator або BashOperator) і визначення порядку виконання через оператор >>. Файл розміщується у папці dags/ всередині AIRFLOW_HOME, після чого Scheduler автоматично його підхоплює.
Питання: Apache Airflow vs Prefect — що краще для початківців?
Відповідь: Airflow — більш зрілий інструмент з великою спільнотою, широкою екосистемою провайдерів і великою кількістю прикладів у відкритому доступі. Початкове налаштування складніше, але знання Airflow є більш затребуваним на ринку праці в data engineering. Prefect має сучасніший Python API і простіший старт, що робить його зручним для невеликих команд. Якщо мета — кар’єра data engineer, Airflow варто знати.
Питання: Чи є безкоштовна версія Apache Airflow?
Відповідь: Apache Airflow — повністю безкоштовний open-source інструмент з ліцензією Apache 2.0. Його можна розгорнути самостійно на будь-якому сервері або локально. Існують хмарні managed-рішення: Google Cloud Composer, Amazon MWAA і Astronomer — вони платні, але знімають операційний тягар з команди. Для навчання і розробки цілком достатньо безкоштовної локальної установки через pip або офіційного docker-compose від Airflow.
Питання: Які помилки найчастіше роблять початківці при роботі з Apache Airflow?
Відповідь: Найпоширеніші помилки: важкий код на рівні модуля DAG-файлу (виконується при кожному парсингу), використання datetime.now() у start_date замість фіксованої дати, ввімкнений catchup=True з давньою start_date, і нерозуміння того, що execution_date — це початок інтервалу, а не момент реального запуску. Також часто зберігають секрети прямо в коді DAG замість Airflow Connections і Variables.
Підсумок і що далі: як розвиватись після першого DAG
Наступні кроки у вивченні оркестрації pipeline даних
Після першого робочого DAG є кілька напрямків для розвитку:
- TaskFlow API — сучасний спосіб писати DAG у Airflow 3.x через декоратори
@task - XComs — механізм передачі невеликих даних між задачами
- Airflow Connections і Variables — безпечне зберігання конфігурацій і секретів
- Кастомні Operators — коли стандартних операторів недостатньо
- Деплой через Docker Compose — офіційний спосіб запустити повноцінний стек Airflow локально або на сервері
Якщо хочеш освоїти Airflow системно — разом з dbt, Spark і побудовою повноцінних data pipeline — рекомндуємо звернути увагу на спеціалізацію Analytics & Data Engineer. Це структурований шлях від основ до реальних інструментів продакшн-рівня за 5 місяців.
Найкращий спосіб закріпити матеріал — запустити перший DAG сьогодні. Навіть простий pipeline з трьох задач дає реальне розуміння того, як Airflow думає і як з ним працювати далі.
Формат:онлайн 
Тривалість:2 місяці 
