NOTE: The transition from 1.8.0 (or before) to 1.8.1 (or after) requires uninstalling Apache Airflow before installing the new version. The package name was changed from airflow
to apache-airflow
as of version 1.8.1.
Apache Airflow (or simply Airflow) is a platform to programmatically author, schedule, and monitor workflows.
When workflows are defined as code, they become more maintainable, versionable, testable, and collaborative.
Use Airflow to author workflows as directed acyclic graphs (DAGs) of tasks. The Airflow scheduler executes your tasks on an array of workers while following the specified dependencies. Rich command line utilities make performing complex surgeries on DAGs a snap. The rich user interface makes it easy to visualize pipelines running in production, monitor progress, and troubleshoot issues when needed.
Table of contents
Apache Airflow is tested with:
Please visit the Airflow Platform documentation (latest stable release) for help with installing Airflow, getting a quick start, or a more complete tutorial.
Documentation of GitHub master (latest development branch): ReadTheDocs Documentation
For further information, please visit the Airflow Wiki.
Official container (Docker) images for Apache Airflow are described in IMAGES.rst.
Airflow is published as apache-airflow
package in PyPI. Installing it however might be sometimes tricky because Airflow is a bit of both a library and application. Libraries usually keep their dependencies open and applications usually pin them, but we should do neither and both at the same time. We decided to keep our dependencies as open as possible (in setup.py
) so users can install different versions of libraries if needed. This means that from time to time plain pip install apache-airflow
will not work or will produce unusable Airflow installation.
In order to have repeatable installation, however, introduced in Airflow 1.10.10 and updated in Airflow 1.10.12 we also keep a set of “known-to-be-working” constraint files in the orphan constraints-master
and constraints-1-10
branches. We keep those “known-to-be-working” constraints files separately per major/minor python version. You can use them as constraint files when installing Airflow from PyPI. Note that you have to specify correct Airflow tag/version/branch and python versions in the URL.
pip install apache-airflow==1.10.12 \ --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-1.10.12/constraints-3.7.txt"
pip install apache-airflow[postgres,gcp]==1.10.11 \ --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-1.10.12/constraints-3.7.txt"
In order to use Airflow in Docker Compose or Kubernetes, you might need to use or build production images of Apache Airflow. The community provides two types of support for the production images:
We provide pre-build relesed version of production image in PyPI build from released sources of Apache Airflow - shortly after release. Those images are available in the DockerHub. You can pull those images via docker pull apache/airflow:<VERSION>-pythonX.Y
- version is the version number (for example 1.10.11). Additionally docker pull apache/airflow
will pull latest stable version of the image with default python version (currently 3.6)
In master
branch of Airflow and in v1-10-stable
branch we provide Dockerfiles and accompanying files that allow to build your own customized version of the Airflow Production image. The instructions on how to build your own image with additional dependencies (if needed) are provided in the IMAGES.rst if you want to build it using docker build
command or in BREEZE.rst to use Breeze tool which easier interface, auto-complete, and accompanying screencast video. Note, that while it is possible to use master branch to build images for released Airflow versions, it might at times get broken so you should rather rely on building your own images from the v1-10-stable branch.
Airflow is not a data streaming solution. Tasks do not move data from one to the other (though tasks can exchange metadata!). Airflow is not in the Spark Streaming or Storm space, it is more comparable to Oozie or Azkaban.
Workflows are expected to be mostly static or slowly changing. You can think of the structure of the tasks in your workflow as slightly more dynamic than a database structure would be. Airflow workflows are expected to look similar from a run to the next, this allows for clarity around unit of work and continuity.
DAGs: Overview of all DAGs in your environment.
Tree View: Tree representation of a DAG that spans across time.
Graph View: Visualization of a DAG's dependencies and their current status for a specific run.
Task Duration: Total time spent on different tasks over time.
Gantt View: Duration and overlap of a DAG.
Code View: Quick way to view source code of a DAG.
Currently stable versions of Apache Airflow are released in 1.10.* series. We are working on the future, major version of Airflow from the 2.0.* series. It is going to be released in in 2020. However the exact time of release depends on many factors and is yet unknown. We have already a lot of changes in the hooks/operators/sensors for many external systems and they are not used because they are part of the master/2.0 release.
In the Airflow 2.0 - following AIP-21 “change in import paths” all the non-core operators/hooks/sensors of Apache Airflow have been moved to the “airflow.providers” package. This opened a possibility to use the operators from Airflow 2.0 in Airflow 1.10 - with the constraint that those packages can only be used in python3.6+ environment.
Therefore we decided to prepare and release backport packages that can be installed for older Airflow versions. Those backport packages are released more frequently. Users do not have to upgrade their Airflow version to use those packages. There are a number of changes between Airflow 2.0 and 1.10.* - documented in UPDATING.md. With backported providers package users can migrate their DAGs to the new providers package incrementally and once they convert to the new operators/sensors/hooks they can seamlessly migrate their environments to Airflow 2.0.
More information about the status and releases of the back-ported packages are available at Backported providers package page
Dependencies between packages are stored in airflow/providers/dependencies.json
. See CONTRIBUTING.rst
Want to help build Apache Airflow? Check out our contributing documentation.
As the Apache Airflow community grows, we'd like to keep track of who is using the platform. Please send a PR with your company name and @githubhandle if you may.
Committers:
Currently officially using Airflow:
Airflow is the work of the community, but the core committers/maintainers are responsible for reviewing and merging PRs as well as steering conversation around new feature requests. If you would like to become a maintainer, please review the Apache Airflow committer requirements.
Yes! Be sure to abide by the Apache Foundation trademark policies and the Apache Airflow Brandbook. The most up to date logos are found in this repo and on the Apache Software Foundation website.