Introduction to Apache Airflow® DAGs

In Apache Airflow®, a DAG is a data pipeline or workflow. DAGs are the main organizational unit in Airflow; they contain a collection of tasks and dependencies that you want to execute on a schedule.

A DAG is defined in Python code and visualized in the Airflow UI. DAGs can be as simple as a single task or as complex as hundreds or thousands of tasks with complicated dependencies.

The following screenshot shows a complex DAG graph in the Airflow UI. After reading this guide, you’ll be able to understand the elements in this graph, as well as know how to define DAGs and use DAG parameters.

Assumed knowledge

To get the most out of this guide, you should have an understanding of:

• What Airflow is. See Introduction to Apache Airflow.

What is a DAG?

A DAG (directed acyclic graph) is a mathematical structure consisting of nodes and edges. In Airflow, a DAG represents a data pipeline or workflow with a start and an end.

The mathematical properties of DAGs make them useful for building data pipelines:

• Directed: There is a clear direction of flow between tasks. A task can be either upstream, downstream, or parallel to another task.

  

• Acyclic: There are no circular dependencies in a DAG. This means that a task cannot depend on itself, nor can it depend on a task that ultimately depends on it.

  

• Graph: A DAG is a graph, which is a structure consisting of nodes and edges. In Airflow, nodes are tasks and edges are dependencies between tasks. Defining workflows as graphs helps you visualize the entire workflow in a way that’s easy to navigate and conceptualize.

Beyond these requirements, a DAG can be as simple or as complicated as you need! You can define tasks that run in parallel or sequentially, implement conditional branches, and visually group tasks together in task groups.

Each task in a DAG performs one unit of work. Tasks can be anything from a simple Python function to a complex data transformation or a call to an external service. They are defined using Airflow operators or Airflow decorators. The dependencies between tasks can be set in different ways (see Managing Dependencies).

The following screenshot shows a simple DAG graph with 3 sequential tasks.

1
"""
2
## Astronaut ETL example DAG
3
4
This DAG queries the list of astronauts currently in space from the
5
Open Notify API and prints each astronaut's name and flying craft.
6
7
There are three tasks, one to get the data from the API and save the results,
8
one to print the results and a final task to react. The first two tasks are
9
written in Python using Airflow's TaskFlow API, which allows you to easily turn
10
Python functions into Airflow tasks, and automatically infer dependencies and pass data.
11
12
The second task uses dynamic task mapping to create a copy of the task for
13
each Astronaut in the list retrieved from the API. This list will change
14
depending on how many Astronauts are in space, and the DAG will adjust
15
accordingly each time it runs.
16
17
The third task is defined using the BashOperator, which is a traditional
18
operator, allowing you to run a bash command.
19
"""
20
21
from airflow.decorators import dag, task
22
from airflow.operators.bash import BashOperator
23
from airflow.models.baseoperator import chain
24
from pendulum import datetime
25
import requests
26
27
28
# Define the basic parameters of the DAG, like schedule and start_date
29
@dag(
30
    start_date=datetime(2024, 1, 1),
31
    schedule="@daily",
32
    catchup=False,
33
    doc_md=__doc__,
34
    default_args={"owner": "Astro", "retries": 3},
35
    tags=["example"],
36
)
37
def example_astronauts_three_tasks():
38
    # Define tasks
39
    @task
40
    def get_astronauts(**context) -> list[dict]:
41
        """
42
        This task uses the requests library to retrieve a list of Astronauts
43
        currently in space. The results are pushed to XCom with a specific key
44
        so they can be used in a downstream pipeline. The task returns a list
45
        of Astronauts to be used in the next task.
46
        """
47
        r = requests.get("http://api.open-notify.org/astros.json")
48
        number_of_people_in_space = r.json()["number"]
49
        list_of_people_in_space = r.json()["people"]
50
51
        context["ti"].xcom_push(
52
            key="number_of_people_in_space", value=number_of_people_in_space
53
        )
54
        return list_of_people_in_space
55
56
    @task
57
    def print_astronaut_craft(greeting: str, person_in_space: dict) -> None:
58
        """
59
        This task creates a print statement with the name of an
60
        Astronaut in space and the craft they are flying on from
61
        the API request results of the previous task, along with a
62
        greeting which is hard-coded in this example.
63
        """
64
        craft = person_in_space["craft"]
65
        name = person_in_space["name"]
66
67
        print(f"{name} is currently in space flying on the {craft}! {greeting}")
68
69
    # define a task using a traditional operator
70
    # this task will run a bash command
71
    print_reaction = BashOperator(
72
        task_id="print_reaction",
73
        bash_command="echo This is awesome!",
74
    )
75
76
    # Use dynamic task mapping to run the print_astronaut_craft task for each
77
    # Astronaut in space
78
    print_astronaut_craft_obj = print_astronaut_craft.partial(
79
        greeting="Hello! :)"
80
    ).expand(
81
        person_in_space=get_astronauts()  # Define dependencies using TaskFlow API syntax
82
    )
83
84
    # set the dependency between the second and third task explicitly
85
    chain(print_astronaut_craft_obj, print_reaction)
86
87
88
# Instantiate the DAG
89
example_astronauts_three_tasks()

What is a DAG run?

A DAG run is an instance of a DAG running at a specific point in time. A task instance is an instance of a task running at a specific point in time. Each DAG run has a unique dag_run_id and contains one or more task instances. The history of previous DAG runs is stored in the Airflow metadata database.

In the Airflow UI, you can view previous runs of a DAG in the Grid view and select individual DAG runs by clicking on their respective duration bar. A DAG run graph looks similar to the DAG graph, but includes additional information about the status of each task instance in the DAG run.

DAG run properties

A DAG run graph in the Airflow UI contains information about the DAG run, as well as the status of each task instance in the DAG run. The following screenshot shows the same DAG as in the previous section, but with annotations explaining the different elements of the graph.

• dag_id: The unique identifier of the DAG.
• logical date: The point in time for which the DAG run is scheduled. This date and time is not necessarily the same as the actual moment the DAG run is executed. See Scheduling for more information.
• task_id: The unique identifier of the task.
• task state: The status of the task instance in the DAG run. Possible states are running, success, failed, skipped, restarting, up_for_retry, upstream_failed, queued, scheduled, none, removed, deferred, and up_for_reschedule, they each cause the border of the node to be colored differently. See the OSS documentation on task instances for an explanation of each state.

The previous screenshot also shows the four common ways you can trigger a DAG run:

• Backfill: The first DAG run was created using a backfill. Backfilled DAG runs include a curved arrow on their DAG run duration bar.
• Scheduled: The second DAG run, which is currently selected in the screenshot, was created by the Airflow scheduler based on the DAG’s defined schedule. This is the default method for running DAGs.
• Manual: The third DAG run was triggered manually by a user using the Airflow UI or the Airflow CLI. Manually triggered DAG runs include a play icon on the DAG run duration bar.
• Dataset triggered: The fourth DAG run was started by a dataset. DAG runs triggered by a dataset include a dataset icon on their DAG run duration bar.

A DAG run can have the following statuses:

• Queued: The time after which the DAG run can be created has passed but the scheduler has not created task instances for it yet.
• Running: The DAG run is eligible to have task instances scheduled.
• Success: All task instances are in a terminal state (success, skipped, failed or upstream_failed) and all leaf tasks (tasks with no downstream tasks) are either in the state success or skipped. In the previous screenshot, all four DAG runs were successful.
• Failed: All task instances are in a terminal state and at least one leaf task is in the state failed or upstream_failed.

Complex DAG runs

When you start writing more complex DAGs, you will see additional Airflow features that are visualized in the DAG run graph. The following screenshot shows the same complex DAG as in the overview but with annotations explaining the different elements of the graph. Don’t worry if you don’t know about all these features yet - you will learn about them as you become more familiar with Airflow.

1
"""
2
## Example of a complex DAG structure
3
4
This DAG demonstrates how to set up a complex structures including:
5
- Branches with Labels
6
- Task Groups
7
- Dynamically mapped tasks
8
- Dynamically mapped task groups
9
10
The tasks themselves are empty or simple bash statements.
11
"""
12
13
from airflow.decorators import dag, task_group, task
14
from airflow.operators.empty import EmptyOperator
15
from airflow.operators.bash import BashOperator
16
from airflow.models.baseoperator import chain, chain_linear
17
from airflow.utils.edgemodifier import Label
18
from airflow.datasets import Dataset
19
from pendulum import datetime
20
21
22
# Define the DAG
23
@dag(
24
    start_date=datetime(2024, 1, 1),
25
    schedule=None,
26
    catchup=False,
27
)
28
def complex_dag_structure():
29
30
    start = EmptyOperator(task_id="start")
31
32
    # Dynamically mapped tasks: .partial() contains all parameters that stay the same
33
    # between mapped task instances. .expand() contains the parameters that change
34
    # one mapped task instance will be created for each value in the list provided to `bash_command`
35
    sales_data_extract = BashOperator.partial(task_id="sales_data_extract").expand(
36
        bash_command=["echo 1", "echo 2", "echo 3", "echo 4"]
37
    )
38
    internal_api_extract = BashOperator.partial(task_id="internal_api_extract").expand(
39
        bash_command=["echo 1", "echo 2", "echo 3", "echo 4"]
40
    )
41
42
    # Branch task that picks which branch to follow
43
    @task.branch
44
    def determine_load_type() -> str:
45
        """Randomly choose a branch. The return value is the task_id of the branch to follow."""
46
        import random
47
48
        if random.choice([True, False]):
49
            return "internal_api_load_full"
50
        return "internal_api_load_incremental"
51
52
    sales_data_transform = EmptyOperator(task_id="sales_data_transform")
53
54
    # When using the TaskFlow API it is common to assign the called task to an object
55
    # to use in several dependency definitions without creating several instances of the same task
56
    determine_load_type_obj = determine_load_type()
57
58
    sales_data_load = EmptyOperator(task_id="sales_data_load")
59
    internal_api_load_full = EmptyOperator(task_id="internal_api_load_full")
60
    internal_api_load_incremental = EmptyOperator(
61
        task_id="internal_api_load_incremental"
62
    )
63
64
    # defining a task group that task a parameter (a) to allow for dynamic task group mapping
65
    @task_group
66
    def sales_data_reporting(a):
67
        # the trigger_rule of the first task in the task group can be set to "all_done"
68
        # to ensure that it runs even if one of the upstream tasks (`internal_api_load_full`)
69
        # is skipped due to the branch task
70
        prepare_report = EmptyOperator(
71
            task_id="prepare_report", trigger_rule="all_done"
72
        )
73
        publish_report = EmptyOperator(task_id="publish_report")
74
75
        # setting dependencies within the task group
76
        chain(prepare_report, publish_report)
77
78
    # dynamically mapping the task group with `a` being the mapped parameter
79
    # one task group instance will be created for each value in the list provided to `a`
80
    sales_data_reporting_obj = sales_data_reporting.expand(a=[1, 2, 3, 4, 5, 6])
81
82
    # defining a task group that does not use any additional parameters
83
    @task_group
84
    def cre_integration():
85
        # the trigger_rule of the first task in the task group can be set to "all_done"
86
        # to ensure that it runs even if one of the upstream tasks (`internal_api_load_full`)
87
        # is skipped due to the branch task
88
        cre_extract = EmptyOperator(task_id="cre_extract", trigger_rule="all_done")
89
        cre_transform = EmptyOperator(task_id="cre_transform")
90
        cre_load = EmptyOperator(task_id="cre_load")
91
92
        # setting dependencies within the task group
93
        chain(cre_extract, cre_transform, cre_load)
94
95
    # calling the task group to instantiate it and assigning it to an object
96
    # to use in dependency definitions
97
    cre_integration_obj = cre_integration()
98
99
    @task_group
100
    def mlops():
101
        # the trigger_rule of the first task in the task group can be set to "all_done"
102
        # to ensure that it runs even if one of the upstream tasks (`internal_api_load_incremental`)
103
        # is skipped due to the branch task
104
        set_up_cluster = EmptyOperator(
105
            task_id="set_up_cluster", trigger_rule="all_done"
106
        )
107
        # the outlets parameter is used to define which datasets are updated by this task
108
        train_model = EmptyOperator(
109
            task_id="train_model", outlets=[Dataset("model_trained")]
110
        )
111
        tear_down_cluster = EmptyOperator(task_id="tear_down_cluster")
112
113
        # setting dependencies within the task group
114
        chain(set_up_cluster, train_model, tear_down_cluster)
115
116
        # turning the `tear_down_cluster`` task into a teardown task and set
117
        # the `set_up_cluster` task as the associated setup task
118
        tear_down_cluster.as_teardown(setups=set_up_cluster)
119
120
    mlops_obj = mlops()
121
122
    end = EmptyOperator(task_id="end")
123
124
    # --------------------- #
125
    # Defining dependencies #
126
    # --------------------- #
127
128
    chain(
129
        start,
130
        sales_data_extract,
131
        sales_data_transform,
132
        sales_data_load,
133
        [sales_data_reporting_obj, cre_integration_obj],
134
        end,
135
    )
136
    chain(
137
        start,
138
        internal_api_extract,
139
        determine_load_type_obj,
140
        [internal_api_load_full, internal_api_load_incremental],
141
        mlops_obj,
142
        end,
143
    )
144
145
    chain_linear(
146
        [sales_data_load, internal_api_load_full],
147
        [sales_data_reporting_obj, cre_integration_obj],
148
    )
149
150
    # Adding labels to two edges
151
    chain(
152
        determine_load_type_obj, Label("additional data"), internal_api_load_incremental
153
    )
154
    chain(
155
        determine_load_type_obj, Label("changed existing data"), internal_api_load_full
156
    )
157
158
159
# Calling the DAG function will instantiate the DAG
160
complex_dag_structure()

Some more complex features visible in this DAG graph are:

• Dynamically mapped tasks: A dynamically mapped task is created dynamically at runtime based on user-defined input. The number of dynamically mapped task instances is shown in brackets ([]) behind the task ID.
• Branching tasks: A branching task creates a conditional branch in the DAG. See Branching in Airflow for more information.
• Edge labels: Edge labels appear on the edge between two tasks. These labels are often helpful to annotate branch decisions in a DAG graph.
• Task groups: A task group is a tool to logically and visually group tasks in an Airflow DAG. See Airflow task groups for more information.
• Setup/teardown tasks: When using Airflow to manage infrastructure, it can be helpful to define tasks as setup and teardown tasks to take advantage of additional intelligent dependency behavior. Setup and teardown tasks appear with diagonal arrows next to their task IDs and are connected with a dotted line. See Use setup and teardown tasks in Airflow for more information.
• Datasets: Datasets are shown in the DAG graph. If a DAG is scheduled on a dataset, it is shown upstream of the first task of the DAG. If a task in the DAG updates a dataset, it is shown after the respective task as in the previous screenshot. See Airflow datasets for more information.

You can learn more about how to set complex dependencies between tasks and task groups in the Managing Dependencies guide.

Write a DAG

A DAG can be defined with a Python file placed in an Airflow project’s DAG_FOLDER, which is dags when using the Astro CLI. Airflow automatically parses all files in this folder every 5 minutes to check for new DAGs, and it parses existing DAGs for code changes every 30 seconds. You can force a new DAG parse using airflow dags reserialize, or astro dev run dags reserialize using the Astro CLI.

There are two types of syntax you can use to structure your DAG:

• TaskFlow API: The TaskFlow API contains the @dag decorator. A function decorated with @dag defines a DAG. Note that you need to call the function at the end of the script for Airflow to register the DAG. All tasks are defined within the context of the DAG function.
• Traditional syntax: You can create a DAG by instantiating a DAG context using the DAG class and defining tasks within that context.

TaskFlow API and traditional syntax can be freely mixed. See Mixing TaskFlow decorators with traditional operators for more information.

The following is an example of the same DAG written using each type of syntax.

1
# Import all packages needed at the top level of the DAG
2
from airflow.decorators import dag, task
3
from airflow.models.baseoperator import chain
4
from pendulum import datetime
5
6
# Define the DAG function a set of parameters
7
@dag(
8
    start_date=datetime(2024, 1, 1),
9
    schedule="@daily",
10
    catchup=False,
11
)
12
def taskflow_dag():
13
    # Define tasks within the DAG context
14
    @task
15
    def my_task_1():
16
        time.sleep(5)
17
        print(1)
18
19
    @task
20
    def my_task_2():
21
        print(2)
22
23
    # Define dependencies and call task functions
24
    chain(my_task_1(), my_task_2())
25
26
# Call the DAG function
27
taskflow_dag()

1
# Import all packages needed at the top level of the DAG
2
from airflow import DAG
3
from airflow.operators.python import PythonOperator
4
from pendulum import datetime
5
6
def my_task_1_func():
7
    time.sleep(5)
8
    print(1)
9
10
# Instantiate the DAG
11
with DAG(
12
    dag_id="traditional_syntax_dag",
13
    start_date=datetime(2024, 1, 1),
14
    schedule="@daily",
15
    catchup=False,
16
):
17
    # Instantiate tasks within the DAG context
18
    my_task_1 = PythonOperator(
19
        task_id="my_task_1",
20
        python_callable=my_task_1_func,
21
    )
22
23
    my_task_2 = PythonOperator(
24
        task_id="my_task_2",
25
        python_callable=lambda: print(2),
26
    )
27
28
    # Define dependencies
29
    my_task_1 >> my_task_2

DAG-level parameters

In Airflow, you can configure when and how your DAG runs by setting parameters in the DAG object. DAG-level parameters affect how the entire DAG behaves, as opposed to task-level parameters which only affect a single task.

The DAGs in the previous section have the following basic parameters defined. It’s best practice to always define these parameters for any DAGs you create:

• dag_id: The name of the DAG. This must be unique for each DAG in the Airflow environment. When using the @dag decorator and not providing the dag_id parameter name, the function name is used as the dag_id.
• start_date: The date and time after which the DAG starts being scheduled.
• schedule: The schedule for the DAG. There are many different ways to define a schedule, see Scheduling in Airflow for more information.
• catchup: Whether the scheduler should backfill all missed DAG runs between the current date and the start date when the DAG is unpaused. It is a best practice to always set it to False unless you specifically want to backfill missed DAG runs. By default catchup is set to True.

There are many more DAG-level parameters that let you configure anything from resource usage to the DAG’s appearance in the Airflow UI. See DAG-level parameters for a complete list.

See also

• Get started with Apache Airflow tutorial for a hands-on introduction to writing your first simple DAG.
• Airflow operators and Introduction to the TaskFlow API and Airflow decorators for more information on how to define tasks in a DAG.
• Intro to Airflow: Get Started Writing Pipelines for Any Use Case webinar for a one-hour webinar introducing Airflow and how to write DAGs.