airflow
Apache Airflow 2.10.3
Apache Airflow (или просто Airflow) — это платформа для программного создания, планирования и мониторинга рабочих процессов.
Когда рабочие процессы определяются как код, они становятся более удобными для сопровождения, версионирования, тестирования и совместной работы.
Используйте Airflow для создания рабочих процессов в виде направленных ациклических графов (DAG) задач. Планировщик Airflow выполняет ваши задачи на массиве воркеров, следуя указанным зависимостям. Богатые утилиты командной строки позволяют с легкостью выполнять сложные операции с группами DAG. Богатый пользовательский интерфейс позволяет легко визуализировать рабочие конвейеры, отслеживать ход выполнения и устранять проблемы, когда это необходимо.
Оглавление
Airflow лучше всего работает с рабочими процессами, которые в основном статичны и медленно меняются. Когда структура DAG одинакова от одного запуска к другому, это проясняет единицу работы и непрерывность. Другие подобные проекты включают Луиджи, Узи и Азкабан.
Airflow обычно используется для обработки данных, но существует мнение, что задачи в идеале должны быть идемпотентными (т. е. результаты задачи будут одинаковыми и не будут создавать дублированные данные в целевой системе) и не должны передавать большие объемы данных. от одной задачи к другой (хотя задачи могут передавать метаданные с помощью функции XCom Airflow). Для задач с большим объемом данных рекомендуется делегировать выполнение сторонним службам, специализирующимся на этом типе работы.
Airflow не является потоковым решением, но он часто используется для обработки данных в реальном времени, пакетно извлекая данные из потоков.
Apache Airflow протестирован с:
| Основная версия (для разработчиков) | Стабильная версия (2.10.3) | |
|---|---|---|
| Питон | 3.9, 3.10, 3.11, 3.12 | 3.8, 3.9, 3.10, 3.11, 3.12 |
| Платформа | AMD64/ARM64(*) | AMD64/ARM64(*) |
| Кубернетес | 1,28, 1,29, 1,30, 1,31 | 1,27, 1,28, 1,29, 1,30 |
| PostgreSQL | 13, 14, 15, 16, 17 | 12, 13, 14, 15, 16 |
| MySQL | 8.0, 8.4, Инновации | 8.0, 8.4, Инновации |
| SQLite | 3.15.0+ | 3.15.0+ |
* Экспериментальный
Примечание . MariaDB не тестируется и не рекомендуется.
Примечание . SQLite используется в тестах Airflow. Не используйте его в производстве. Мы рекомендуем использовать последнюю стабильную версию SQLite для локальной разработки.
Примечание . В настоящее время Airflow можно запускать в операционных системах, совместимых с POSIX. При разработке он регулярно тестируется на довольно современных дистрибутивах Linux и последних версиях macOS. В Windows вы можете запустить его через WSL2 (подсистема Windows для Linux 2) или через контейнеры Linux. Работа по добавлению поддержки Windows отслеживается по номеру #10388, но она не является приоритетной. Вам следует использовать только дистрибутивы на базе Linux в качестве «производственной» среды выполнения, поскольку это единственная поддерживаемая среда. Единственный дистрибутив, который используется в наших CI-тестах и в образе DockerHub, управляемом сообществом, — это Debian Bookworm .
Посетите официальную документацию веб-сайта Airflow (последняя стабильная версия), чтобы получить помощь по установке Airflow, началу работы или пройти более полное руководство.
Примечание. Если вы ищете документацию для основной ветки (последней ветки разработки): вы можете найти ее на s.apache.org/airflow-docs.
Для получения дополнительной информации о предложениях по улучшению воздушного потока (AIP) посетите Airflow Wiki.
Документацию для зависимых проектов, таких как пакеты поставщиков, образ Docker, Helm Chart, вы найдете в указателе документации.
Мы публикуем Apache Airflow как пакет apache-airflow в PyPI. Однако иногда его установка может оказаться сложной задачей, поскольку Airflow — это одновременно библиотека и приложение. Библиотеки обычно оставляют свои зависимости открытыми, а приложения обычно закрепляют их, но мы не должны делать ни того, ни другого одновременно. Мы решили сохранить наши зависимости максимально открытыми (в pyproject.toml ), чтобы пользователи могли при необходимости устанавливать разные версии библиотек. Это означает, что pip install apache-airflow время от времени не будет работать или приведет к непригодной для использования установке Airflow.
Однако для обеспечения повторяемости установки мы храним набор «заведомо работающих» файлов ограничений в потерянных ветвях constraints-main и constraints-2-0 . Мы храним эти «заведомо работающие» файлы ограничений отдельно для каждой основной/вспомогательной версии Python. Вы можете использовать их в качестве файлов ограничений при установке Airflow из PyPI. Обратите внимание, что вам необходимо указать правильный тег/версию/ветвь Airflow и версии Python в URL-адресе.
Примечание. В настоящее время официально поддерживается только установка
pip.
Хотя Airflow можно установить с помощью таких инструментов, как Poetry или pip-tools, они не используют тот же рабочий процесс, что и pip , особенно когда речь идет об управлении ограничениями и требованиями. Установка через Poetry или pip-tools в настоящее время не поддерживается.
Существуют известные проблемы с bazel , которые могут привести к циклическим зависимостям при использовании его для установки Airflow. Пожалуйста, переключитесь на pip если у вас возникнут такие проблемы. Сообщество Bazel работает над решением проблемы в this PR <https://github.com/bazelbuild/rules_python/pull/1166> _, так что, возможно, новые версии bazel справятся с этой проблемой.
Если вы хотите установить Airflow с помощью этих инструментов, вам следует использовать файлы ограничений и преобразовать их в соответствующий формат и рабочий процесс, который требуется вашему инструменту.
pip install ' apache-airflow==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "pip install ' apache-airflow[postgres,google]==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "Информацию об установке пакетов поставщиков см. в разделе «Поставщики».
Apache Airflow — это проект Apache Software Foundation (ASF), и наши официальные выпуски исходного кода:
Согласно правилам ASF, выпущенных исходных пакетов должно быть достаточно, чтобы пользователь мог собрать и протестировать выпуск при условии, что у него есть доступ к соответствующей платформе и инструментам.
Существуют и другие способы установки и использования Airflow. Это «удобные» методы — они не являются «официальными выпусками», как указано в ASF Release Policy , но их могут использовать пользователи, которые не хотят создавать программное обеспечение самостоятельно.
Это - в порядке наиболее распространенных способов установки Airflow:
pip .docker , используйте их в Kubernetes, Helm Charts, docker-compose , docker swarm и т. д. Вы можете узнать больше об использовании, настройке и расширении образов в последних документах, а также узнать подробности о внутренних компонентах. в документе изображений.Все эти артефакты не являются официальными релизами, но подготовлены с использованием официально выпущенных источников. Некоторые из этих артефактов относятся к «разрабатываемым» или «предварительным версиям», и они четко обозначены как таковые в соответствии с Политикой ASF.
Группы обеспечения доступности баз данных : обзор всех групп обеспечения доступности баз данных в вашей среде.
Сетка : Сеточное представление группы обеспечения доступности баз данных, охватывающее время.
График : Визуализация зависимостей группы обеспечения доступности баз данных и их текущего состояния для конкретного запуска.
Продолжительность задачи : общее время, потраченное на выполнение различных задач с течением времени.
Гантт : Продолжительность и перекрытие группы обеспечения доступности баз данных.
Код : быстрый способ просмотра исходного кода группы обеспечения доступности баз данных.
Начиная с Airflow 2.0.0, мы поддерживаем строгий подход SemVer для всех выпущенных пакетов.
Мы согласились с несколькими конкретными правилами, определяющими детали управления версиями различных пакетов:
google 4.1.0 и amazon 3.0.3 могут быть успешно установлены с Airflow 2.1.2 . Если существуют ограничения перекрестных зависимостей между поставщиками и пакетами Airflow, они присутствуют в поставщиках как ограничения install_requires . Мы стремимся сохранить обратную совместимость провайдеров со всеми ранее выпущенными версиями Airflow 2, но иногда будут происходить критические изменения, из-за которых у некоторых или всех провайдеров может быть указана минимальная версия Airflow.Жизненный цикл версии Apache Airflow:
| Версия | Текущий патч/второстепенный | Состояние | Первый выпуск | Ограниченная поддержка | Прекращено/прекращено |
|---|---|---|---|---|---|
| 2 | 2.10.3 | Поддерживается | 17 декабря 2020 г. | подлежит уточнению | подлежит уточнению |
| 1.10 | 1.10.15 | окончание срока действия | 27 августа 2018 г. | 17 декабря 2020 г. | 17 июня 2021 г. |
| 1,9 | 1.9.0 | окончание срока действия | 3 января 2018 г. | 27 августа 2018 г. | 27 августа 2018 г. |
| 1,8 | 1.8.2 | окончание срока действия | 19 марта 2017 г. | 3 января 2018 г. | 3 января 2018 г. |
| 1,7 | 1.7.1.2 | окончание срока действия | 28 марта 2016 г. | 19 марта 2017 г. | 19 марта 2017 г. |
Версии с ограниченной поддержкой будут поддерживаться только с исправлениями безопасности и критических ошибок. Версии EOL не получат никаких исправлений и поддержки. Мы всегда рекомендуем всем пользователям запускать последнюю доступную второстепенную версию для любой используемой основной версии. Мы настоятельно рекомендуем выполнить обновление до последней основной версии Airflow в ближайшее удобное время и до даты прекращения выпуска.
Начиная с Airflow 2.0, мы согласились с определенными правилами, которым мы следуем при поддержке Python и Kubernetes. Они основаны на официальном графике выпуска Python и Kubernetes, подробно изложенном в Руководстве разработчика Python и политике отклонения версий Kubernetes.
Мы прекращаем поддержку версий Python и Kubernetes, когда они достигают EOL. За исключением Kubernetes, версия продолжает поддерживаться Airflow, если два крупных облачных провайдера по-прежнему поддерживают ее. Мы прекращаем поддержку этих версий EOL в основной версии сразу после даты EOL, и она фактически удаляется, когда мы выпускаем первую новую MINOR (или MAJOR, если нет новой MINOR-версии) Airflow. Например, для Python 3.9 это означает, что мы прекратим поддержку основной версии сразу после 27.06.2023, а первая ОСНОВНАЯ или МИНОРНАЯ версия Airflow, выпущенная после нее, не будет иметь ее.
Мы поддерживаем новые версии Python/Kubernetes в основном после их официального выпуска. Как только мы заставим их работать в нашем конвейере CI (что может быть не сразу из-за зависимостей, которые в основном догоняют новые версии Python), мы выпускаем новые образы. /support в Airflow на основе рабочей настройки CI.
Эта политика является максимальным, что означает, что могут возникнуть ситуации, когда мы можем прекратить поддержку раньше, если этого потребуют обстоятельства.
Сообщество Airflow предоставляет удобно упакованные образы контейнеров, которые публикуются всякий раз, когда мы публикуем выпуск Apache Airflow. Эти изображения содержат:
Версия базового образа ОС — это стабильная версия Debian. Airflow поддерживает использование всех активных на данный момент стабильных версий — как только все зависимости Airflow поддерживают сборку, и мы настраиваем конвейер CI для сборки и тестирования версии ОС. Примерно за 6 месяцев до прекращения регулярной поддержки предыдущей стабильной версии ОС Airflow переключает выпущенные образы на использование последней поддерживаемой версии ОС.
Например, переход с Debian Bullseye на Debian Bookworm был реализован до выпуска версии 2.8.0 в октябре 2023 года, и Debian Bookworm будет единственным вариантом, поддерживаемым начиная с Airflow 2.10.0.
Пользователи по-прежнему смогут создавать свои образы с использованием стабильных выпусков Debian до тех пор, пока не закончится регулярная поддержка, а сборка и проверка образов не будет происходить в нашем CI, но модульные тесты с использованием этого образа в main ветке не выполнялись.
Airflow имеет множество зависимостей - прямых и транзитивных, а также Airflow является одновременно библиотекой и приложением, поэтому наша политика в отношении зависимостей должна включать как стабильность установки приложения, так и возможность установки более новых версий зависимостей для тех пользователей, которые разрабатывают. ДАГ. Мы разработали подход, в котором используются constraints , чтобы обеспечить повторяемость установки airflow, при этом мы не ограничиваем наших пользователей в обновлении большинства зависимостей. В результате мы решили не устанавливать верхнюю границу версий зависимостей Airflow по умолчанию, если только у нас нет веских причин полагать, что верхняя граница необходима из-за важности зависимости, а также риска, связанного с обновлением конкретной зависимости. Мы также устанавливаем верхние границы для зависимостей, которые, как мы знаем, вызывают проблемы.
Наш механизм ограничений автоматически обеспечивает поиск и обновление всех зависимостей, не имеющих верхней границы (при условии, что все тесты пройдены). Наши main сбои сборки будут указывать на наличие версий зависимостей, которые нарушают наши тесты, что указывает на то, что мы должны либо выполнить их верхнюю привязку, либо исправить наш код/тесты, чтобы учесть изменения в исходном коде от этих зависимостей.
Всякий раз, когда мы устанавливаем верхнюю границу такой зависимости, мы всегда должны комментировать, почему мы это делаем, т. е. у нас должна быть веская причина, почему зависимость является верхней границей. Также следует упомянуть, каково условие снятия привязки.
Эти зависимости сохраняются в pyproject.toml .
Есть несколько зависимостей, которые, по нашему мнению, являются достаточно важными, чтобы устанавливать для них верхние ограничения по умолчанию, поскольку известно, что они следуют предсказуемой схеме управления версиями, и мы знаем, что новые версии этих зависимостей с большой вероятностью принесут критические изменения. Мы обязуемся регулярно проверять и пытаться обновиться до новых версий зависимостей по мере их выпуска, но это процесс вручную.
Важными зависимостями являются:
SQLAlchemy : верхняя граница конкретной MINOR-версии (известно, что SQLAlchemy удаляет устаревшие версии и вносит критические изменения, особенно если поддержка разных баз данных варьируется и меняется с разной скоростью)Alembic : важно, чтобы наши миграции выполнялись предсказуемо и эффективно. Он разработан совместно с SQLAlchemy. Наш опыт работы с Alembic показывает, что он очень стабилен в версии MINOR.Flask : мы используем Flask в качестве основы нашего веб-интерфейса и API. Мы знаем, что основная версия Flask, скорее всего, внесет критические изменения во все эти версии, поэтому имеет смысл ограничить ее ОСНОВНОЙ версией.werkzeug : известно, что библиотека вызывает проблемы в новых версиях. Он тесно связан с библиотеками Flask, и мы должны обновлять их вместе.celery : Сельдерей является важнейшим компонентом Airflow, поскольку он используется для CeleryExecutor (и ему подобных). Celery следует за SemVer, поэтому нам следует привязать его к следующей версии MAJOR. Кроме того, когда мы обновляем верхнюю версию библиотеки, мы должны убедиться, что минимальная версия Airflow поставщика Celery обновлена.kubernetes : Kubernetes — важнейший компонент Airflow, поскольку он используется для KubernetesExecutor (и ему подобных). Библиотека Kubernetes Python следует за SemVer, поэтому нам следует привязать ее к следующей ОСНОВНОЙ версии. Кроме того, когда мы обновляем верхнюю версию библиотеки, мы должны убедиться, что минимальная версия Airflow поставщика Kubernetes обновлена.Основная часть Airflow — это ядро Airflow, но мощь Airflow также исходит от ряда поставщиков, которые расширяют основные функциональные возможности и выпускаются отдельно, даже если мы для удобства сохраним их (на данный момент) в одном монорепозитории. Подробнее о провайдерах можно прочитать в документации провайдеров. У нас также реализован набор политик для поддержки и освобождения поставщиков, управляемых сообществом, а также подход к отношению сообщества к сторонним поставщикам в документе поставщиков.
Эти extras и зависимости providers сохраняются в provider.yaml каждого поставщика.
По умолчанию мы не должны устанавливать верхние границы зависимостей для провайдеров, однако сопровождающий каждого провайдера может решить добавить дополнительные ограничения (и обосновать их комментариями).
Хотите помочь в создании Apache Airflow? Ознакомьтесь с руководством наших участников, чтобы получить подробный обзор того, как внести свой вклад, включая инструкции по настройке, стандарты кодирования и рекомендации по запросам на включение.
Если вам не терпится внести свой вклад и вы хотите начать как можно скорее, ознакомьтесь с кратким руководством по вкладу здесь!
Официальные образы Docker (контейнера) для Apache Airflow описаны в изображениях.
+1s как члена PMC, так и коммиттера считаются обязательными. Нам известно около 500 организаций, которые используют Apache Airflow (но, вероятно, их гораздо больше).
Если вы используете Airflow – смело делайте пиар о добавлении вашей организации в список.
Airflow — это работа сообщества, но основные коммиттеры/сопровождающие отвечают за рассмотрение и объединение запросов на поддержку, а также за управление обсуждением запросов на новые функции. Если вы хотите стать сопровождающим, ознакомьтесь с требованиями к коммиттеру Apache Airflow.
Часто вы увидите проблему, которая назначена определенной вехе с версией Airflow, или PR, который объединяется с основной веткой, и вы можете задаться вопросом, в какой версии будут выпущены объединенные PR или в какой версии будут исправлены проблемы. в. Ответ на это обычный - зависит от различных сценариев. Ответ на PR и Issues разный.
Чтобы добавить немного контекста, мы следуем схеме управления версиями Semver, как описано в процессе выпуска Airflow. Более подробная информация подробно описана в этом README в главе «Семантическое управление версиями», но вкратце, у нас есть версии Airflow MAJOR.MINOR.PATCH .
MAJOR увеличивается в случае критических изменений.MINOR версия увеличивается при добавлении новых функций.PATCH увеличивается, если есть только исправления ошибок и изменения только в документации. Обычно мы выпускаем MINOR версии Airflow из ветки, названной в честь МИНОР-версии. Например, выпуски 2.7.* выпускаются из v2-7-stable , 2.8.* выпускаются из v2-8-stable и т. д.
Большую часть времени в нашем цикле выпуска, когда ветка для следующей ветки MINOR еще не создана, все PR, объединенные с main (если они не будут отменены), найдут свой путь к следующему MINOR выпуску. Например, если последняя версия — 2.7.3 , а v2-8-stable еще не создана, следующая версия MINOR — 2.8.0 , и все PR, объединенные с основной, будут выпущены в 2.8.0 . Однако некоторые PR (исправления ошибок и изменения только для документации) при объединении могут быть перенесены в текущую ветку MINOR и выпущены в следующем выпуске PATCHLEVEL . Например, если 2.8.1 уже выпущена и мы работаем над 2.9.0dev , то пометка PR с вехой 2.8.2 означает, что она будет выбрана для ветки v2-8-test и выпущена в 2.8.2rc1 . и, наконец, в 2.8.2 .
Когда мы готовимся к следующему выпуску MINOR , мы вырезаем новую ветку v2-*-test и v2-*-stable и готовим alpha и beta версии для следующей версии MINOR , PR, объединенные с основной версией, все равно будут выпущены в следующем выпуске MINOR . пока rc версия не будет вырезана. Это происходит потому, что ветки v2-*-test и v2-*-stable перебазируются поверх основной при подготовке следующих beta и версий rc . Например, когда мы вырезаем версию 2.10.0beta1 , все, что было добавлено в основную версию до выпуска 2.10.0rc1 , найдет свой путь в 2.10.0rc1.
Затем, как только мы подготовим первого кандидата RC для выпуска MINOR, мы прекратим перемещение веток v2-*-test и v2-*-stable , а PR, объединенные с основным, будут выпущены в следующем выпуске MINOR . Однако некоторые PR (исправления ошибок и изменения только для документации) при объединении могут быть перенесены в текущую ветку MINOR и выпущены в следующем выпуске PATCHLEVEL - например, когда последней выпущенной версией из v2-10-stable является 2.10.0rc1 , некоторые из PR из main могут быть помечены коммиттерами как веха 2.10.0 , менеджер релиза попытается выбрать их в ветку релиза. В случае успеха они будут выпущены в 2.10.0rc2 , а затем в 2.10.0 . Это также относится и к последующим версиям PATCHLEVEL . Когда, например, 2.10.1 уже выпущена, пометка PR с вехой 2.10.2 будет означать, что она будет выбрана для v2-10-stable и выпущена в 2.10.2rc1 и, в конечном итоге, в 2.10.2 .
Окончательное решение о выборе принимает релиз-менеджер.
Маркировка проблем с помощью вех немного отличается. Специалисты по сопровождению обычно не отмечают проблемы вехами, обычно они отмечаются только в PR. Если PR, связанный с проблемой (и «его исправлением»), будет объединен и выпущен в определенной версии в соответствии с процессом, описанным выше, проблема будет автоматически закрыта, для проблемы не будет установлена веха, вам необходимо проверить PR, который исправлена проблема с возможностью увидеть, в какой версии он был выпущен.
Однако иногда сопровождающие помечают проблемы определенной вехой, что означает, что проблема важна для того, чтобы стать кандидатом на рассмотрение при подготовке выпуска. Поскольку это проект с открытым исходным кодом, в котором практически все участники добровольно отдают свое время, нет никакой гарантии, что конкретная проблема будет исправлена в конкретной версии. Мы не хотим откладывать выпуск из-за того, что какая-то проблема не устранена, поэтому в этом случае менеджер выпуска переназначит такие неустраненные проблемы на следующий этап, если они не будут исправлены вовремя для текущего выпуска. Таким образом, веха в выпуске — это скорее намерение, на которое следует обратить внимание, чем обещание, что оно будет исправлено в версии.
Дополнительную информацию и часто задаваемые вопросы о выпуске уровня исправлений можно найти в документе «Что входит в следующий выпуск» в папке dev репозитория.
Да! Обязательно соблюдайте политику использования товарных знаков Apache Foundation и брендбук Apache Airflow. Самые актуальные логотипы можно найти в этом репозитории и на веб-сайте Apache Software Foundation.
Инфраструктуру CI для Apache Airflow спонсируют:
