airflow
Apache Airflow 2.10.3
Apache Airflow (ou simplement Airflow) est une plate-forme permettant de créer, planifier et surveiller des flux de travail par programmation.
Lorsque les flux de travail sont définis sous forme de code, ils deviennent plus maintenables, versionnables, testables et collaboratifs.
Utilisez Airflow pour créer des flux de travail sous forme de graphiques acycliques dirigés (DAG) de tâches. Le planificateur Airflow exécute vos tâches sur un ensemble de nœuds de calcul tout en suivant les dépendances spécifiées. De riches utilitaires de ligne de commande facilitent la réalisation d'interventions chirurgicales complexes sur les DAG. L'interface utilisateur riche facilite la visualisation des pipelines exécutés en production, le suivi de la progression et le dépannage des problèmes en cas de besoin.
Table des matières
Airflow fonctionne mieux avec des flux de travail qui sont pour la plupart statiques et qui évoluent lentement. Lorsque la structure du DAG est similaire d’une exécution à l’autre, elle clarifie l’unité de travail et la continuité. D'autres projets similaires incluent Luigi, Oozie et Azkaban.
Airflow est couramment utilisé pour traiter les données, mais estime que les tâches devraient idéalement être idempotentes (c'est-à-dire que les résultats de la tâche seront les mêmes et ne créeront pas de données en double dans un système de destination) et ne devraient pas transmettre de grandes quantités de données. d'une tâche à la suivante (bien que les tâches puissent transmettre des métadonnées à l'aide de la fonctionnalité XCom d'Airflow). Pour les tâches volumineuses et gourmandes en données, une bonne pratique consiste à déléguer à des services externes spécialisés dans ce type de travail.
Airflow n'est pas une solution de streaming, mais il est souvent utilisé pour traiter des données en temps réel, en extrayant les données des flux par lots.
Apache Airflow est testé avec :
| Version principale (développement) | Version stable (2.10.3) | |
|---|---|---|
| Python | 3.9, 3.10, 3.11, 3.12 | 3.8, 3.9, 3.10, 3.11, 3.12 |
| Plate-forme | AMD64/ARM64(*) | AMD64/ARM64(*) |
| Kubernetes | 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, Innovations | 8.0, 8.4, Innovations |
| SQLite | 3.15.0+ | 3.15.0+ |
* Expérimental
Remarque : MariaDB n'est pas testé/recommandé.
Remarque : SQLite est utilisé dans les tests Airflow. Ne l'utilisez pas en production. Nous vous recommandons d'utiliser la dernière version stable de SQLite pour le développement local.
Remarque : Airflow peut actuellement être exécuté sur des systèmes d'exploitation compatibles POSIX. Pour le développement, il est régulièrement testé sur des distributions Linux assez modernes et des versions récentes de macOS. Sous Windows, vous pouvez l'exécuter via WSL2 (Windows Subsystem for Linux 2) ou via Linux Containers. Le travail d'ajout de la prise en charge de Windows est suivi via #10388, mais ce n'est pas une priorité élevée. Vous ne devez utiliser que des distributions basées sur Linux comme environnement d'exécution de « Production », car c'est le seul environnement pris en charge. La seule distribution utilisée dans nos tests CI et utilisée dans l'image DockerHub gérée par la communauté est Debian Bookworm .
Consultez la documentation officielle du site Web Airflow (dernière version stable ) pour obtenir de l'aide sur l'installation d'Airflow, pour démarrer ou pour parcourir un didacticiel plus complet.
Remarque : Si vous recherchez de la documentation pour la branche principale (dernière branche de développement) : vous pouvez la trouver sur s.apache.org/airflow-docs.
Pour plus d’informations sur les propositions d’amélioration du flux d’air (AIP), visitez le wiki Airflow.
Documentation pour les projets dépendants tels que les packages de fournisseur, l'image Docker, Helm Chart, vous la trouverez dans l'index de la documentation.
Nous publions Apache Airflow en tant que package apache-airflow dans PyPI. Son installation peut cependant s'avérer parfois délicate car Airflow est à la fois une bibliothèque et une application. Les bibliothèques gardent généralement leurs dépendances ouvertes et les applications les épinglent généralement, mais nous ne devrions faire ni l'un ni l'autre, ni les deux simultanément. Nous avons décidé de garder nos dépendances aussi ouvertes que possible (dans pyproject.toml ) afin que les utilisateurs puissent installer différentes versions de bibliothèques si nécessaire. Cela signifie que pip install apache-airflow ne fonctionnera pas de temps en temps ou produira une installation Airflow inutilisable.
Cependant, pour avoir une installation reproductible, nous conservons un ensemble de fichiers de contraintes « connus pour fonctionner » dans les branches orphelines constraints-main et constraints-2-0 . Nous conservons ces fichiers de contraintes « connus pour fonctionner » séparément par version majeure/mineure de Python. Vous pouvez les utiliser comme fichiers de contraintes lors de l'installation d'Airflow depuis PyPI. Notez que vous devez spécifier la balise/version/branche Airflow correcte et les versions Python dans l'URL.
Remarque : Seule l'installation
pipest actuellement officiellement prise en charge.
Bien qu'il soit possible d'installer Airflow avec des outils comme Poetry ou pip-tools, ils ne partagent pas le même workflow que pip - surtout lorsqu'il s'agit de gestion des contraintes et des exigences. L'installation via Poetry ou pip-tools n'est actuellement pas prise en charge.
Il existe des problèmes connus avec bazel qui peuvent entraîner des dépendances circulaires lors de son utilisation pour installer Airflow. Veuillez passer à pip si vous rencontrez de tels problèmes. La communauté Bazel s'efforce de résoudre le problème dans this PR <https://github.com/bazelbuild/rules_python/pull/1166> _ il se peut donc que des versions plus récentes de bazel le gèrent.
Si vous souhaitez installer Airflow à l'aide de ces outils, vous devez utiliser les fichiers de contraintes et les convertir au format et au flux de travail appropriés requis par votre outil.
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 "Pour plus d’informations sur l’installation des packages de fournisseur, consultez les fournisseurs.
Apache Airflow est un projet Apache Software Foundation (ASF) et nos versions officielles du code source :
Conformément aux règles ASF, les packages sources publiés doivent être suffisants pour qu'un utilisateur puisse créer et tester la version à condition qu'il ait accès à la plate-forme et aux outils appropriés.
Il existe d'autres façons d'installer et d'utiliser Airflow. Ce sont des méthodes « pratiques » - ce ne sont pas des « versions officielles » comme l'indique la ASF Release Policy , mais elles peuvent être utilisées par les utilisateurs qui ne souhaitent pas créer le logiciel eux-mêmes.
Ce sont – dans l’ordre des manières les plus courantes d’installer Airflow :
pip standarddocker , utilisez-les dans Kubernetes, Helm Charts, docker-compose , docker swarm , etc. Vous pouvez en savoir plus sur l'utilisation, la personnalisation et l'extension des images dans les derniers documents et en savoir plus sur les composants internes. dans le document images.Tous ces artefacts ne sont pas des versions officielles, mais ils sont préparés à partir de sources officiellement publiées. Certains de ces artefacts sont des artefacts de « développement » ou de « pré-version », et ils sont clairement marqués comme tels conformément à la politique d'ASF.
DAG : aperçu de tous les DAG de votre environnement.
Grid : représentation en grille d'un DAG qui s'étend dans le temps.
Graphique : Visualisation des dépendances d'un DAG et de leur état actuel pour une exécution spécifique.
Durée de la tâche : Temps total passé sur différentes tâches au fil du temps.
Gantt : Durée et chevauchement d'un DAG.
Code : Moyen rapide d’afficher le code source d’un DAG.
Depuis Airflow 2.0.0, nous prenons en charge une approche SemVer stricte pour tous les packages publiés.
Nous avons convenu de quelques règles spécifiques qui définissent les détails de la gestion des versions des différents packages :
google 4.1.0 et amazon 3.0.3 peuvent volontiers être installés avec Airflow 2.1.2 . S'il existe des limites de dépendances croisées entre les fournisseurs et les packages Airflow, elles sont présentes dans les fournisseurs en tant que limitations install_requires . Nous visons à maintenir la compatibilité ascendante des fournisseurs avec toutes les versions d'Airflow 2 précédemment publiées, mais il y aura parfois des modifications importantes qui pourraient obliger certains, ou tous les fournisseurs, à spécifier la version minimale d'Airflow.Cycle de vie des versions d'Apache Airflow :
| Version | Patch actuel/mineur | État | Première version | Assistance limitée | EOL/Terminé |
|---|---|---|---|---|---|
| 2 | 2.10.3 | Soutenu | 17 décembre 2020 | À déterminer | À déterminer |
| 1.10 | 1.10.15 | EOL | 27 août 2018 | 17 décembre 2020 | 17 juin 2021 |
| 1.9 | 1.9.0 | EOL | 03 janvier 2018 | 27 août 2018 | 27 août 2018 |
| 1.8 | 1.8.2 | EOL | 19 mars 2017 | 03 janvier 2018 | 03 janvier 2018 |
| 1.7 | 1.7.1.2 | EOL | 28 mars 2016 | 19 mars 2017 | 19 mars 2017 |
Les versions à support limité seront prises en charge uniquement avec la sécurité et la correction des bogues critiques. Les versions EOL ne recevront aucun correctif ni support. Nous recommandons toujours à tous les utilisateurs d'exécuter la dernière version mineure disponible, quelle que soit la version majeure utilisée. Nous vous recommandons fortement de passer à la dernière version majeure d'Airflow le plus tôt possible et avant la date EOL.
Depuis Airflow 2.0, nous avons accepté certaines règles que nous suivons pour la prise en charge de Python et Kubernetes. Ils sont basés sur le calendrier de publication officiel de Python et Kubernetes, joliment résumé dans le Guide du développeur Python et la politique de biais de version de Kubernetes.
Nous abandonnons la prise en charge des versions Python et Kubernetes lorsqu'elles atteignent la fin de vie. À l'exception de Kubernetes, une version reste prise en charge par Airflow si deux principaux fournisseurs de cloud la prennent toujours en charge. Nous abandonnons la prise en charge de ces versions EOL dans main juste après la date EOL, et elle est effectivement supprimée lorsque nous publions la première nouvelle MINEURE (ou MAJEURE s'il n'y a pas de nouvelle version MINEURE) d'Airflow. Par exemple, pour Python 3.9, cela signifie que nous abandonnerons le support dans main juste après le 27.06.2023, et que la première version MAJEURE ou MINEURE d'Airflow publiée après ne l'aura pas.
Nous prenons en charge une nouvelle version de Python/Kubernetes dans main après leur sortie officielle, dès que nous les faisons fonctionner dans notre pipeline CI (ce qui pourrait ne pas être immédiat en raison des dépendances qui rattrapent principalement les nouvelles versions de Python), nous publions de nouvelles images /support dans Airflow basé sur la configuration CI fonctionnelle.
Cette politique s'applique au mieux, ce qui signifie qu'il peut y avoir des situations dans lesquelles nous pouvons mettre fin au support plus tôt si les circonstances l'exigent.
La communauté Airflow fournit des images de conteneurs emballées de manière pratique qui sont publiées chaque fois que nous publions une version d'Apache Airflow. Ces images contiennent :
La version de l'image de base du système d'exploitation est la version stable de Debian. Airflow prend en charge l'utilisation de toutes les versions stables actuellement actives - dès que toutes les dépendances d'Airflow prennent en charge la création et que nous avons configuré le pipeline CI pour créer et tester la version du système d'exploitation. Environ 6 mois avant la fin du support régulier d'une version stable précédente du système d'exploitation, Airflow change les images publiées pour utiliser la dernière version prise en charge du système d'exploitation.
Par exemple, le passage de Debian Bullseye à Debian Bookworm a été implémenté avant la version 2.8.0 en octobre 2023 et Debian Bookworm sera la seule option prise en charge à partir d'Airflow 2.10.0.
Les utilisateurs continueront à pouvoir créer leurs images à l'aide des versions stables de Debian jusqu'à la fin du support régulier. La construction et la vérification des images auront lieu dans notre CI, mais aucun test unitaire n'a été exécuté en utilisant cette image dans la branche main .
Airflow a de nombreuses dépendances - directes et transitives, Airflow est également à la fois - une bibliothèque et une application, donc nos politiques en matière de dépendances doivent inclure les deux - la stabilité de l'installation de l'application, mais aussi la possibilité d'installer une version plus récente des dépendances pour les utilisateurs qui développent DAG. Nous avons développé une approche dans laquelle constraints sont utilisées pour garantir que le flux d'air peut être installé de manière reproductible, sans limiter nos utilisateurs à mettre à niveau la plupart des dépendances. En conséquence, nous avons décidé de ne pas limiter la version supérieure des dépendances Airflow par défaut, à moins que nous ayons de bonnes raisons de croire qu'une limite supérieure est nécessaire en raison de l'importance de la dépendance ainsi que du risque que cela implique pour mettre à niveau une dépendance spécifique. Nous avons également limité les dépendances qui, selon nous, posent problème.
Notre mécanisme de contraintes se charge de rechercher et de mettre à niveau automatiquement toutes les dépendances non liées à la limite supérieure (à condition que tous les tests réussissent). Nos main échecs de construction indiqueront s'il existe des versions de dépendances qui interrompent nos tests - indiquant que nous devrions soit les lier au niveau supérieur, soit que nous devrions corriger notre code/tests pour tenir compte des modifications en amont de ces dépendances.
Chaque fois que nous plaçons une telle dépendance, nous devons toujours expliquer pourquoi nous le faisons - c'est-à-dire que nous devons avoir une bonne raison pour laquelle la dépendance est supérieure. Et nous devrions également mentionner quelle est la condition pour supprimer la liaison.
Ces dépendances sont conservées dans pyproject.toml .
Il y a peu de dépendances que nous avons jugées suffisamment importantes pour les limiter par défaut, car elles sont connues pour suivre un schéma de gestion de versions prévisible, et nous savons que les nouvelles versions de celles-ci sont très susceptibles d'apporter des modifications importantes. Nous nous engageons à examiner régulièrement et à tenter de mettre à niveau vers les versions les plus récentes des dépendances au fur et à mesure de leur publication, mais il s'agit d'un processus manuel.
Les dépendances importantes sont :
SQLAlchemy : limite supérieure à une version MINEURE spécifique (SQLAlchemy est connu pour supprimer les dépréciations et introduire des modifications avec rupture, en particulier que la prise en charge de différentes bases de données varie et change à différentes vitesses)Alembic : il est important de gérer nos migrations de manière prévisible et performante. Il est développé en collaboration avec SQLAlchemy. Notre expérience avec Alambic est qu'il est très stable en version MINEUREFlask : Nous utilisons Flask comme épine dorsale de notre interface utilisateur et de notre API Web. Nous savons que les versions majeures de Flask sont très susceptibles d'introduire des modifications importantes dans celles-ci, il est donc logique de les limiter à la version MAJEURE.werkzeug : la bibliothèque est connue pour causer des problèmes dans les nouvelles versions. Il est étroitement couplé aux bibliothèques Flask, et nous devrions les mettre à jour ensemblecelery : Le céleri est un composant crucial d'Airflow car il est utilisé pour CeleryExecutor (et similaire). Le céleri suit SemVer, nous devrions donc le limiter à la prochaine version MAJEURE. De plus, lorsque nous augmentons la version supérieure de la bibliothèque, nous devons nous assurer que la version minimale d'Airflow de Celery Provider est mise à jour.kubernetes : Kubernetes est un composant crucial d'Airflow car il est utilisé pour KubernetesExecutor (et similaire). La bibliothèque Kubernetes Python suit SemVer, nous devrions donc la limiter à la prochaine version MAJEURE. De plus, lorsque nous augmentons la version supérieure de la bibliothèque, nous devons nous assurer que la version minimale d'Airflow du fournisseur Kubernetes est mise à jour.La partie principale d'Airflow est l'Airflow Core, mais la puissance d'Airflow vient également d'un certain nombre de fournisseurs qui étendent les fonctionnalités de base et sont publiés séparément, même si nous les gardons (pour l'instant) dans le même monorepo pour plus de commodité. Vous pouvez en savoir plus sur les fournisseurs dans la documentation des fournisseurs. Nous avons également mis en œuvre un ensemble de politiques pour maintenir et libérer les fournisseurs gérés par la communauté, ainsi que l'approche entre les fournisseurs communautaires et les fournisseurs tiers dans le document des fournisseurs.
Ces extras et dépendances providers sont conservés dans provider.yaml de chaque fournisseur.
Par défaut, nous ne devons pas limiter les dépendances des fournisseurs, mais le responsable de chaque fournisseur peut décider d'ajouter des limites supplémentaires (et de les justifier par un commentaire).
Vous voulez aider à créer Apache Airflow ? Consultez notre guide des contributeurs pour un aperçu complet de la manière de contribuer, y compris les instructions de configuration, les normes de codage et les directives sur les demandes d'extraction.
Si vous avez hâte de contribuer et souhaitez commencer dès que possible, consultez le guide de démarrage rapide ici !
Les images Docker officielles (conteneur) pour Apache Airflow sont décrites dans images.
+1s des membres du PMC et des committers sont considérés comme un vote contraignant. Nous connaissons environ 500 organisations qui utilisent Apache Airflow (mais il y en a probablement beaucoup plus) dans la nature.
Si vous utilisez Airflow, n'hésitez pas à créer un PR pour ajouter votre organisation à la liste.
Airflow est le travail de la communauté, mais les principaux committers/mainteneurs sont responsables de l'examen et de la fusion des PR ainsi que d'orienter les conversations autour des demandes de nouvelles fonctionnalités. Si vous souhaitez devenir responsable, veuillez consulter les exigences du committer Apache Airflow.
Souvent, vous verrez un problème attribué à une étape spécifique avec la version Airflow, ou un PR qui est fusionné avec la branche principale et vous pourriez vous demander dans quelle version le ou les PR fusionnés seront publiés ou dans quelle version les problèmes résolus seront. dans. La réponse à cette question est comme d'habitude - cela dépend de divers scénarios. La réponse est différente pour les PR et les problèmes.
Pour ajouter un peu de contexte, nous suivons le schéma de versioning Semver tel que décrit dans Processus de publication d'Airflow. Plus de détails sont expliqués en détail dans ce README sous le chapitre sur la gestion des versions sémantiques, mais en bref, nous avons des versions MAJOR.MINOR.PATCH d'Airflow.
MAJOR est incrémentée en cas de modifications avec ruptureMINOR est incrémentée lorsque de nouvelles fonctionnalités sont ajoutéesPATCH est incrémentée lorsqu'il n'y a que des corrections de bugs et des modifications de la documentation uniquement Généralement, nous publions des versions MINOR d'Airflow à partir d'une branche qui porte le nom de la version MINEURE. Par exemple, les versions 2.7.* sont publiées à partir de la branche v2-7-stable , 2.8.* sont publiées à partir de la branche v2-8-stable , etc.
La plupart du temps dans notre cycle de publication, lorsque la branche de la prochaine branche MINOR n'est pas encore créée, tous les PR fusionnés avec main (à moins qu'ils ne soient annulés) trouveront leur chemin vers la prochaine version MINOR . Par exemple, si la dernière version est 2.7.3 et que la branche v2-8-stable n'est pas encore créée, la prochaine version MINOR est 2.8.0 et tous les PR fusionnés avec la branche principale seront publiés dans 2.8.0 . Cependant, certains PR (corrections de bogues et modifications de la documentation uniquement) une fois fusionnés, peuvent être sélectionnés dans la branche MINOR actuelle et publiés dans la prochaine version PATCHLEVEL . Par exemple, si 2.8.1 est déjà publiée et que nous travaillons sur 2.9.0dev , alors marquer un PR avec le jalon 2.8.2 signifie qu'il sera sélectionné dans la branche v2-8-test et publié dans 2.8.2rc1 , et finalement en 2.8.2 .
Lorsque nous préparons la prochaine version MINOR , nous coupons les nouvelles branches v2-*-test et v2-*-stable et préparons les versions alpha et beta pour la prochaine version MINOR , les PR fusionnés avec main seront toujours publiés dans la prochaine version MINOR . jusqu'à ce que la version rc soit coupée. Cela se produit parce que les branches v2-*-test et v2-*-stable sont rebasées sur main lors de la préparation des prochaines versions beta et rc . Par exemple, lorsque nous supprimons la version 2.10.0beta1 , tout ce qui a été fusionné avec main avant la sortie de 2.10.0rc1 trouvera son chemin vers 2.10.0rc1.
Ensuite, une fois que nous avons préparé le premier candidat RC pour la version MINOR, nous arrêtons de déplacer les branches v2-*-test et v2-*-stable et les PR fusionnés avec main seront publiés dans la prochaine version MINOR . Cependant, certains PR (corrections de bugs et modifications de la documentation uniquement) une fois fusionnés, peuvent être sélectionnés dans la branche MINOR actuelle et publiés dans la prochaine version PATCHLEVEL - par exemple lorsque la dernière version publiée de la branche v2-10-stable est 2.10.0rc1 , certains des PR de main peuvent être marqués comme jalon 2.10.0 par les committers, le gestionnaire de versions essaiera de les sélectionner dans la branche de publication. En cas de succès, ils seront publiés en 2.10.0rc2 puis en 2.10.0 . Cela s'applique également aux versions ultérieures PATCHLEVEL . Lorsque, par exemple, 2.10.1 est déjà publiée, marquer un PR avec le jalon 2.10.2 signifiera qu'il sera sélectionné dans la branche v2-10-stable et publié dans 2.10.2rc1 et éventuellement dans 2.10.2 .
La décision finale concernant la sélection est prise par le responsable de la version.
Marquer les problèmes avec un jalon est un peu différent. Les responsables ne marquent généralement pas les problèmes avec un jalon, normalement ils ne sont marqués que dans les PR. Si le PR lié au problème (et « le résoudre ») est fusionné et publié dans une version spécifique en suivant le processus décrit ci-dessus, le problème sera automatiquement fermé, aucun jalon ne sera défini pour le problème, vous devez vérifier le PR qui résolu le problème pour voir dans quelle version il a été publié.
Cependant, les responsables marquent parfois les problèmes avec une étape spécifique, ce qui signifie que le problème est important pour devenir un candidat à examiner lors de la préparation de la version. Puisqu'il s'agit d'un projet Open Source, dans lequel pratiquement tous les contributeurs donnent de leur temps, il n'y a aucune garantie qu'un problème spécifique sera résolu dans une version spécifique. Nous ne souhaitons pas conserver la version car certains problèmes ne sont pas résolus. Dans ce cas, le gestionnaire de versions réaffectera ces problèmes non résolus à l'étape suivante au cas où ils ne seraient pas résolus à temps pour la version actuelle. Par conséquent, le jalon pour le problème est plus une intention de l'examiner qu'une promesse qu'il sera corrigé dans la version.
Plus de contexte et de FAQ sur la version au niveau du correctif peuvent être trouvés dans le document Ce qui entre dans la prochaine version dans le dossier dev du référentiel.
Oui! Assurez-vous de respecter les politiques de marque Apache Foundation et le Brandbook Apache Airflow. Les logos les plus récents se trouvent dans ce référentiel et sur le site Web d'Apache Software Foundation.
L'infrastructure CI pour Apache Airflow a été sponsorisée par :
