DAG performance tracking in Apache Airflow - Time & Space Complexity
When tracking DAG performance in Airflow, we want to understand how the time to process tasks grows as the number of tasks increases.
We ask: How does adding more tasks affect the total time to complete the DAG?
Analyze the time complexity of this DAG task execution loop.
for task in dag.tasks:
task.run()
log_performance(task)
update_metrics(task)
# dag.tasks is a list of tasks in the DAG
# Each task.run() executes the task logic
# log_performance and update_metrics record timing info
This code runs each task in the DAG one by one and tracks its performance.
Look for repeated actions that affect time.
- Primary operation: Loop over all tasks in the DAG.
- How many times: Once per task, so as many times as there are tasks.
As the number of tasks grows, the total time grows roughly the same amount.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 task runs + 10 logs + 10 metric updates |
| 100 | 100 task runs + 100 logs + 100 metric updates |
| 1000 | 1000 task runs + 1000 logs + 1000 metric updates |
Pattern observation: Doubling tasks roughly doubles total work and time.
Time Complexity: O(n)
This means the total time grows linearly with the number of tasks in the DAG.
[X] Wrong: "Adding more tasks won't affect total execution time much because tasks run independently."
[OK] Correct: Even if tasks run independently, tracking and running each task still takes time, so more tasks mean more total work.
Understanding how task count affects DAG run time helps you design efficient workflows and explain performance trade-offs clearly.
"What if we parallelize task runs instead of running them sequentially? How would the time complexity change?"
Practice
Solution
Step 1: Understand DAG performance tracking
DAG performance tracking focuses on measuring execution times of workflows and tasks.Step 2: Identify the main goal
The goal is to find how long tasks and DAG runs take to help improve pipeline speed.Final Answer:
To measure how long workflows and tasks take to run -> Option AQuick Check:
DAG performance tracking = measuring run times [OK]
- Confusing performance tracking with task ordering
- Thinking it creates or deletes DAGs
- Mixing logs management with performance tracking
Solution
Step 1: Identify models related to execution times
DagRun stores info about the whole DAG run, TaskInstance stores info about each task run.Step 2: Match model to task execution time
TaskInstance tracks start and end times for each task, so it holds execution time data.Final Answer:
TaskInstance -> Option CQuick Check:
TaskInstance = task execution info [OK]
- Choosing DagRun which tracks whole DAG, not tasks
- Confusing Variables or Connections with timing data
- Assuming all info is in one model
from airflow.models import TaskInstance from datetime import datetime, timedelta start = datetime(2024, 6, 1, 10, 0, 0) end = datetime(2024, 6, 1, 10, 5, 30) ti = TaskInstance(dag_id='example_dag', task_id='task1', execution_date=start) ti.start_date = start ti.end_date = end print((ti.end_date - ti.start_date).total_seconds())
Solution
Step 1: Identify variable name mismatch
The code assigns TaskInstance to 'ti' but prints using 'ti', which is correct. However, the code snippet uses 'ti' consistently, so no mismatch here.Step 2: Check for syntax errors
The code is syntactically correct, but the TaskInstance constructor requires a DAG object or context in recent Airflow versions, so this code may raise a runtime error.Step 3: Consider the actual output
Assuming the code runs, the output would be 330.0 seconds.Final Answer:
330.0 -> Option DQuick Check:
5 min 30 sec = 330.0 seconds [OK]
- Confusing minutes with seconds
- Expecting integer instead of float
- Syntax errors from missing imports (not here)
ti = TaskInstance(dag_id='example_dag', task_id='task1', execution_date='2024-06-01T10:00:00') ti.start_date = datetime(2024, 6, 1, 10, 0, 0) ti.end_date = datetime(2024, 6, 1, 10, 5, 0) duration = (ti.end_date - ti.start_date).total_seconds() print(duration)What is the likely cause of the error?
Solution
Step 1: Check execution_date type
execution_date must be a datetime object, not a string, to avoid errors.Step 2: Confirm other parts are correct
start_date and end_date are datetime objects, total_seconds() is valid method.Final Answer:
execution_date should be a datetime, not a string -> Option AQuick Check:
execution_date type error = execution_date should be a datetime, not a string [OK]
- Passing string instead of datetime for execution_date
- Thinking start_date/end_date must be strings
- Believing total_seconds() is invalid
Solution
Step 1: Understand data sources for task durations
TaskInstance has start_date and end_date for each task, so durations come from there.Step 2: Calculate average duration correctly
Query all TaskInstances for the DAG run, compute (end_date - start_date) for each, then average.Final Answer:
Query TaskInstance for all tasks of the DAG run, calculate average of (end_date - start_date) -> Option BQuick Check:
Average task duration = average of TaskInstance times [OK]
- Using DagRun duration divided by task count (wrong average)
- Storing durations manually in Variables (extra work)
- Counting rows without timing info
Ready to prove it?
Pass the test and this pattern moves unknown
