Sharing data between tasks effectively in Apache Airflow - Step-by-Step Execution

Process Flow - Sharing data between tasks effectively

Task 1 runs

↓

Push data to XCom

↓

Task 2 waits

↓

Task 2 pulls data from XCom

↓

Task 2 uses data

↓

Workflow continues

Task 1 produces data and pushes it to XCom. Task 2 waits, then pulls that data from XCom to use it.

Execution Sample

Apache Airflow

from airflow import DAG
from airflow.operators.python import PythonOperator

def push_data(ti):
    ti.xcom_push(key='my_key', value='hello')

def pull_data(ti):
    data = ti.xcom_pull(key='my_key', task_ids='push_data')
    print(f"Pulled data: {data}")

Task push_data sends 'hello' to XCom; pull_data retrieves and prints it.

Process Table

Step	Task	Action	XCom State	Output
1	push_data	Runs and pushes 'hello' with key 'my_key'	{'push_data': {'my_key': 'hello'}}	No output
2	pull_data	Pulls 'hello' from XCom using key 'my_key'	{'push_data': {'my_key': 'hello'}}	Pulled data: hello
3	Workflow	Continues to next tasks	{'push_data': {'my_key': 'hello'}}	No output

💡 All tasks completed; data shared successfully via XCom.

Status Tracker

Variable	Start	After push_data	After pull_data	Final
XCom	{}	{'push_data': {'my_key': 'hello'}}	{'push_data': {'my_key': 'hello'}}	{'push_data': {'my_key': 'hello'}}
data in pull_data	None	None	'hello'	'hello'

Key Moments - 2 Insights

Why does pull_data need to specify task_ids='push_task' when pulling data?

Because XCom stores data per task, pull_data must specify which task's data to retrieve, as shown in execution_table step 2.

Can tasks share data without using XCom?

Not effectively within Airflow's task context; XCom is the built-in way to share small data between tasks, as demonstrated in the flow.

Visual Quiz - 3 Questions

Look at the execution table step 1, what key-value pair is pushed to XCom?

A 'my_key': 'world'

B 'data': 'hello'

C 'my_key': 'hello'

D 'key': 'hello'

💡 Hint

Check the 'XCom State' column in step 1 of the execution_table.

At which step does pull_data retrieve the data from XCom?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Action' column describing pull_data's behavior.

If push_data pushed a different key, what must pull_data change to get the data?

A Change the key parameter in xcom_pull

B Change the task_id parameter

C Change the DAG id

D No change needed

💡 Hint

Refer to the 'key' argument in the xcom_pull call in the execution_sample code.

Concept Snapshot

Airflow tasks share data using XCom.
Task 1 pushes data with ti.xcom_push(key, value).
Task 2 pulls data with ti.xcom_pull(key, task_ids).
XCom stores data per task instance.
Use keys to identify data.
This enables effective data sharing between tasks.

Full Transcript

In Airflow, tasks share data using a feature called XCom. First, one task runs and pushes data to XCom with a key. Then, another task waits and pulls that data from XCom using the same key and the task id of the pushing task. This way, tasks can pass small pieces of data between each other safely and clearly. The execution table shows step-by-step how push_data stores 'hello' in XCom and pull_data retrieves it. Variables like XCom and data in pull_data change accordingly. Remember, when pulling data, you must specify the task id that pushed it and the key used. This method is the standard way to share data effectively between Airflow tasks.

Practice

1. What is the primary purpose of using Airflow Variables when sharing data between tasks?

easy

A. To execute tasks in parallel

B. To monitor task execution logs

C. To schedule DAG runs automatically

D. To store small pieces of data accessible across different tasks

Solution

1. Step 1: Understand Airflow Variables role

   Airflow Variables are designed to hold small data values that can be shared between tasks.

2. Step 2: Identify the correct use case

   Sharing data between tasks requires a storage mechanism accessible by all tasks, which Airflow Variables provide.

3. Final Answer:

   To store small pieces of data accessible across different tasks -> Option D

4. Quick Check:

   Airflow Variables = data sharing [OK]

Hint: Variables store shared data between tasks easily [OK]

Common Mistakes:

• Confusing Variables with task scheduling
• Thinking Variables execute tasks
• Using Variables for logging

2. Which of the following is the correct way to set an Airflow Variable named my_var with value 123 inside a PythonOperator task?

easy

A. Variable.set('my_var', 123)

B. Variable.set(my_var, '123')

C. Variable.get('my_var', 123)

D. Variable.create('my_var', 123)

Solution

1. Step 1: Recall Variable.set syntax

   The correct method to set a variable is Variable.set(key, value) where key is a string and value is the data.

2. Step 2: Check option correctness

   Variable.set('my_var', 123) uses Variable.set with key 'my_var' and value 123 correctly as a string key and integer value.

3. Final Answer:

   Variable.set('my_var', 123) -> Option A

4. Quick Check:

   Set variable = Variable.set(key, value) [OK]

Hint: Use Variable.set('key', value) to store data [OK]

Common Mistakes:

• Using Variable.get instead of set to store data
• Not quoting the variable name key
• Using a non-existent method like Variable.create

3. Given the following code snippet in two tasks, what will be printed by task_b?

from airflow.models import Variable

def task_a():
    Variable.set('shared_key', 'hello')

def task_b():
    value = Variable.get('shared_key')
    print(value)

medium

A. None

B. hello

C. shared_key

D. Error: Variable not found

Solution

1. Step 1: Analyze task_a behavior

   task_a sets the Variable 'shared_key' with value 'hello'.

2. Step 2: Analyze task_b behavior

   task_b retrieves the Variable 'shared_key' and prints its value, which is 'hello'.

3. Final Answer:

   hello -> Option B

4. Quick Check:

   Set then get Variable = 'hello' [OK]

Hint: Get returns the stored value by key [OK]

Common Mistakes:

• Expecting the key name instead of value
• Assuming Variable.get returns None if set
• Forgetting to set the Variable before getting

4. You wrote this code in task_b to get a Variable set by task_a:

value = Variable.get('my_var')

But you get an error: KeyError: 'Variable my_var does not exist'. What is the best fix?

medium

A. Set a default value in Variable.get like Variable.get('my_var', default_var='default')

B. Change Variable.get to Variable.set

C. Remove the Variable.get call

D. Restart Airflow scheduler

Solution

1. Step 1: Understand the error cause

   The error means 'my_var' was not set before getting it, so Variable.get fails.

2. Step 2: Use default value to avoid error

   Variable.get supports a default_var parameter to return if key missing, preventing KeyError.

3. Final Answer:

   Set a default value in Variable.get like Variable.get('my_var', default_var='default') -> Option A

4. Quick Check:

   Use default_var to avoid missing key error [OK]

Hint: Add default_var to Variable.get to prevent errors [OK]

Common Mistakes:

• Using Variable.set instead of get to read data
• Ignoring missing Variable errors
• Restarting scheduler without fixing code

5. You want to share a list of user IDs between two tasks in Airflow. Which approach is best to share this data effectively?

hard

A. Write the list to a local file and read it in the next task

B. Pass the list directly as a Python variable between tasks

C. Use XComs to push and pull the list between tasks

D. Serialize the list as JSON string and store it in an Airflow Variable

Solution

1. Step 1: Understand data sharing options

   Airflow Variables are for small strings; passing Python variables directly is not possible between tasks.

2. Step 2: Identify best practice for complex data

   XComs are designed to share data like lists between tasks efficiently and safely.

3. Final Answer:

   Use XComs to push and pull the list between tasks -> Option C

4. Quick Check:

   XComs = best for task-to-task data sharing [OK]

Hint: Use XComs for complex data sharing between tasks [OK]

Common Mistakes:

• Trying to pass Python variables directly
• Using Variables for large or complex data
• Using local files which break portability