[任务调度/工作流] Apache Airflow：以代码为中心的开源工作流编排与批处理调度平台(领导者)

0 序

  • 目前大数据领域，主要用到的任务调度与工作流系统：Apache DolphiScheduler、Apache Airflow

    • XXL-Job（早年在使用，现在基本退出历史舞台）

  • 本篇讲讲 AirFlow。

1 概述：Apache Airflow

1.1 产品介绍

  • Apache Airflow® 是一个开源的工作流编排（Orchestration）与批处理调度平台，用于以【编程方式】开发、调度和监控工作流。
    • 它由 Python 实现，核心思想是 "代码即工作流（Workflow as Code）"：用户用标准 Python 编写 DAG（有向无环图）来定义任务及其依赖关系，平台负责按时间或事件触发执行，并提供 Web UI 可视化监控、管理与调试。

image

image

  • 产品定位：面向数据工程与 AI 场景的批处理工作流编排平台，是当前业界事实上的开源数据编排标准（de facto standard）。

  • 诞生的背景与原因：

    • 2014 年前后，Airbnb 内部数据工程管道爆炸式增长，cron 与脚本难以管理复杂依赖、无法监控任务健康状态。
    • 创始人 Maxime Beauchemin 因此创建 Airflow，将"工作流定义"与"调度执行"分离。

  • 解决的核心问题：

    • 复杂任务依赖关系编排、定时/事件驱动调度、任务状态与日志的统一可视化监控、失败重试与告警、跨技术栈的管道连接。

  • URLs：

image

image
image

image

1.2 发展历程

时间 里程碑
2014-10 Maxime Beauchemin 在 Airbnb 发起 Airflow 项目
2015-06 正式开源，托管于 Airbnb GitHub
2016-03 进入 Apache 软件基金会孵化器
2019-01 晋升为 Apache 顶级项目（Top-Level Project），彼时已被 200+ 组织使用（Adobe、Airbnb、Google、ING、Lyft、Twitter 等）
2020-12 发布 2.0：重大架构重构——多 Scheduler 支持、KubernetesExecutor、稳定 REST API、TaskFlow API（@task 装饰器）
2022 2.3 引入 Dynamic Task Mapping（动态任务映射）；2.4 引入 Datasets 数据感知调度
2025-04 发布 3.0（项目史上最大版本）：服务化架构（Task Execution API）、Edge Executor、DAG 版本化、Assets 资产化调度、React 全新 UI、多语言 Task SDK
2026 当前稳定文档版本为 3.2.x，持续演进 AI/ML 工作流支持

1.3 主要功能

  • DAG 编程式编排：纯 Python 定义任务与依赖，支持分支、循环、动态生成任务、跨任务数据传递（XCom）。
  • 多样化调度：定时调度（cron / 自定义 Timetable）、事件驱动调度（Assets 数据感知：上游产出数据触发下游 DAG）、手动触发、TriggerDagRunOperator 跨 DAG 触发、backfill 补数（3.0 起由 Scheduler 统一管理）。
  • 丰富连接器生态：官方与社区维护 300+ Providers（约 1,700+ operator/hook/sensor 模块），可连接 GCP、AWS、Azure、数据库、消息队列、大数据组件乃至 AI/Agent 工具。
  • Web UI 与 API：基于 React 重写的现代化 UI（3.x），支持 DAG 可视化、任务日志查看、手动触发、DAG 版本历史查看；提供完整 REST API。
  • 可靠执行机制：失败自动重试、重试延迟、触发规则（Trigger Rules）、任务优先级与资源池（Pool）、告警通知（Email/Slack 等）。
  • 动态任务映射（Dynamic Task Mapping）：根据上游输出动态生成多个并行任务实例。
  • 可延迟算子（Deferrable Operators）：配合 Triggerer 以极低资源占用等待外部条件。
  • 安全与多租户：RBAC 权限、LDAP/OAuth SSO、连接凭据加密存储、变量管理。
  • 可观测性：内置 metrics（Prometheus 兼容）、与 Grafana 等监控系统集成。

1.4 核心优势

  1. 表达力最强的工作流定义：完全基于 Python，可编程动态生成管道、编写任意复杂逻辑，灵活性远超配置式/拖拽式平台。
  2. 生态无可匹敌：300+ Providers、3,600+ 贡献者、约 46.4K GitHub Stars（2026-08）、月下载量超 3,000 万次，是数据工程领域使用最广的开源编排器。
  3. 架构灵活、扩展性好：Executor 可插拔——从单机 Sequential/Local，到 Celery 分布式，再到 KubernetesExecutor 按任务弹性伸缩；3.0 起支持 Edge Executor 远程/边缘执行。
  4. 数据感知与事件驱动：Assets/Datasets 机制让管道间以"数据就绪"而非固定时间耦合，更贴近现代数据平台。
  5. 持续演进、社区活跃：Airflow 3.x 引入服务化架构与 Task SDK，官方明确支持 ML 训练、模型推理、Agentic/LLM 工作流，紧跟 AI 趋势。
  6. 生产验证充分：Airbnb、Google、Twitter、PayPal、ING 等大量头部公司多年生产使用，云厂商均提供托管服务（AWS MWAA、GCP Cloud Composer、Astronomer Astro）。

1.5 主要短板

  1. 学习曲线陡峭：要求 Python 与 DAG/Operator 概念，非 Python 开发者上手成本高。
  2. 可视化编排弱：DAG 靠代码定义，无拖拽画布；业务人员难以直接参与编排。
  3. Scheduler 高可用与扩展复杂：Scheduler 为集中式设计，多 Scheduler 需依赖数据库锁防重复调度；元数据库（PostgreSQL/MySQL）易成为性能与可用性瓶颈。
  4. 调度粒度偏批处理：以分钟级为主，秒级实时调度能力有限，不适合实时流处理（无原生的流式执行引擎）。
  5. 运维组件多：生产部署需管理 Scheduler、Webserver、Worker、元数据库、消息队列（Celery）、日志存储，且分布式部署存在 DAG 代码分发/版本同步成本。
  6. 极端规模下性能受限：超大任务量下调度延迟上升、DAG 解析开销大，社区亦有"任务过多会卡死"的反馈。

1.6 局限性

  • 只编排、不计算：Airflow 是"调度器/编排器"，本身不执行数据处理，计算需交给外部系统（Spark、Flink、数据库等）。
  • 不提供计算资源管理与调度：与 YARN/K8s 原生资源调度不同，任务资源分配依赖所选 Executor 与外部集群。
  • 实时/流式场景缺失：定位为批处理与近实时（事件驱动），无法替代 Flink/Spark Streaming 等流处理系统。
  • 依赖元数据库：所有状态集中于元数据库，DB 故障影响全局调度能力。
  • 监控告警体系相对基础：复杂告警策略、SLA 管理能力弱于专业运维平台。

1.7 适用场景

  • 数据管道 ETL/ELT：定时或数据触发的大批量数据同步、清洗、转换。
  • 数据仓库/数据湖建设：分层建模、批量加载、指标计算等离线作业编排。
  • 机器学习/MLOps：模型训练、超参调优、批量推理、实验管道编排。
  • AI/LLM 工作流（3.x 官方支持）：Agentic 工作流、模型微调、非区间式推理任务。
  • 事件驱动的数据管道：上游数据产出自动触发下游处理（Assets 调度）。
  • 定时报表与批处理任务：需要复杂依赖关系与动态逻辑的通用批处理。

1.8 同类竞品

类别 代表产品
数据编排平台 Apache DolphinScheduler、Dagster、Prefect、Luigi、Apache Oozie（旧）、Azkaban（旧）
轻量任务调度 XXL-Job、Quartz、Elastic-Job、PowerJob
AI 工作流平台 Dify、n8n、Coze（商业/闭源）、Flowise、LangFlow
通用工作流引擎 Temporal、Cadence、Argo Workflows（K8s）

1.9 发展趋势

  • 社区活跃度：Star 持续稳步增长（2026-01 约 43.8K → 2026-08 约 46.4K，Gitstar 快照），Forks 约 17.5K，贡献者 3,600+；每月 PyPI 下载量超 3,000 万次，服务组织超 8 万家。
  • 服务化与多语言化：3.x 的 Task Execution API + Task SDK 使任务可在任意运行时（容器、边缘、其他语言）执行，打破"Python 专属"边界。
  • 事件驱动与数据感知：Assets 调度体系持续完善，向"数据就绪即触发"演进。
  • AI/ML 原生支持：官方将 Agentic/LLM 工作流列为一等公民，与 AI 工具链深度融合。
  • 云原生与托管化：K8s 部署成熟，AWS/GCP/Astronomer 等托管服务普及，商业化生态（Astronomer）反哺社区。
  • 总结：Airflow 正从"批处理调度器"演进为"面向数据与 AI 的统一编排平台"，并保持开源【数据编排生态】的领导者地位。

2 工作原理与架构

2.1 概念术语

术语 含义
DAG 有向无环图，描述任务及其依赖关系的整体工作流，用 Python 定义
Task / Operator DAG 中的最小执行单元；Operator 是内置/扩展的任务模板（Bash、Python、SQL 等）
Sensor 特殊算子，等待外部条件满足后再继续（文件到达、数据就绪等）
DAG Run DAG 的一次具体执行实例（对应一个逻辑日期）
Task Instance 某个 Task 在特定 DAG Run 中的一次执行实例，含状态（queued/running/success/failed…）
Scheduler 调度器，负责判断何时触发 DAG、将就绪任务提交给 Executor
Executor 执行器，是 Scheduler 的配置属性，负责把任务分发出去（Sequential/Local/Celery/Kubernetes/Edge）
Worker 工作节点，真正运行任务（调用 Operator 的 execute 方法）
Webserver Web 服务器，提供 UI 与 REST API
Metadata DB 元数据库（PostgreSQL/MySQL/SQLite），存储 DAG 定义、任务状态、变量、连接等
Triggerer 触发器（2.2+），运行可延迟算子的事件循环，低资源占用
XCom 任务间跨进程数据传递机制
Provider 集成包，提供面向特定系统（云厂商/数据库/工具）的 Operator、Hook、Sensor
Asset / Dataset 数据资产（3.0 由 Dataset 更名），用于数据感知/事件驱动调度
Pool / Priority 资源池与优先级，控制任务并发与执行顺序
Backfill 补数/回填，对历史时间区间补跑任务

2.2 架构与运行原理

架构总览（Airflow 3.x）

flowchart LR subgraph 编排层["编排层（控制平面）"] SCH["Scheduler 调度器"] DAGP["DAG Processor<br/>解析并序列化 DAG"] EX["Executor 执行器<br/>Local / Celery / Kubernetes / Edge"] WS["Webserver<br/>React UI + FastAPI"] TR["Triggerer 触发器"] end subgraph 存储层 DB[("Metadata DB<br/>PostgreSQL / MySQL")] LOG[("日志与远端存储<br/>S3 / GCS / 本地")] end subgraph 执行层["执行层（数据平面）"] W1["Worker 1"] W2["Worker 2"] W3["Worker N / Pod"] end DAGF["DAG Python 文件<br/>（代码仓库）"] --> DAGP DAGP -->|序列化 DAG 定义| DB DB <--> SCH SCH -->|就绪任务| EX EX -->|分发| W1 EX -->|分发| W2 EX -->|分发| W3 WS <--> DB TR <--> DB W1 -->|执行结果/状态| DB W2 -->|执行结果/状态| DB W3 -->|执行结果/状态| DB W1 --> LOG W2 --> LOG W3 --> LOG

核心运行流程

  1. DAG 解析：DAG Processor 周期性扫描 dags/ 目录中的 Python 文件，解析出 DAG 结构并序列化存入元数据库（3.x 中解析与调度解耦）。
  2. 调度决策：Scheduler 持续循环，检查每个 DAG 是否到达调度时间（Timetable/Assets 触发）、依赖是否满足、并发是否超限，将就绪的 Task Instance 置为 queued 并交给 Executor。
  3. 任务分发：Executor 将任务分发到执行层——LocalExecutor 本地进程、CeleryExecutor 经消息队列（Redis/RabbitMQ）到 Worker、KubernetesExecutor 动态创建 Pod、EdgeExecutor 分发到远程/边缘环境。
  4. 任务执行：Worker/Pod 运行 Operator 的 execute()，期间可与外部系统交互（SQL、API、Spark 等）。
  5. 状态回写与监控：任务状态与日志实时回写元数据库/日志存储；Webserver 从元数据库读取并在 UI 展示 DAG 图、任务状态、日志；失败任务按重试策略重新入队。
  6. 触发机制：Triggerer 为可延迟算子维持长连接事件循环，条件满足后唤醒任务，大幅降低空闲任务资源占用。

任务状态机

None → Scheduled → Queued → Running → Success
                        ↘ Failed → UpForRetry → Scheduled（重试）
                        ↘ Skipped / UpstreamFailed（依赖失败）

image

https://blog.csdn.net/MXin_/article/details/130448112

3 使用指南

3.1 安装部署

官方支持 pip / uv 安装，也提供 Docker Compose 与 Kubernetes（Helm）部署。

Linux / macOS（pip 安装，生产常用）

# 1. 安装（指定版本并使用官方约束文件避免依赖冲突）
AIRFLOW_VERSION=3.2.0
PYTHON_VERSION="$(python --version | cut -d " " -f 2 | cut -d "." -f 1-2)"
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt"
pip install "apache-airflow==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"

# 2. 初始化元数据库（默认 SQLite，生产建议先配置 PostgreSQL/MySQL）
airflow db migrate

# 3. 创建管理员用户
airflow users create \
  --username admin --firstname admin --lastname admin \
  --role Admin --email admin@example.com --password admin

# 4. 启动服务（分别在不同终端/进程）
airflow webserver --port 8080   # Web UI
airflow scheduler                # 调度器
airflow triggerer                # 触发器（使用可延迟算子时需要）

快速体验（一条命令）

pipx run apache-airflow standalone   # 或 uvx apache-airflow standalone
# 自动生成管理员密码，使用 SQLite，立即在 http://localhost:8080 可用

Docker & Standalone 版 （亲测）

docker pull docker.mirrors.ustc.edu.cn/apache/airflow:2.10.5

docker run   -d -p 8080:8080 -e AIRFLOW__CORE__LOAD_EXAMPLES=true -v ${PWD}/dags:/usr/local/airflow/dags --name airflow apache/airflow:2.10.5 standalone

Docker Compose（开发/测试最常用）

curl -LfO 'https://airflow.apache.org/docs/apache-airflow/3.2.0/docker-compose.yaml'
mkdir -p ./dags ./logs ./plugins ./config
docker compose up -d        # 启动 scheduler / webserver / worker / triggerer / postgres 等

Kubernetes（生产规模化）

helm repo add apache-airflow https://airflow.apache.org
helm repo update
helm install airflow apache-airflow/airflow --namespace airflow --create-namespace

Windows 部署说明

  • Airflow 官方对 Windows 原生支持有限（依赖 fcntl 等 POSIX 特性），不推荐直接在 Windows 裸机运行 Scheduler/Worker。
  • 推荐方式：WSL2（Ubuntu）+ Docker Desktop，在 Linux 子系统中按上述 Linux 流程部署，或直接使用 Docker Compose。
  • Windows 上可使用 Web 浏览器访问远端/WSL 中部署的 UI（默认 http://localhost:8080 ）。

3.2 关键操作

定义一个最简单的 DAG

# dags/example.py （放入 dags/ 目录）
from airflow.sdk import DAG, task          # 3.x 稳定命名空间
from datetime import datetime

with DAG(dag_id="my_first_dag", schedule="@daily", start_date=datetime(2026, 1, 1), catchup=False) as dag:

    @task
    def extract():
        print("extract done")
        return "data"

    @task
    def load(data: str):
        print(f"load {data}")

    load(extract())

常用 CLI

操作 命令
查看 DAG 列表 airflow dags list
手动触发 DAG airflow dags trigger <dag_id>
查看任务列表 airflow tasks list <dag_id>
测试单个任务 airflow tasks test <dag_id> <task_id> <logical_date>
补数 airflow dags backfill <dag_id> -s <start> -e <end>（3.x 由 Scheduler 管理）
查看任务日志 Web UI → DAG → Task Instance → Log

生产环境建议

  • 元数据库：使用 PostgreSQL/MySQL（勿用 SQLite），并配置备份与高可用。
  • 任务多/规模大时：选择 CeleryExecutor 或 KubernetesExecutor。
  • DAG 代码：纳入 Git 管理，通过 CI/CD 分发到所有节点（保持版本一致）。
  • 配置告警（email、slack 等 Provider）与监控（Prometheus metrics）。

Z FAQ for Airflow

Q: Airflow 与 Linux cron 有什么区别？

cron 只能按时间触发单条命令，无依赖管理、无状态监控、无重试告警；Airflow 提供 DAG 依赖编排、可视化监控、失败重试、事件驱动、跨系统集成等完整能力，适合复杂工作流。

Q: Scheduler 到点却不触发任务，常见原因有哪些？

① 元数据库连接异常或 Scheduler 未运行；② DAG 文件解析失败（语法错误/导入错误），可在 UI 查看解析状态；③ start_date 与调度时间配置不当（如 catchup=False 且 start_date 在未来）；④ 并发/池（Pool）资源占满；⑤ DAG 未启用（Paused）。

Q: Airflow 适合实时/流式任务吗？

不适合。Airflow 定位为批处理与事件驱动编排，调度粒度分钟级为主；秒级实时调度能力有限，实时流处理应使用 Flink/Spark Streaming 等专用引擎，Airflow 可负责其外围编排。

Q: Windows 上可以安装运行 Airflow 吗？

官方对 Windows 原生支持有限，不推荐在 Windows 裸机跑 Scheduler/Worker；建议使用 WSL2 或 Docker Desktop 运行，浏览器访问 UI。

Q: 与 DolphinScheduler 相比如何选型？

看团队技术栈与编排偏好：偏好代码即工作流、Python 生态、复杂动态逻辑选 Airflow；偏好可视化拖拽、大数据任务开箱即用、去中心化高可用、中文团队选 DolphinScheduler。

Q: 升级到 3.0 需要注意什么？

3.0 移除 SLAs/SubDAG/pickling 等旧特性，schedule_interval 统一为 schedule 字段，标准 Operator 迁移至 apache-airflow-providers-standard 包，导入路径从 airflow.operators.* 改为 airflow.providers.standard.operators.*；官方建议用 ruff 与 airflow config update 校验，升级需从 2.7+ 开始。

Q: 生产环境 Executor 怎么选？

单机试用用 LocalExecutor；中小规模分布式用 CeleryExecutor（需 Redis/RabbitMQ）；云原生/K8s 环境用 KubernetesExecutor（按任务弹性建 Pod）；边缘/远程执行用 3.0 Edge Executor。

Q: Dify 能用来做传统定时任务调度吗？

不建议。Dify 是 AI 应用开发平台，核心是交互/事件驱动的工作流（LLM、RAG、Agent），不具备 XXL-Job/Airflow 那样的通用定时调度与任务管理能力；传统批处理调度应选用专业调度系统。

Q: 是否可以将 Apache Airflow 作为元数据血缘管理的工具？可作为任务级/表级血缘，但不推荐（必读）

  • 结论：可以，但 Airflow 不是血缘管理的专用工具，只能做【轻量血缘】；【复杂企业级血缘】不推荐用它作为核心方案。

1. Airflow 原生能力

Airflow 本身没有内置完整的数据血缘解析引擎：

  • Airflow DAG 定义了任务之间的依赖关系（Task A → Task B），这是任务级血缘，不是【数据表/字段级】的数据血缘。
  • Airflow Metadata DB 存储：DAG、Task、运行日志、参数、执行时间。不会自动解析 SQL，识别表读写、字段映射。
  • 仅能表达：任务依赖，不能自动识别底层数据资产（Hive/ClickHouse/MySQL 表、字段）。

举例：一个 BigQueryOperator 执行 INSERT INTO table_b SELECT col1 FROM table_a，Airflow 只知道这个任务跑成功了，原生不知道 table_a → table_b 的数据血缘。

2. 怎么基于 Airflow 实现血缘（两种方式）

方式1：Operator 埋点 + 外部血缘接收器（主流方案）

Airflow 提供 Lineage API（Airflow 2.x 内置）：

from airflow.lineage.entities import Table
from airflow.lineage import prepare_lineage

@prepare_lineage
def my_sql_task(inlets, outlets):
    ...
  • inlets：上游数据资产（输入表）
  • outlets：下游数据资产（输出表）
    你手动/自动给任务绑定输入输出表，Airflow 会把血缘事件发送到后端（如 OpenLineage）。

✅ 典型组合：Airflow + OpenLineage
OpenLineage 是标准血缘规范，支持：

  • 自动解析很多 Operator（BigQuery、Snowflake、Spark、SQL 类算子）的 SQL，提取表级血缘
  • 收集 Airflow 任务上下文，把「任务依赖」和「数据读写血缘」关联起来
  • 血缘存储可以对接 Marquez、Amundsen、DataHub 等元数据平台

👉 这种模式下：Airflow 是血缘事件的采集器，不是血缘存储和查询引擎。

方式2：自己写代码解析SQL，写入Airflow元库（不推荐）

自己解析 SQL 得到表读写关系，存入 Airflow metadata DB。
缺点：维护成本极高，没有字段血缘，查询、影响分析能力弱。

3. 适用场景 & 局限

✅ 适合

  1. 调度链路和数据血缘强绑定，所有ETL都由Airflow调度
  2. 只需要表级血缘，字段级血缘非必需
  3. 已有Airflow，想低成本快速落地轻量血缘，不想立刻引入重型元数据平台

❌ 不适合（短板）

  1. 字段级血缘：Airflow+原生OpenLineage对复杂SQL（CTE、子查询、UDF）字段解析能力有限，复杂场景需要额外SQL解析器
  2. 非Airflow调度的数据作业：Spark、Flink、同步工具、手工SQL，这部分血缘Airflow完全覆盖不到，会形成血缘孤岛
  3. 元数据能力弱：没有资产目录、数据质量关联、权限、影响分析、版本管理。血缘数据只靠Airflow存很难做查询可视化。
  4. 血缘是运行时采集：只有任务执行时才上报血缘；DAG定义静态分析不能提前预先生成血缘。

4. 架构选型参考

方案 定位 血缘能力
Airflow 原生 调度器 仅任务依赖，无数据血缘
Airflow + OpenLineage + Marquez 调度+血缘采集+存储 表级血缘，部分算子支持字段血缘
DataHub / Amundsen / Atlas 元数据平台 全链路资产目录、表+字段血缘、影响分析

总结

Airflow 不能单独作为完整元数据血缘管理工具，但它是非常好的血缘采集入口；搭配 OpenLineage 可以采集调度内的数据血缘，最终血缘存储、查询、资产目录能力仍然要交给专门元数据系统。

Y 推荐文献

X 参考文献

posted @ 2026-09-16 01:25  千千寰宇  阅读(5)  评论(0)    收藏  举报