Bird
Raised Fist0
Apache Airflowdevops~10 mins

Handling schema changes in data pipelines in Apache Airflow - Commands & Configuration

Choose your learning style10 modes available
Introduction
Data pipelines often break when the structure of incoming data changes unexpectedly. Handling schema changes means updating your pipeline to accept new or modified data formats without stopping the flow.
When a new column is added to your data source and your pipeline needs to process it.
When a column is removed or renamed in the incoming data and your pipeline must adapt.
When the data type of a column changes, such as from integer to string.
When you want to validate incoming data schema before processing to avoid errors.
When you want to maintain historical data compatibility while accepting new schema versions.
Config File - my_dag.py
my_dag.py
from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.utils.dates import days_ago
import json

def validate_schema(**kwargs):
    expected_schema = {'id': int, 'name': str, 'age': int}
    data = kwargs['ti'].xcom_pull(task_ids='fetch_data')
    for record in data:
        for key, expected_type in expected_schema.items():
            if key not in record:
                raise ValueError(f"Missing key {key} in record")
            if not isinstance(record[key], expected_type):
                raise TypeError(f"Key {key} expected type {expected_type.__name__}, got {type(record[key]).__name__}")

def fetch_data():
    # Simulated data fetch with schema change (extra 'email' field)
    return [
        {'id': 1, 'name': 'Alice', 'age': 30, 'email': 'alice@example.com'},
        {'id': 2, 'name': 'Bob', 'age': 25, 'email': 'bob@example.com'}
    ]

def process_data(**kwargs):
    data = kwargs['ti'].xcom_pull(task_ids='fetch_data')
    # Process data ignoring unknown fields
    processed = [{k: v for k, v in record.items() if k in ['id', 'name', 'age']} for record in data]
    print(f"Processed data: {processed}")

def handle_schema_change():
    print("Schema change handled by ignoring unknown fields and validating required ones.")

default_args = {
    'owner': 'airflow',
    'start_date': days_ago(1),
}

dag = DAG(
    'handle_schema_changes',
    default_args=default_args,
    schedule_interval=None,
    catchup=False
)

fetch_task = PythonOperator(
    task_id='fetch_data',
    python_callable=fetch_data,
    dag=dag
)

validate_task = PythonOperator(
    task_id='validate_schema',
    python_callable=validate_schema,
    dag=dag
)

process_task = PythonOperator(
    task_id='process_data',
    python_callable=process_data,
    dag=dag
)

handle_change_task = PythonOperator(
    task_id='handle_schema_change',
    python_callable=handle_schema_change,
    dag=dag
)

fetch_task >> validate_task >> process_task >> handle_change_task

This Airflow DAG simulates handling schema changes in a data pipeline.

fetch_data simulates fetching data with an extra 'email' field not in the expected schema.

validate_schema checks required fields and their types, ignoring extra fields.

process_data processes only the expected fields, ignoring unknown ones.

handle_schema_change is a placeholder to show where you might add logic to adapt to schema changes.

The DAG runs tasks in order: fetch, validate, process, then handle schema changes.

Commands
List all available DAGs to confirm the new DAG 'handle_schema_changes' is recognized by Airflow.
Terminal
airflow dags list
Expected OutputExpected
handle_schema_changes example_bash_operator example_python_operator
Trigger the DAG manually to run the tasks and test schema change handling.
Terminal
airflow dags trigger handle_schema_changes
Expected OutputExpected
Created <DagRun handle_schema_changes @ 2024-06-01T12:00:00+00:00: manual__2024-06-01T12:00:00+00:00, externally triggered: True>
List all tasks in the DAG to understand the workflow steps.
Terminal
airflow tasks list handle_schema_changes
Expected OutputExpected
fetch_data validate_schema process_data handle_schema_change
Run the 'fetch_data' task alone for the given date to verify data fetching with schema changes.
Terminal
airflow tasks test handle_schema_changes fetch_data 2024-06-01
Expected OutputExpected
[2024-06-01 12:00:00,000] {python.py:114} INFO - Running command: ['python3', '-m', 'airflow', 'tasks', 'run', 'handle_schema_changes', 'fetch_data', '2024-06-01', '--local'] [2024-06-01 12:00:01,000] {python.py:118} INFO - Done. Returned value: [{'id': 1, 'name': 'Alice', 'age': 30, 'email': 'alice@example.com'}, {'id': 2, 'name': 'Bob', 'age': 25, 'email': 'bob@example.com'}]
Run the 'validate_schema' task to check if the data matches the expected schema, ignoring extra fields.
Terminal
airflow tasks test handle_schema_changes validate_schema 2024-06-01
Expected OutputExpected
[2024-06-01 12:01:00,000] {python.py:114} INFO - Running command: ['python3', '-m', 'airflow', 'tasks', 'run', 'handle_schema_changes', 'validate_schema', '2024-06-01', '--local'] [2024-06-01 12:01:01,000] {python.py:118} INFO - Done. Returned value: None
Key Concept

If you remember nothing else, remember: validate required fields strictly but ignore unknown fields to handle schema changes smoothly.

Common Mistakes
Failing the pipeline when extra fields appear in the data.
This causes unnecessary pipeline failures for harmless schema additions.
Validate only required fields and ignore extra fields to allow forward compatibility.
Not validating data types, leading to errors downstream.
Incorrect data types can cause crashes or wrong results later in the pipeline.
Always check that required fields have the expected data types before processing.
Hardcoding schema without a way to update it when changes occur.
Makes the pipeline brittle and hard to maintain as data evolves.
Design schema validation to be easy to update and handle optional fields gracefully.
Summary
Create an Airflow DAG that fetches data, validates schema, processes data, and handles schema changes.
Validate required fields and their types but ignore unknown fields to avoid pipeline failures.
Test tasks individually to ensure each step handles schema changes correctly.

Practice

(1/5)
1. What is the main reason to handle schema changes in Airflow data pipelines?
easy
A. To prevent pipeline failures due to unexpected data format changes
B. To speed up the execution of tasks
C. To reduce the number of DAGs in Airflow
D. To increase the number of parallel tasks

Solution

  1. Step 1: Understand schema changes impact

    Schema changes can cause data format mismatches that break pipelines.
  2. Step 2: Identify the main goal of handling schema changes

    Handling schema changes aims to avoid pipeline failures by validating schemas.
  3. Final Answer:

    To prevent pipeline failures due to unexpected data format changes -> Option A
  4. Quick Check:

    Prevent failures = C [OK]
Hint: Schema changes break pipelines; handle to avoid failure [OK]
Common Mistakes:
  • Thinking schema changes speed up tasks
  • Confusing schema handling with DAG count
  • Assuming schema changes increase parallelism
2. Which Airflow operator is best suited to check and validate data schema before processing?
easy
A. PythonOperator
B. BashOperator
C. DummyOperator
D. EmailOperator

Solution

  1. Step 1: Identify operator for custom Python code

    PythonOperator runs Python functions, ideal for schema checks.
  2. Step 2: Compare with other operators

    BashOperator runs shell commands, DummyOperator does nothing, EmailOperator sends emails.
  3. Final Answer:

    PythonOperator -> Option A
  4. Quick Check:

    Python code for schema check = A [OK]
Hint: Use PythonOperator for custom schema validation code [OK]
Common Mistakes:
  • Choosing BashOperator for Python code
  • Using DummyOperator which does nothing
  • Selecting EmailOperator unrelated to schema checks
3. Given this PythonOperator task in Airflow, what happens if the schema check fails by raising an Exception?
def check_schema():
    if not schema_is_valid():
        raise ValueError('Schema mismatch detected')

check_schema_task = PythonOperator(
    task_id='check_schema',
    python_callable=check_schema,
    dag=dag
)
medium
A. The task completes successfully ignoring the error
B. The task fails and the DAG run is marked as failed
C. The task retries automatically without failing
D. The task is skipped and DAG continues

Solution

  1. Step 1: Understand exception effect in PythonOperator

    Raising an Exception causes the task to fail in Airflow.
  2. Step 2: Check DAG run status on task failure

    When a task fails without retries, the DAG run is marked failed.
  3. Final Answer:

    The task fails and the DAG run is marked as failed -> Option B
  4. Quick Check:

    Exception raised = task fail = D [OK]
Hint: Exception in PythonOperator causes task failure [OK]
Common Mistakes:
  • Assuming task skips on exception
  • Thinking task retries automatically without retry config
  • Believing task completes despite error
4. You wrote this schema validation function in Airflow but the DAG fails to detect schema mismatches properly. What is the error?
def validate_schema():
    if schema_is_valid():
        raise ValueError('Schema mismatch detected')

validate_task = PythonOperator(
    task_id='validate_schema',
    python_callable=validate_schema,
    dag=dag
)
medium
A. The PythonOperator is missing retries parameter
B. The task_id is invalid and causes failure
C. The condition is reversed; it raises error when schema is valid
D. The function does not return any value

Solution

  1. Step 1: Analyze the condition logic

    The function raises error if schema_is_valid() is True, which is wrong.
  2. Step 2: Identify correct logic for schema validation

    Error should raise when schema_is_valid() is False, indicating mismatch.
  3. Final Answer:

    The condition is reversed; it raises error when schema is valid -> Option C
  4. Quick Check:

    Raise error on invalid schema, not valid = B [OK]
Hint: Check if condition logic matches error raising intent [OK]
Common Mistakes:
  • Reversing condition logic
  • Ignoring task_id naming rules
  • Expecting return value in PythonOperator callable
5. You want to handle schema changes gracefully in Airflow by branching: if schema matches, continue processing; if not, send alert and stop. Which Airflow feature helps implement this logic?
hard
A. LatestOnlyOperator to run tasks only on latest DAG run
B. SubDagOperator to run schema check in a sub-DAG
C. TriggerDagRunOperator to start a new DAG on schema mismatch
D. BranchPythonOperator to choose next task based on schema check

Solution

  1. Step 1: Understand branching in Airflow

    BranchPythonOperator allows choosing next task based on condition.
  2. Step 2: Match branching to schema check use case

    Use BranchPythonOperator to continue or alert based on schema validity.
  3. Final Answer:

    BranchPythonOperator to choose next task based on schema check -> Option D
  4. Quick Check:

    Branching logic = BranchPythonOperator = A [OK]
Hint: Use BranchPythonOperator for conditional task flow [OK]
Common Mistakes:
  • Using SubDagOperator which is for nested DAGs
  • TriggerDagRunOperator starts new DAG, not branching
  • LatestOnlyOperator controls run timing, not branching
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard