Создан
2014, Airbnb → Apache Software Foundation
Apache Airflow — оркестратор пайплайнов данных, где каждый рабочий процесс описывается кодом на Python. Нужен там, где ETL-задачи должны запускаться по расписанию и зависеть друг от друга.
Apache Airflow — платформа для создания, планирования и мониторинга рабочих процессов с данными. Каждый процесс описывается как DAG (directed acyclic graph) — направленный ациклический граф на Python.
Аirflow решает конкретную проблему: у вас есть цепочка задач, которые должны запускаться в нужном порядке, в нужное время, и вы хотите знать, что именно упало, когда что-то идёт не так. Вместо cron-скриптов и ручного запуска — декларативное описание зависимостей и централизованный мониторинг.
Открыт в 2014 году в Airbnb, сейчас под управлением Apache. Навык входит в стандартный стек инженера данных и аналитика, работающего с ETL.
2014, Airbnb → Apache Software Foundation
Python — DAG описываются на Python
DAG — направленный ациклический граф задач
DAG — это граф, где узлы — задачи, а стрелки — зависимости между ними. «Направленный» означает, что поток идёт в одну сторону. «Ациклический» — нет петель, которые создали бы бесконечные циклы. В Airflow каждый DAG — это Python-файл, который описывает структуру процесса.
Cron запускает скрипт по расписанию, но не знает о зависимостях между задачами и не отслеживает историю. Airflow знает: задача B запустится только после успешного завершения задачи A. При падении — понятный UI с историей запусков, логами и возможностью перезапустить конкретный шаг.
Каждая задача в Airflow должна быть идемпотентной: повторный запуск при backfill не должен создавать дубликаты данных. Это требует использования INSERT ... ON CONFLICT или замены файлов, а не дозаписи. Без идемпотентности retry и backfill становятся опасны.
От Python-файла с DAG до выполненной задачи — понятная цепочка. Важно понять роль каждого компонента, чтобы уметь диагностировать проблемы в реальных пайплайнах.
DAG-файл парсится
Scheduler решает, что запустить
На основе расписания (schedule_interval) и зависимостей scheduler создаёт DagRun — конкретный запуск DAG для заданной даты. Каждая задача в DagRun имеет свой статус.
Worker выполняет задачу
Worker забирает задачу из очереди и выполняет. Статус обновляется: queued → running → success/failed. Все логи доступны в UI.
Зависимые задачи запускаются
После успешного завершения задачи Airflow автоматически запускает все зависимые. При падении — downstream-задачи блокируются, а upstream-задачи не затронуты.
Airflow переносится между ролями: Инженер данных, Аналитик данных, Data Scientist. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.
Инженер данных — самый заметный профиль в распределении ролей по навыку.
Ещё 7 ролей используют Airflow
Текущий срез показывает активные вакансии сейчас. Распределение по ролям рассчитано по расширенной исторической выборке, поэтому значения могут быть выше текущего количества активных вакансий.
Airflow ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами — ниже они разобраны так, как встречаются в реальной работе.
Создать базовый DAG
Описать DAG с расписанием и двумя задачами с зависимостью. Проверить в UI, что граф корректен.
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime
with DAG('my_dag', schedule_interval='@daily', start_date=datetime(2026,1,1)) as dag:
t1 = PythonOperator(task_id='extract', python_callable=extract)
t2 = PythonOperator(task_id='load', python_callable=load)
t1 >> t2 Выполнить SQL-запрос
Использовать PostgresOperator для выполнения SQL внутри DAG. Подключение задаётся через Airflow Connection.
from airflow.providers.postgres.operators.postgres import PostgresOperator
run_query = PostgresOperator(
task_id='transform',
postgres_conn_id='my_pg',
sql='INSERT INTO summary SELECT ... FROM raw'
) Настроить retry
Задать количество повторных попыток и задержку между ними. Это стандарт для задач, которые могут упасть из-за временной...
task = PythonOperator(
task_id='load_api',
python_callable=load_from_api,
retries=3,
retry_delay=timedelta(minutes=5)
) Запустить backfill
Повторно выполнить DAG за прошлые даты. Используется при добавлении нового источника или исправлении ошибки в трансформации.
airflow dags backfill my_dag \
--start-date 2026-01-01 \
--end-date 2026-01-31 Настроить алерт на падение
Добавить on_failure_callback в DAG или задачу. Отправит уведомление в Slack или email при первом же падении.
def notify_failure(context):
send_slack_message(f"DAG {context['dag'].dag_id} failed")
with DAG('my_dag', on_failure_callback=notify_failure, ...) as dag:
... Диагностировать зависшую задачу
Открыть Grid View в UI, найти задачу в статусе running дольше ожидаемого. Проверить логи, при необходимости — очистить (Clear)...
Задача при повторном запуске вставляет дубликаты в базу или ломает агрегаты. Решение — проверять существование данных перед записью или использовать INSERT ... ON CONFLICT.
DAG-файл должен описывать структуру процесса, а не содержать бизнес-логику. Вся логика — в Python-функциях или SQL-файлах, которые вызывает DAG.
Airflow работает с execution_date — логической датой запуска, не временем фактического старта. Задача за «вчера» выполняется сегодня. Это нужно понять для правильной фильтрации данных.
Без retries задача при первом же временном сбое упадёт окончательно. В продакшене почти все задачи должны иметь retries=3 и разумный retry_delay.
Airflow стал стандартом де-факто в data engineering. Большинство команд с ETL-инфраструктурой используют именно его — альтернативы существуют, но экосистема провайдеров и многолетняя зрелость Airflow создают высокий порог замены. Навык сконцентрирован на инженерах данных: Airflow встречается в вакансиях инженера данных значительно чаще, чем в среднем по рынку — навык присутствует в большинстве JD этой роли. Аналитики и Data Scientist тоже взаимодействуют с Airflow, но чаще на уровне чтения и ручного запуска готовых DAG, а не создания новых пайплайнов с нуля. Managed Airflow от облачных провайдеров снизил операционный барьер для небольших команд.
Airflow нужен там, где важно быстро проверить гипотезу, сверить метрику или подготовить данные для следующего шага.
Такой навык редко живёт в одной профессии: он остаётся полезным в аналитике, продукте, разработке и соседних data-сценариях.
Инструменты вокруг меняются, но сама задача не исчезает, поэтому Airflow продолжает удерживать прикладной спрос.
Airflow формирует устойчивый спрос внутри своего рабочего сегмента.
Airflow сохраняет устойчивый прикладной спрос на рынке: 442 активных вакансий, #31 по рынку, 6.3% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.
#31 по рынку • 6.3% IT-вакансий
-76 вакансий и -12% к предыдущему месяцу.
Airflow — центральный навык инженера данных и ключевой маркер его уровня. Разработчик, умеющий проектировать производственные DAG с идемпотентностью, retry-логикой и централизованным мониторингом, устойчиво работает на уровне middle или...
89 вакансий с зарплатой в расширенной зарплатной выборке
Основной зарплатный ориентир по Senior-вакансиям
Senior - основной уровень рынка (50%)
Airflow редко живёт изолированно: чаще всего рынок видит его рядом с Python, SQL, ClickHouse. Самая плотная связка сейчас - Python: оба навыка встречаются вместе в 86% вакансий.
Главная связка: Python • 86% вакансий. Показываем общерыночные связки Airflow: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.
навыки, которые рынок чаще всего видит рядом в одной вакансии
Сейчас на рынке 30 активных junior-вакансий с Airflow. Это 8.5% всех вакансий по навыку, поэтому для старта важнее всего смотреть на реальный объём junior-окна и на стек, который рынок ждёт рядом.
8.5% всех вакансий по навыку • Senior / Junior 5.9x
Вход возможен, но рынок ждёт уже собранный стартовый стек.
Медианная вакансия с Airflow ожидает около 16 навыков в стеке. Это широкий стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.
навыки из junior-вакансий, где встречается Airflow
Airflow применяется везде, где есть регулярные задачи с данными, зависящие друг от друга по порядку выполнения. Основная аудитория — инженеры данных, аналитики и ML-инженеры. В стеке обычно рядом Python и SQL.
Загрузить данные из источника, трансформировать и записать в хранилище. Airflow обеспечивает порядок шагов и мониторинг каждого.
Ежедневное переобучение модели: загрузка свежих данных, обучение, валидация, публикация артефакта. Каждый шаг — задача в DAG.
Генерация дашбордов и агрегаций по расписанию. Airflow запускает SQL-задачи в нужном порядке и уведомляет при ошибке.
Синхронизация данных между CRM, хранилищем и аналитической платформой. Airflow управляет порядком и повторными попытками.
Airflow заметен в 4 направлениях рынка с долей выше 5%.
Знать синтаксис DAG недостаточно. Реальная ценность — умение строить надёжные пайплайны, которые корректно обрабатывают ошибки и легко диагностируются.
Описать цепочку задач с зависимостями. Использовать операторы (Bash, Python, SQL). Настроить расписание и retry-логику.
Задачи должны работать корректно при повторном запуске. Это критично для backfill — повторного заполнения данных за прошлые даты.
Читать Graph View и Gantt в UI. Диагностировать зависшие задачи. Настраивать алерты на падения через email или Slack.
Настраивать подключения к базам данных, S3, Spark через Airflow Connections. Управлять секретами через Secrets Backend.
Рынок оркестраторов данных вырос — у Airflow появились серьёзные конкуренты. Выбор зависит от требований к масштабированию, экосистеме и опыту команды.
Prefect — более современный оркестратор с лучшим динамическим пайплайном и облачным UI. Airflow побеждает зрелостью, огромным сообществом и числом провайдер-пакетов. Если команда уже знает Airflow —...
dbt — инструмент трансформации данных внутри хранилища (SQL). Airflow — оркестратор, который может запускать dbt как одну из задач. Они дополняют друг друга, а не конкурируют.
Spark — движок обработки больших данных. Airflow оркестрирует Spark-джобы через SparkSubmitOperator. Airflow планирует, Spark считает.
При сбое смотрят не только код задачи. Проверяют DAG, расписание, интервал данных, логи, подключения, секреты, очередь и воркеры. Важно помнить границу: Airflow хранит состояние запуска, а не качество данных. Шаг может быть зелёным, а таблица — неполной. Поэтому в рабочем процессе нужны проверки после записи и понятный владелец цепочки. Иначе интерфейс покажет красивый граф, но не ответит, кто чинит ночное падение.
Проверяют, корректно ли описаны задачи, зависимости, параметры, расписание и нет ли тяжёлых действий при загрузке DAG.
Многие ошибки возникают из-за неверного периода: задача считает не тот день, пересчитывает прошлое или пропускает окно загрузки.
Логи показывают, где упал шаг: в SQL, Python, подключении, правах, таймауте, памяти, данных или внешнем сервисе.
Неверный пароль, истёкший токен, недоступная база или изменение прав часто выглядят как падение бизнес-задачи.
Если задачи стоят в очереди, причина может быть в ресурсах, настройках исполнителя, недоступном воркере или слишком высокой параллельности.
Перед ручным перезапуском нужно понять, какие шаги уже записали результат и можно ли повторить их без дублей.
Перспективы Airflow завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.
Значительное обновление архитектуры: новый планировщик, улучшенный UI, поддержка event-driven DAG. Переход занимает время, но направление понятно.
Cloud-провайдеры предлагают управляемые версии: AWS MWAA, Google Cloud Composer, Astronomer. Снижают операционную нагрузку, но добавляют зависимость от платформы.
Airflow 2.4+ вводит dataset-dependent DAG: запуск не по времени, а по событию обновления набора данных. Это сдвиг от schedule_interval к event-driven оркестрации.
DAG из трёх задач: забрать курсы по открытому API, провалидировать и записать в PostgreSQL по паттерну delete-insert, отправить сводку в Telegram. Демонстрирует расписание, retries, идемпотентность и работу с...
Пайплайн ELT: сенсор ждёт файлы с событиями в объектном хранилище, загрузка в staging-слой ClickHouse, пересчёт агрегированной витрины SQL-запросами, проверки качества данных перед публикацией. Показывает работу с...
Генерация однотипных пайплайнов из YAML-конфига и dynamic task mapping для параллельной обработки таблиц, число которых меняется от запуска к запуску. Плюс алерты об ошибках через on_failure_callback. Уровень уверенного...
DAG связывает подготовку датасета в Spark, обучение модели, валидацию метрик через BranchPythonOperator (деплой только при улучшении качества) и выкладку артефакта. Демонстрирует ветвление, XCom для передачи метрик и...
Для старта с Airflow достаточно базового Python и знания SQL. Лучший первый шаг — официальный Docker Compose из документации: он поднимает полное окружение одной командой docker compose up. После первого DAG важно сразу разобрать idempotency — задача должна корректно отрабатывать при повторном запуске без дубликатов. Это ключевая концепция для backfill: повторного заполнения данных за прошлые даты. Потом стоит изучить retry и on_failure_callback: в продакшене пайплайны падают, и важно понимать, как Airflow реагирует на ошибки и как настроить уведомления в Slack или email при первом же сбое. Для первых шагов рекомендуют BigDataSchool или DataCamp Introduction to Airflow.
Освоить базовый Python
Уметь писать функции, работать с datetime и понимать декораторы. Это всё, что нужно для первых DAG.
Понять концепцию DAG
Разобрать, что такое задача, зависимость и расписание. Понять разницу между execution_date и фактическим временем запуска.
Поднять локально и написать первый DAG
Запустить через Docker Compose. Создать DAG с двумя задачами. Запустить вручную, изучить Graph View и логи.
Разобрать idempotency и retry
Убедиться, что задачи работают корректно при повторном запуске. Настроить retries и retry_delay. Понять backfill.
Соответствие — доля тем навыка, которые охватывает программа курса
Airflow — это Python, поэтому для старта достаточно базовых знаний языка и SQL. Самый быстрый вход — официальный Docker Compose из документации Airflow: команда docker compose up запускает webserver, scheduler, worker и базу данных одновременно. После этого создайте простой DAG с двумя задачами и зависимостью между ними. Запустите вручную через UI и посмотрите на Graph View, Gantt и логи каждой задачи. Этот первый опыт даёт интуицию о том, как Airflow думает о зависимостях и времени выполнения. После этого добавьте реальный PostgresOperator и подключение через Airflow Connections.
Используйте официальный docker-compose.yaml из документации Airflow. Команда docker compose up запустит webserver, scheduler, worker и базу данных.
Создайте Python-файл в папке dags/. Определите DAG с расписанием @daily и две задачи через PythonOperator с зависимостью task_a >> task_b.
Откройте http://localhost:8080. Включите DAG, запустите вручную (Trigger DAG). Посмотрите Graph View, Gantt и логи каждой задачи.
Замените тестовую функцию на реальную: чтение из PostgreSQL, запись в CSV или вызов API. Подключите через Airflow Connection в UI Admin → Connections.
Это система, которая запускает задачи в нужном порядке по расписанию. Вы описываете на Python, что нужно сделать и что от чего зависит — Airflow берёт управление на себя. Если шаг падает, видно где и почему, и можно перезапустить только его, не весь пайплайн.
DAG (directed acyclic graph) — это Python-файл, который описывает структуру процесса: какие задачи есть, в каком порядке выполняются и по какому расписанию. «Ациклический» означает, что задачи не образуют циклы — поток идёт строго вперёд, без петель.
Cron запускает скрипт, но не знает о зависимостях и не отслеживает историю. Airflow знает: задача B запустится только после успешного A. При падении — UI с историей, логами и возможностью перезапустить конкретный шаг. При больших числе задач это принципиально важно.
При падении задача переходит в статус failed. Если настроен retries — Airflow повторяет попытку через retry_delay. Если настроен on_failure_callback — отправляет уведомление в Slack или email. Downstream-задачи блокируются автоматически. Задачу можно вручную перезапустить через UI после того, как ошибка исправлена.
При падении задача переходит в статус failed. Если настроен retries — Airflow повторяет попытку через retry_delay. Если настроен on_failure_callback — отправляет уведомление. Downstream-задачи блокируются и не запускаются. Задачу можно вручную перезапустить через UI после исправления.
dbt трансформирует данные внутри хранилища с помощью SQL-моделей. Airflow оркестрирует задачи и запускает dbt как один из шагов пайплайна. Они дополняют друг друга: Airflow управляет порядком и расписанием, dbt выполняет трансформации. Использовать их вместе — стандарт в современных data engineering командах.