What if you could stop worrying about task order and failures and just watch your workflows run smoothly?
Why Airflow architecture (scheduler, webserver, executor, metadata DB)? - Purpose & Use Cases
Imagine you have many tasks to run every day, like sending emails, processing data, or cleaning files. You try to do all these tasks by hand or with simple scripts, running each one separately and checking if they finished okay.
Doing this manually is slow and confusing. You might forget to run a task, run them in the wrong order, or miss errors. It's hard to see what's done and what's still waiting. If something breaks, fixing it takes a lot of time and guesswork.
Airflow's architecture solves this by organizing tasks into workflows and managing them automatically. The scheduler plans when tasks run, the executor runs them, the webserver shows you the status, and the metadata database keeps track of everything. This way, you get clear control and easy monitoring.
run_task1.sh run_task2.sh run_task3.sh
from airflow import DAG from airflow.operators.bash import BashOperator from datetime import datetime default_args = { 'start_date': datetime(2023, 1, 1), } with DAG('my_dag', default_args=default_args, schedule_interval='@daily', catchup=False) as dag: task1 = BashOperator(task_id='task1', bash_command='run_task1.sh') task2 = BashOperator(task_id='task2', bash_command='run_task2.sh') task1 >> task2
With Airflow architecture, you can automate complex workflows reliably and watch their progress in real time through a friendly interface.
A data team uses Airflow to run daily reports: the scheduler triggers tasks in order, the executor runs them on different machines, the webserver shows if reports succeeded, and the metadata DB stores all history for audits.
Manual task running is slow and error-prone.
Airflow's scheduler, executor, webserver, and metadata DB work together to automate and monitor workflows.
This architecture makes managing many tasks easy, reliable, and visible.
Practice
Solution
Step 1: Understand the role of the scheduler
The scheduler checks the workflow definitions and decides the timing and order of task execution.Step 2: Differentiate from other components
The executor runs tasks, the webserver shows status, and the metadata DB stores info. Only the scheduler plans tasks.Final Answer:
Scheduler -> Option AQuick Check:
Task planning = Scheduler [OK]
- Confusing executor with scheduler
- Thinking webserver runs tasks
- Assuming metadata DB schedules tasks
Solution
Step 1: Recall the Airflow CLI command for webserver
The correct command to start the webserver is simplyairflow webserver.Step 2: Analyze other options
airflow webserver start adds an unnecessary 'start', airflow start webserver reverses the order, and airflow webserver -p adds a port flag which is valid but incomplete without specifying the port number explicitly.Final Answer:
airflow webserver -> Option DQuick Check:
Start webserver = airflow webserver [OK]
- Adding extra words like 'start'
- Reversing command order
- Incorrect or incomplete flags
Solution
Step 1: Understand metadata DB role
The metadata DB stores task states and workflow info. If it is down, Airflow components cannot read or write task status.Step 2: Impact on scheduler and executor
The scheduler depends on the metadata DB to know which tasks to schedule. Without DB access, it cannot schedule new tasks. The executor waits for tasks from the scheduler.Final Answer:
Scheduler will stop scheduling tasks -> Option BQuick Check:
Metadata DB down stops scheduler [OK]
- Thinking tasks run without DB
- Assuming webserver crashes immediately
- Believing executor ignores tasks
Solution
Step 1: Analyze symptoms
Tasks are marked scheduled in the webserver UI but are not running. This means scheduling is done but execution is not happening.Step 2: Identify responsible component
The executor runs the tasks. If tasks are scheduled but not running, the executor might be stuck or misconfigured.Final Answer:
Executor -> Option AQuick Check:
Tasks not running? Check executor [OK]
- Checking scheduler when scheduling works
- Restarting webserver unnecessarily
- Ignoring executor logs
Solution
Step 1: Understand distributed setup needs
In distributed Airflow, multiple executors and schedulers may run on different machines.Step 2: Identify shared resource for coordination
The metadata database stores task states and is the central point both scheduler and executor use to coordinate which tasks to run and their status.Step 3: Exclude other options
The webserver is for UI only, local logs are not shared, and scheduler's local cache is not accessible by executors.Final Answer:
Metadata Database -> Option CQuick Check:
Shared coordination = Metadata DB [OK]
- Thinking webserver shares task state
- Assuming local logs are shared
- Believing scheduler cache syncs executors
Ready to prove it?
Pass the test and this pattern moves unknown
