Atomic operations in pipelines in Apache Airflow - Step-by-Step Execution

Process Flow - Atomic operations in pipelines

Start Pipeline Task

↓

Begin Atomic Operation

↓

Perform Step 1

↓

Perform Step 2

↓

Check for Errors

↓

Commit

↓

End Atomic Operation

↓

Task Complete

The pipeline task starts an atomic operation where multiple steps run. If all succeed, changes commit; if any fail, rollback happens to keep data safe.

Execution Sample

Apache Airflow

with TaskGroup('atomic_task') as atomic_task:
    step1 = BashOperator(task_id='step1', bash_command='echo Step 1')
    step2 = BashOperator(task_id='step2', bash_command='echo Step 2')
    step1 >> step2

This Airflow task group runs two steps in order, simulating an atomic operation where both must succeed.

Process Table

Step	Action	Result	Next Step
1	Start atomic_task group	Task group initialized	Execute step1
2	Execute step1	Step 1 output: 'Step 1'	Execute step2
3	Execute step2	Step 2 output: 'Step 2'	Check for errors
4	Check for errors	No errors found	Commit changes
5	Commit changes	Changes saved successfully	End atomic_task
6	End atomic_task	Task group completed	Pipeline continues

💡 All steps succeeded, so atomic operation committed and pipeline continues.

Status Tracker

Variable	Start	After Step 1	After Step 2	Final
step1_status	None	Success	Success	Success
step2_status	None	None	Success	Success
atomic_task_status	None	Running	Running	Success

Key Moments - 2 Insights

Why do we need to check for errors after all steps instead of after each step?

Checking after all steps ensures the entire group succeeds before committing, as shown in execution_table row 4. This keeps the operation atomic.

What happens if step2 fails?

If step2 fails, the pipeline triggers a rollback instead of commit, preventing partial changes. This is implied by the 'Check for errors' decision in execution_table row 4.

Visual Quiz - 3 Questions

Look at the execution table, what is the output of step1 at step 2?

A Step 2 output: 'Step 2'

B Step 1 output: 'Step 1'

C Task group initialized

D Changes saved successfully

💡 Hint

Refer to execution_table row 2 under the 'Result' column.

At which step does the pipeline decide to commit changes?

A Step 4

B Step 3

C Step 5

D Step 6

💡 Hint

Look at execution_table row 4 where 'Check for errors' leads to 'Commit changes'.

If step1 failed, how would the atomic_task_status change after Step 1?

A Success

B Running

C Failed

D None

💡 Hint

Check variable_tracker for how statuses update after each step.

Concept Snapshot

Atomic operations in pipelines ensure multiple steps succeed together or fail together.
Use task groups or transactions to group steps.
Check for errors after all steps before committing.
Rollback if any step fails to keep data consistent.
This prevents partial updates and keeps pipelines reliable.

Full Transcript

Atomic operations in pipelines mean running several steps as one unit. If all steps succeed, changes are saved. If any step fails, all changes are undone. In Airflow, this can be done using task groups where steps run in order. After all steps, the pipeline checks for errors. If none, it commits changes; if errors exist, it rolls back. This keeps data safe and consistent. The execution table shows each step's action and result. Variables track step statuses. Key moments clarify why error checking happens after all steps and what happens on failure. The quiz tests understanding of step outputs, commit timing, and failure effects.

Practice

1. What does it mean for a task in an Airflow pipeline to be atomic?

easy

A. The task can be skipped without affecting the pipeline

B. The task runs multiple times in parallel

C. The task either completes fully or does not change anything at all

D. The task runs only once per day

Solution

1. Step 1: Understand atomicity in pipelines

   Atomic means an operation is indivisible: it either fully happens or not at all.

2. Step 2: Apply this to Airflow tasks

   In Airflow, atomic tasks ensure no partial changes if they fail.

3. Final Answer:

   The task either completes fully or does not change anything at all -> Option C

4. Quick Check:

   Atomic = all or nothing [OK]

Hint: Atomic means all or nothing for task completion [OK]

Common Mistakes:

• Thinking atomic means running multiple times
• Confusing atomic with task scheduling frequency
• Assuming atomic means task can be skipped

2. Which of the following is the correct way to define a PythonOperator task in Airflow to ensure atomicity?

easy

A. task = PythonOperator(task_id='task1', python_callable=my_func, retry=3)

B. task = PythonOperator(task_id='task1', python_callable=my_func, retries='three')

C. task = PythonOperator(task_id='task1', python_callable=my_func, retry_count=3)

D. task = PythonOperator(task_id='task1', python_callable=my_func, retries=3)

Solution

1. Step 1: Check PythonOperator parameters

   The correct parameter for retry attempts is retries with an integer value.

2. Step 2: Validate each option

   task = PythonOperator(task_id='task1', python_callable=my_func, retries=3) uses retries=3 correctly. Options A, B, and D use wrong parameter names or types.

3. Final Answer:

   task = PythonOperator(task_id='task1', python_callable=my_func, retries=3) -> Option D

4. Quick Check:

   Correct retries param = task = PythonOperator(task_id='task1', python_callable=my_func, retries=3) [OK]

Hint: Use 'retries' with integer for retry count [OK]

Common Mistakes:

• Using string instead of integer for retries
• Using incorrect parameter names like retry or retry_count
• Missing retries parameter for retry logic

3. Given this Airflow task code snippet, what will be the output if my_task fails on first try but succeeds on retry?

task = PythonOperator(
    task_id='my_task',
    python_callable=my_func,
    retries=1,
    retry_delay=timedelta(seconds=5)
)

medium

A. Task fails and pipeline stops immediately

B. Task retries once after 5 seconds and then succeeds

C. Task retries infinitely until success

D. Task skips retry and marks success

Solution

1. Step 1: Understand retries and retry_delay

   Retries=1 means one retry attempt after failure, retry_delay=5 seconds means wait 5 seconds before retry.

2. Step 2: Apply to task behavior

   If first try fails, Airflow waits 5 seconds and retries once. If retry succeeds, task is marked success.

3. Final Answer:

   Task retries once after 5 seconds and then succeeds -> Option B

4. Quick Check:

   Retries=1 means one retry attempt [OK]

Hint: Retries=1 means one retry after delay [OK]

Common Mistakes:

• Assuming no retry happens
• Thinking retries means infinite retries
• Ignoring retry_delay effect

4. You wrote a task that updates a database but sometimes leaves partial updates if it fails. What is the best way to fix this atomicity issue?

medium

A. Add database transactions inside the task to commit or rollback changes

B. Increase the task timeout to avoid failures

C. Remove retries to prevent repeated partial updates

D. Split the task into multiple smaller tasks without transactions

Solution

1. Step 1: Identify cause of partial updates

   Partial updates happen if database changes are not atomic, meaning no transaction control.

2. Step 2: Apply database transactions

   Using transactions ensures all changes commit together or rollback on failure, fixing atomicity.

3. Final Answer:

   Add database transactions inside the task to commit or rollback changes -> Option A

4. Quick Check:

   Transactions ensure atomic DB updates [OK]

Hint: Use DB transactions to ensure all-or-nothing updates [OK]

Common Mistakes:

• Thinking increasing timeout fixes atomicity
• Removing retries causes no atomicity improvement
• Splitting tasks without transactions still risks partial updates

5. You want to ensure a pipeline task that writes files to cloud storage is atomic. Which approach best guarantees no partial files remain if the task fails?

hard

A. Write files to a temporary location first, then move them to final location after success

B. Write files directly to final location and delete on failure manually

C. Write files without retries to avoid duplicates

D. Write files in parallel to speed up the task

Solution

1. Step 1: Understand atomic file writes

   Writing directly risks partial files if failure occurs mid-write.

2. Step 2: Use temporary location and move

   Writing to temp location then moving is atomic because move is usually instant and atomic, avoiding partial files in final location.

3. Final Answer:

   Write files to a temporary location first, then move them to final location after success -> Option A

4. Quick Check:

   Temp write + move = atomic file update [OK]

Hint: Write temp files then move to final location atomically [OK]

Common Mistakes:

• Writing directly risks partial files
• Deleting on failure is error-prone
• Skipping retries does not guarantee atomicity
• Parallel writes do not ensure atomic single file