Apache Airflow Fundamentals
Apache Airflow is a platform for authoring, scheduling, and monitoring batch data pipelines as directed acyclic graphs defined in Python. It manages task dependencies, retries failures, and provides a web interface for observing pipeline execution.
itData engineering and analytics | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Apache Airflow Fundamentals
Apache Airflow is the traffic controller for repeatable batch work. It does not calculate the warehouse query, store the dataset, or become a message broker after three cups of confidence. It takes a Python workflow, turns it into scheduled work, and keeps a record of what happened.
The useful picture starts with a Dag, the workflow definition. It names tasks and dependency order. A Dag run is one trip through that map. A task instance is one task inside that particular trip. Keep those three separate and a surprising amount of Airflow stops looking like an elaborate calendar with opinions.
The scheduler creates runs and notices which task instances are ready. The executor decides how they reach workers. The workers often ask another system to do the real job. That is why a green Airflow task can still be a poor outcome: submitting an external job is not the same as seeing it finish successfully. The control plane records orchestration state; it does not grant magical transaction powers to every service it calls.
Time is another small ambush. A daily run normally represents a data interval, the period of data it is responsible for, and the logical date identifies that interval rather than the moment a worker woke up. Choose inputs and outputs from that interval. A retry then has something stable to repeat, instead of quietly processing whatever happens to be latest when it returns.
This is also why XCom has modest ambitions. Pass an object location, row count, or external job identifier. Put the dataset itself in the data system built to hold it. Passing a dataframe through orchestration state is how a tidy dependency graph acquires furniture.
Waiting and parallelism are not free. A sensor can occupy a worker while waiting, while deferrable work gives the wait to a triggerer. More workers can still overwhelm one shared database, API, or warehouse, so pools and concurrency limits begin with downstream capacity rather than enthusiasm.
Start with the Intro for the whole component map and the boundaries of the tool. Open Slides when the relationships need a compact picture. Keep the Cheatsheet nearby when Dag, run, task instance, scheduler, and executor begin impersonating one another. The Practice Reference and Exercise turn that model into one local, repeatable Dag test before any external system gets invited to the party.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://airflow.apache.org/docs/apache-airflow/stable/
Supports
- Airflow as a platform for developing, scheduling, and monitoring batch-oriented workflows
- Python-defined workflows, extensibility, user-interface capabilities, and deployment range
- Dag attributes including schedules, tasks, dependencies, callbacks, and parameters
- https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html
Supports
- Dag and task dependency model
- Scheduler, executor, Dag processor, Dag bundle, API server, metadata database, worker, and triggerer responsibilities
- Airflow 3 component separation and task communication through the API server
- Operator, sensor, and TaskFlow task forms
- XCom for small metadata and external storage for large data
- User-interface visibility into Dags, runs, task state, and logs
- https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.html
Supports
- Dag as a workflow model containing tasks, schedules, dependencies, callbacks, and operating details
- Dependency notation, trigger rules, branching, TaskGroups, Dag loading, and Dag testing
- Repeated parsing of top-level Dag code and the cost of expensive top-level work
- Stable topology guidance for dynamically generated Dags
- https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dag-run.html
Supports
- Dag runs as independent workflow instances with their own task instances
- Data interval and logical date semantics
- Run creation after a represented interval ends
- Catchup behavior and Dag run terminal state derived from leaf tasks
- Risk from permissive trigger rules on leaf tasks
- https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/backfill.html
Supports
- Backfill as explicit Dag run creation across a historical date range
- Reprocessing and concurrency controls for backfill runs
- https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/tasks.html
Supports
- Task as the basic execution unit and task instance as a task in a Dag run
- Operator, sensor, and TaskFlow task categories
- Task dependencies, trigger rules, retries, timeouts, and task states
- https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/taskflow.html
Supports
- TaskFlow authoring through decorated Python functions
- XComArg results, automatic dependencies, and implicit XCom movement
- Interoperation between TaskFlow tasks and traditional operators
- https://airflow.apache.org/docs/task-sdk/stable/
Supports
- The Task SDK and airflow.sdk namespace as the current Dag-authoring interface
- Separation of task execution from Airflow internals through the execution API
- Task runtime access to connections, variables, XComs, metrics, and logs
- https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/xcoms.html
Supports
- XCom identity, serialization, push and pull behavior, and TaskFlow return values
- XCom design for small values rather than dataframes or other large payloads
- Difference between per-task-instance XCom and global Variables
- https://airflow.apache.org/docs/apache-airflow/stable/best-practices.html
Supports
- Transaction-like task design and complete outputs
- Repeatable outcomes under retries, stable partition selection, upsert, and avoidance of current time in critical computation
- Dag loader tests, unit tests, self-checks, staging, dependency isolation, and upgrade preparation
- Reduction of top-level parsing work and Dag complexity
- https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/deferring.html
Supports
- Worker-capacity behavior of deferrable operators and triggerer-managed waits
- Resumption after an asynchronous trigger and the role of timeouts
- Difference between sensor reschedule mode and deferral
- https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/assets.html
Supports
- Asset as a logical grouping of data identified by a URI
- Producer asset updates and downstream consumer scheduling
- Airflow treatment of an asset URI as an identifier rather than inspected data
- Time-based, asset-aware, and combined scheduling concepts
- https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/pools.html
Supports
- Pools as limits on parallel execution for tasks that use shared constrained systems
- Pool slots, priority, and queued-task capacity decisions
- https://airflow.apache.org/docs/apache-airflow/stable/installation/dependencies.html
Supports
- Separate Airflow core, Task SDK, provider, extras, and external dependency packages
- Independent installation and upgrade of providers
- Limited integration set in a default installation
- https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/production-deployment.html
Supports
- SQLite as a testing backend and PostgreSQL or MySQL for production
- Distributed executor choices, Dag bundle delivery, durable logging, and component uptime
- Official container images, Helm-based deployment, and live upgrade concerns
- Restriction of sensitive configuration to components that require it
- https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/logging-monitoring/index.html
Supports
- Task and component logs, metrics, traces, callbacks, health checks, and error tracking
- Remote logging choices for distributed and disposable workers
- Component health and operational monitoring scope
- https://airflow.apache.org/docs/apache-airflow/stable/security/security_model.html
Supports
- Deployment manager, Dag author, and operations user roles
- Dag author code execution and trust boundaries
- Component isolation, credential restrictions, API protection, and workload security responsibilities
- Current multi-team isolation limitations
- https://airflow.apache.org/docs/apache-airflow/stable/installation/index.html
Supports
- pipx run apache-airflow standalone as a local development and testing start
- Standalone mode uses a minimal local system and is not for production
- https://airflow.apache.org/docs/apache-airflow/stable/tutorial/fundamentals.html
Supports
- airflow dags test runs one local Dag run without registering database state
- Airflow CLI commands for listing Dags and tasks during local verification
- https://airflow.apache.org/docs/apache-airflow/stable/howto/usage-cli.html
Supports
- airflow dags test can load a Dag from a specified file with -f
- airflow dags list-import-errors can verify discovered Dag import errors
- https://incubator.apache.org/projects/airflow.html
Supports
- Apache Airflow entered the Apache Incubator in 2016
- https://airflow.apache.org/announcements/
Supports
- Apache Airflow became an Apache top-level project in January 2019
- https://airflow.apache.org/blog/airflow-two-point-oh-is-here/
Supports
- Airflow 2.0.0 was released in December 2020
- Airflow 2.0 introduced the TaskFlow API, scheduler high availability, and separately released providers
- https://airflow.apache.org/blog/tags/release/
Supports
- Official Airflow release dates for 2.2.0, 2.4.0, 2.6.0, 2.10.0, and 3.1.0
- https://airflow.apache.org/blog/airflow-three-point-oh-is-here/
Supports
- Airflow 3.0.0 was released on 2025 Apr 22
- Airflow 3 introduced the Task Execution Interface, API server architecture, DAG versioning, scheduler-managed backfills, and data assets
- https://shopify.engineering/lessons-learned-apache-airflow-scale
Supports
- Practitioner evidence on Dag-file delivery, metadata retention, ownership guardrails, schedule bursts, pools, queues, and resource contention in a large Airflow deployment
- https://docs.aws.amazon.com/mwaa/
Supports
- Amazon MWAA as a managed Apache Airflow service
- https://cloud.google.com/products/managed-service-for-apache-airflow
Supports
- Google Cloud Managed Service for Apache Airflow
- https://www.astronomer.io/astro/
Supports
- Astronomer Astro as a managed Airflow offering
- https://docs.dagster.io/
Supports
- Dagster as a data orchestrator with an asset-oriented programming model and managed offering
- https://docs.prefect.io/
Supports
- Prefect workflow-orchestration documentation and its flow-oriented model
