英文原文正文为项目原始 README（英文），本站后续会翻译为中文，当前仅剔除图片与无关章节并统一排版。

Apache Airflow

类别	徽章
许可证
PyPI
容器
社区
开发工具

版本	构建状态
主页面
3.x

Apache Airflow（或简称 Airflow）是一个用于以编程方式创建、调度和监控工作流的平台。

当工作流被定义为代码时，它们变得更易维护、版本化、可测试且便于协作。

使用 Airflow 编写协调任务的工作流（Dags）。Airflow 调度程序会根据指定的依赖关系在多个工作节点上执行任务。丰富的命令行工具使对 Dags 执行复杂操作变得轻而易举。丰富的用户界面使您能够轻松可视化生产中运行的管道、监控进度，并在需要时排查问题。

目录

• 项目重点
• 原则
• 要求
• 入门
• 从 PyPI 安装
• 安装
• 官方源码
• 便利包
• 用户界面
• 语义化版本
• 版本生命周期
• 对 Python 和 Kubernetes 版本的支持
• 参考 Airflow 镜像的基础操作系统支持
• Airflow 依赖项的处理方式
• 贡献
• 社区标准
• 代理辅助贡献（apache-magpie）
• 投票政策
• 谁在使用 Apache Airflow？
• 谁维护 Apache Airflow？
• 下一个版本包含哪些内容？
• 我可以在演示文稿中使用 Apache Airflow 的标志吗？
• 链接
• 赞助商

项目重点

Airflow 在大多数静态且变化缓慢的工作流中表现最佳。当每次运行的 DAG 结构相似时，它可以明确工作单元和连续性。其他类似项目包括 Luigi、Oozie 和 Azkaban。

除了传统的数据管道之外，Airflow 还被广泛用于编排机器学习工作流——训练、再训练、评估和部署——并且越来越多地用于编排智能和基于大型语言模型（LLM）的工作负载，协调 AI 管道的步骤（数据准备、工具调用、模型调用、评估），而不是作为代理本身。这并不是一个新方向：团队多年来一直在 Airflow 上运行机器学习和 AI 工作负载，支持这些用例的提供商生态系统（参见 Airflow 注册表的 AI & ML 部分）持续增长。

Airflow 通常用于处理数据，但其观点是任务理想情况下应具有幂等性（即任务的结果将相同，不会在目标系统中创建重复数据），并且不应将大量数据从一个任务传递到下一个任务（尽管任务可以使用 Airflow 的 XCom 功能 传递元数据）。对于高容量、数据密集型任务，一个最佳实践是委托给专门处理此类工作的外部服务。

Airflow 不是流式解决方案，但它经常用于处理实时数据，以批处理的方式从流中提取数据。

原则

• 动态：流水线在代码中定义，实现动态 DAG 生成和参数化。
• 可扩展：Airflow 框架包含广泛的内置操作符，并且可以扩展以满足您的需求。
• 灵活：Airflow 利用 Jinja 模板引擎，支持丰富的自定义。

要求

Apache Airflow 已测试于：

	主版本（开发版）	稳定版本（3.3.2）	弃用版本（2.11.2）
Python	3.11, 3.12, 3.13, 3.14	3.10, 3.11, 3.12, 3.13, 3.14	3.10, 3.11, 3.12
平台	AMD64/ARM64	AMD64/ARM64	AMD64/ARM64(*)
Kubernetes	1.31, 1.32, 1.33, 1.34, 1.35, 1.36, 1.37	1.30, 1.31, 1.32, 1.33, 1.34, 1.35	1.26, 1.27, 1.28, 1.29, 1.30
PostgreSQL	14, 15, 16, 17, 18	14, 15, 16, 17, 18	12, 13, 14, 15, 16
MySQL	8.0, 8.4, 创新	8.0, 8.4, 创新	8.0, 创新
SQLite	3.15.0	3.15.0	3.15.0

• 实验性

注意：MariaDB 未经过测试/不推荐使用。

注意：SQLite 在 Airflow 测试中使用。请勿在生产环境中使用。我们建议在本地开发中使用最新稳定版本的 SQLite。

注意：Airflow 目前可以在符合 POSIX 标准的操作系统上运行。对于开发，它定期在相当现代的 Linux 发行版和近期 macOS 版本上进行测试。在 Windows 上，你可以通过 WSL2（Windows 子系统 Linux 2）或通过 Linux 容器运行。添加 Windows 支持的工作在 #10388 中跟踪，但这不是优先事项。你应当仅使用基于 Linux 的发行版作为“生产”执行环境，因为这是唯一支持的环境。在我们的 CI 测试中使用的唯一发行版，以及在 社区管理的 DockerHub 镜像 中使用的，都是 Debian Bookworm。

入门

请访问官方 Airflow 网站文档（最新 稳定 版本）获取有关安装 Airflow、入门指南或更完整教程的帮助。

注意：如果您正在查找主分支（最新开发分支）的文档：可以在 s.apache.org/airflow-docs 找到它。

有关 Airflow 改进提案 (AIPs) 的更多信息，请访问 Airflow Wiki。

有关依赖项目的文档，如提供者发行版、Docker 镜像、Helm Chart，您可以在文档索引中找到。

从 PyPI 安装

我们在 PyPI 上将 Apache Airflow 以 apache-airflow 包的形式发布。然而安装它有时可能比较棘手，因为 Airflow 既是库又是应用程序。库通常保持其依赖项开放，而应用程序通常会固定它们，但我们既不应该完全开放也不应该完全固定，而是同时这样做。我们决定尽可能保持依赖项开放（在 pyproject.toml 中），以便用户在需要时可以安装不同版本的库。这意味着 pip install apache-airflow 有时可能无法工作，或者会产生不可用的 Airflow 安装。

为了实现可重复的安装，我们在孤立的 constraints-main 和 constraints-2-0 分支中保留了一组“已知可用”的约束文件。我们根据主要/次要 Python 版本分别存储这些“已知可用”的约束文件。您可以在从 PyPI 安装 Airflow 时将它们作为约束文件使用。请注意，您必须在 URL 中指定正确的 Airflow 标签/版本/分支和 Python 版本。

1. 仅安装 Airflow：

注意：目前官方仅支持 pip 和 uv 的安装。

虽然可以使用像 Poetry 或 pip-tools 这样的工具安装 Airflow，但它们的工作流程与 pip 不同——尤其是在约束文件与依赖管理方面。目前不支持通过 Poetry 或 pip-tools 安装。

如果您希望使用这些工具安装 Airflow，应该使用约束文件，并将其转换为您的工具所需的适当格式和工作流程。

pip install 'apache-airflow==3.3.2' \
 --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.3.2/constraints-3.10.txt"

2. 安装时包含额外组件（例如，postgres、google）

pip install 'apache-airflow[postgres,google]==3.3.2' \
 --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.3.2/constraints-3.10.txt"

有关安装提供程序分发的信息，请查看 providers。

安装

有关设置本地开发环境和安装 Apache Airflow 的详细说明，请参阅 INSTALLING.md 文件。

官方源代码

Apache Airflow 是一个 Apache 软件基金会 (ASF) 项目，我们的官方源码发布：

• 遵循 ASF 发布政策
• 可以从 ASF 分发目录 下载
• 由发布经理进行加密签名
• 在 发布批准流程 中由 PMC 成员正式投票

按照 ASF 规则，发布的源码包必须足够让用户在拥有适当平台和工具的情况下构建和测试该发布版本。

便捷包

还有其他安装和使用 Airflow 的方式。这些是“便捷”方法——它们不是由 ASF Release Policy 所规定的“官方发布”，但可以供不想自己构建软件的用户使用。

这些方法是按人们安装 Airflow 的最常见方式排序的：

• PyPI 发布 使用标准 pip 工具安装 Airflow
• Docker 镜像 通过 docker 工具安装 Airflow，可在 Kubernetes、Helm Charts、docker-compose、docker swarm 等中使用。你可以在 最新文档 中了解使用、自定义和扩展镜像的更多内容，并在 镜像 文档中学习内部细节。
• GitHub 标签 用于通过 git 检索用于生成官方源代码包的 git 项目源代码

所有这些制品都不是官方发布，但它们是使用已正式发布的源代码准备的。其中一些制品是“开发版”或“预发布”版本，并且根据 ASF 政策明确标注了这一点。

用户界面

• Dags：查看您环境中所有Dags的概览。

• Assets：查看具有依赖关系的资产概览。

• Grid：跨时间范围显示Dag的网格表示。

• Graph：可视化Dag的依赖关系及其在特定运行中的当前状态。

• Home：显示您的Airflow环境的概述统计信息。

• Backfill：为特定日期范围回填Dag。

• Code：快速查看Dag的源代码。

语义化版本控制

从 Airflow 2.0.0 开始，我们对所有发布的包支持严格的 SemVer 方法。

我们达成了一些特定规则，用于定义不同包的版本管理细节：

• Airflow：SemVer 规则仅适用于核心 Airflow（不包括对提供者的任何更改）。仅修改 Airflow 依赖版本的限制本身不构成破坏性更改。
• Airflow 提供者：SemVer 规则仅适用于特定提供者代码的更改。包的 SemVer 主版本（MAJOR）和次版本（MINOR）独立于 Airflow 版本。例如，google 4.1.0 和 amazon 3.1.1 提供者可以与 Airflow 2.1.2 一起安装。如果提供者与 Airflow 包之间存在跨依赖限制，则这些限制会出现在提供者的 install_requires 中。我们的目标是保持提供者与所有之前发布的 Airflow 2 版本的向后兼容性，但有时会有破坏性更改可能导致某些或所有提供者指定最低 Airflow 版本。
• Airflow Helm 图表：SemVer 规则仅适用于图表的更改。图表的 SemVer 主版本（MAJOR）和次版本（MINOR）独立于 Airflow 版本。我们的目标是保持 Helm 图表与所有已发布的 Airflow 2 版本的向后兼容性，但某些新功能可能仅在特定 Airflow 版本开始可用。我们可能会限制 Helm 图表依赖最低 Airflow 版本。
• Airflow API 客户端：它们的版本独立于 Airflow 版本。它们遵循自己的 SemVer 规则，处理破坏性更改和新功能，例如，允许更改客户端生成方式。

版本生命周期

Apache Airflow 版本生命周期：

版本	当前补丁/次要版本	状态	首次发布	有限维护	已结束/终止
3	3.3.2	维护	2025年4月22日	待定	待定
2	2.11.2	终止	2020年12月17日	2025年10月22日	2026年4月22日
1.10	1.10.15	终止	2018年8月27日	2020年12月17日	2021年6月17日
1.9	1.9.0	终止	2018年1月3日	2018年8月27日	2018年8月27日
1.8	1.8.2	终止	2017年3月19日	2018年1月3日	2018年1月3日
1.7	1.7.1.2	终止	2016年3月28日	2017年3月19日	2017年3月19日

仅限支持版本将仅获得安全性和关键错误修复。已结束生命周期（EOL）的版本将不会获得任何修复或支持。我们始终建议所有用户运行其所用主版本的最新小版本。我们强烈建议在方便的最早时间且在EOL日期之前升级到最新的Airflow主版本。

对 Python 和 Kubernetes 版本的支持

从Airflow 2.0开始，我们同意遵循某些关于Python和Kubernetes支持的规则。它们基于Python和Kubernetes的官方发布计划，已经在Python开发者指南和Kubernetes版本偏差策略中很好地总结。

1. 当Python和Kubernetes版本达到EOL时，我们将停止支持。除Kubernetes外，如果两个主要云提供商仍提供支持，则Airflow仍支持该版本。对于这些EOL版本，我们会在EOL日期之后立即在主分支中停止支持，并且在我们发布Airflow的第一个新小版本（如果没有新小版本则为主版本）时，实际上它们会被移除。例如，对于Python 3.10，这意味着我们将在2023年6月27日之后立即在主分支中停止支持，之后发布的第一个Airflow主版本或小版本将不再包含它。

2. 在新的Python/Kubernetes版本官方发布后，只要我们能够在CI管道中使其正常工作（由于依赖项追赶新的Python版本可能不会立即实现），我们就会在主分支中支持它并发布新的镜像/支持于Airflow中。

3. 该政策为尽力而为，这意味着在某些情况下，如果情况需要，我们可能会提前终止支持。

参考 Airflow 镜像的基础操作系统支持

Airflow社区提供了方便打包的容器镜像，这些镜像在每次发布Apache Airflow版本时都会发布。镜像包含以下内容：

• 安装Airflow所需的软件包的基础操作系统（稳定的Debian OS）
• 在发布Airflow小版本时支持的基础Python安装（因此例如2.3和2.2系列可能有不同的版本）
• 连接支持的数据库所需的库（同样，支持的数据库集取决于Airflow的小版本）
• 预定义的一组流行提供者（详情见Dockerfile）
• 可以构建自定义镜像，用户可以选择自己的提供者和库集（见构建镜像）
• 未来Airflow也可能支持一个“精简”版本，不安装提供者或数据库客户端

基础操作系统镜像的版本是 Debian 的稳定版本。Airflow 支持使用所有当前活跃的稳定版本——只要所有 Airflow 依赖项支持构建，并且我们建立了构建和测试操作系统版本的 CI 流水线。在上一稳定版本操作系统的常规支持结束前大约 6 个月，Airflow 会将发布的镜像切换为使用最新支持的操作系统版本。

例如，从 Debian Bullseye 切换到 Debian Bookworm 已在 2023 年 10 月 2.8.0 版本发布前实现，并且从 Airflow 2.10.0 开始，Debian Bookworm 将是唯一支持的选项。

用户仍然可以继续使用稳定的 Debian 版本构建他们的镜像，直到常规支持结束，而镜像的构建和验证会在我们的 CI 中进行，但在 main 分支中不会使用该镜像执行任何单元测试。

Airflow 依赖的处理方式

Airflow 有很多依赖项——直接依赖和传递依赖，同时 Airflow 既是库也是应用程序，因此我们对依赖项的策略必须包括两方面——应用程序安装的稳定性，以及为那些开发 DAG 的用户安装更新版本依赖项的能力。我们开发了一种方法，使用 constraints 来确保 Airflow 可以以可重复的方式安装，同时不限制用户升级大多数依赖项。因此，我们决定默认不对 Airflow 依赖项设定上限版本，除非我们有充分理由认为，由于依赖项的重要性以及升级特定依赖项的风险，需要设定上限版本。我们也会对已知会引发问题的依赖项设定上限。

我们的约束机制会自动处理查找和升级所有没有上限的依赖项（前提是所有测试通过）。在 main 构建失败时，如果有依赖项版本破坏了我们的测试，将提示我们要么为其设定上限，要么修正我们的代码/测试以适应这些依赖项的上游变化。

每当我们为某个依赖项设定上限时，都应评论说明理由——即我们应有充分理由说明为什么要设定上限版本。我们还应备注移除该绑定的条件。

Airflow Core 的依赖项处理方法

这些依赖项维护在 pyproject.toml 中。

有一些依赖项被认为重要到足以默认设定上限版本，因为它们遵循可预测的版本规则，并且我们知道它们的新版本很可能带来破坏性更改。我们承诺定期审查并尝试升级这些依赖项的新版本，但这是手动过程。

重要的依赖项包括：

• SQLAlchemy：限制到特定的次版本上限（已知 SQLAlchemy 会移除弃用功能并引入破坏性更改，尤其是因为对不同数据库的支持各不相同并且变化速度也不同）
• Alembic：以可预测且高性能的方式处理迁移非常重要。它是与 SQLAlchemy 一起开发的。我们的经验是 Alembic 在次版本中非常稳定
• Flask：我们使用 Flask 作为我们的 Web UI 和 API 的骨干。我们知道 Flask 的主版本很可能引入破坏性更改，因此将其限制在主版本上是合理的
• werkzeug：该库在新版本中已知会导致问题。它与 Flask 库紧密耦合，因此应一起更新
• celery：Celery 是 Airflow 的关键组件，因为它用于 CeleryExecutor（及类似功能）。Celery 遵循 SemVer，所以我们应将其上限限制到下一个主版本。此外，当我们提升库的上限版本时，应确保更新 Celery Provider 的最低 Airflow 版本
• kubernetes：Kubernetes 是 Airflow 的关键组件，因为它用于 KubernetesExecutor（及类似功能）。Kubernetes Python 库 遵循 SemVer，所以我们应将其上限限制到下一个主版本。此外，当我们提升库的上限版本时，应确保更新 Kubernetes Provider 的最低 Airflow 版本

Airflow Provider 和额外依赖的处理方法

Airflow 的主要部分是 Airflow Core，但 Airflow 的强大能力也来自多个扩展核心功能并单独发布的提供者，即使出于方便，我们暂时将它们保存在同一个 monorepo 中。你可以在 Providers documentation 了解更多提供者信息。我们还在 providers 文档中实施了一套维护和发布社区管理提供者的策略，并说明了社区提供者与第三方提供者的处理方法

这些 extras 和 providers 依赖在每个提供者的 provider.yaml 中进行维护

默认情况下，我们不应对提供者的依赖限制上限，但每个提供者的维护者可以决定添加额外限制（并用注释说明理由）

贡献

想帮助构建 Apache Airflow 吗？查看我们的 贡献者指南，了解如何贡献的全面概述，包括设置说明、编码标准和拉取请求指南。

如果你迫不及待想要贡献，并希望尽快开始，请查看这里的 贡献快速入门！

Apache Airflow 的官方 Docker（容器）镜像在 images 中有描述。

社区标准

所有与 Apache Airflow 项目互动的人——无论是在 GitHub、邮件列表、Slack、CWiki 还是其他地方——都应遵守 行为准则。

当反复违反行为准则、发送垃圾信息、滥用项目资源或其他持续破坏性行为无法通过正常的审查和指导解决时，项目将应用 社区升级流程。该流程描述了维护者和 PMC 可能采取的步骤——从直接反馈、关闭 PR，到 PMC 级或 ASF 基础设施级的封禁和向 GitHub 报告账户——以及受影响的贡献者如何通过发送电子邮件至 private@airflow.apache.org 向 PMC 提出申诉。

代理辅助贡献（apache-magpie）

该仓库使用从插件市场安装的 apache/magpie 框架。该框架提供面向维护者的 PR 管理技能（pr-management-triage、pr-management-code-review、pr-management-stats、pr-management-mentor），这些技能在 Claude Code 等代理框架中作为代理技能暴露。

与框架相关的内容未提交到此仓库，新的克隆不需要任何设置步骤——该插件在你自己的代理框架中按用户安装。在 Claude Code 中：

/plugin marketplace add apache/magpie
/plugin install magpie-pr-management@apache-magpie

请安装 magpie@apache-magpie 来一次性获取所有技能系列，或者一次添加其他系列（magpie-security、magpie-release-management 等）。通过从标签添加市场插件来固定某个版本，而不是跟踪 main：/plugin marketplace add apache/magpie@0.2.0。

项目推荐的集合记录在 .apache-magpie.lock 中，包括 release-management 系列，该系列允许代理验证候选发布版本——包括一个可选检查，它会将你自己的更改与 Breeze 中安装的 providers wave 进行运行比对：

/plugin install magpie-release-management@apache-magpie

其他工具链 — Codex CLI、Gemini CLI、Copilot、Cursor — 已在框架的市场指南中说明。

针对 Airflow 的框架工作流修改位于.apache-magpie-overrides/（已提交）——已安装的插件在运行时读取它们，因此它们适用于每个贡献者，无需任何人编辑框架。框架的更改通过 PR 提交到apache/magpie。

投票政策

• 提交需要由非作者的提交者投一票
• 当我们进行 AIP 投票时，PMC 成员和提交者的 +1s 都被视为有效投票。

谁在使用 Apache Airflow？

我们知道大约有500个组织在使用Apache Airflow（但实际上可能有更多）实际使用情况。

如果你使用Airflow - 欢迎提交PR将你的组织添加到列表中。

Who maintains Apache Airflow?

Airflow 是由社区完成的工作，但核心提交者/维护者负责审查和合并 PR，以及引导有关新功能请求的讨论。如果您想成为维护者，请查看 Apache Airflow 的提交者要求。

下一个版本包含哪些内容？

你经常会看到一个问题被分配到具体的 Airflow 版本里，或者一个 PR 被合并到主分支，你可能会想，合并的 PR 会在哪个版本发布，或者修复的问题会在哪个版本中。对此的答案一如既往——取决于各种情况。PR 和问题的答案是不同的。

为了增加一点背景，我们遵循 Semver 版本控制方案，如 Airflow 发布流程 中描述的那样。更多细节在此 README 的 语义版本控制 章节中有详细说明，但简而言之，我们有 Airflow 的 MAJOR.MINOR.PATCH 版本。

• 当发生破坏性变更时，MAJOR 版本会递增。
• 当新增功能时，MINOR 版本会递增。
• 当仅有 bug 修复和文档更改时，PATCH 版本会递增。

通常我们会从以 MINOR 版本命名的分支发布 Airflow 的 MINOR 版本。例如，2.7.* 版本是从 v2-7-stable 分支发布的，2.8.* 版本从 v2-8-stable 分支发布，依此类推。

1. 在我们的发布周期中，大多数情况下，当下一个 MINOR 分支还未创建时，所有合并到 main 的 PR（除非被回滚），都会进入下一个 MINOR 版本。例如，如果最后发布的是 2.7.3 并且 v2-8-stable 分支尚未创建，那么下一个 MINOR 版本是 2.8.0，所有合并到 main 的 PR 都会在 2.8.0 发布。然而，一些 PR（仅修复 bug 和文档更改）在合并时，可以被挑选（cherry-pick）到当前 MINOR 分支，并在下一个 PATCHLEVEL 版本中发布。例如，如果 2.8.1 已经发布，而我们正在开发 2.9.0dev，那么将某个 PR 标记为 2.8.2 里程碑意味着它会被挑选到 v2-8-test 分支，并发布在 2.8.2rc1，最终发布在 2.8.2。

2. 当我们准备下一个 MINOR 版本发布时，会创建新的 v2-*-test 和 v2-*-stable 分支，并为下一个 MINOR 版本准备 alpha、beta 版本，合并到 main 的 PR 仍然会发布在下一个 MINOR 版本中，直到 rc 版本被切出。这是因为在准备下一个 beta 和 rc 版本时，v2-*-test 和 v2-*-stable 分支会基于 main 做 rebase。例如，当我们切出 2.10.0beta1 版本时，在 2.10.0rc1 发布前合并到 main 的任何内容，都会进入 2.10.0rc1。

3. 然后，一旦我们为 MINOR 版本准备好第一个 RC 候选版本，我们就停止移动 v2-*-test 和 v2-*-stable 分支，并且合并到 main 的 PR 将在下一个 MINOR 版本中发布。然而，一些 PR（修复 bug 和仅文档更改）在合并后，可以被挑选到当前的 MINOR 分支并在下一个 PATCHLEVEL 版本中发布——例如，当 v2-10-stable 分支的最新发布版本是 2.10.0rc1 时，部分来自 main 的 PR 可以由提交者标记为 2.10.0 里程碑，发布经理会尝试将它们挑选到发布分支。如果成功，它们将在 2.10.0rc2 中发布，随后在 2.10.0 中发布。这也适用于后续的 PATCHLEVEL 版本。例如，当 2.10.1 已经发布时，将 PR 标记为 2.10.2 里程碑意味着它将被挑选到 v2-10-stable 分支，并在 2.10.2rc1 中发布，最终在 2.10.2 中发布。

关于挑拣的最终决定由发布经理做出。

为问题标记里程碑稍有不同。维护者通常不在问题上标记里程碑，通常只会在 PR 上标记。如果与问题相关联（并“修复”问题）的 PR 被合并并按照上述流程发布在特定版本中，问题将自动关闭，不会为问题设置里程碑，你需要检查修复该问题的 PR 看它发布在哪个版本中。

然而，有时维护者会为问题标记特定里程碑，这意味着该问题在准备版本时被认为是一个重要的候选问题。由于这是一个开源项目，基本上所有贡献者都是自愿贡献时间，因此不能保证特定问题会在特定版本中修复。我们不想因为某个问题未修复而延迟发布，因此在这种情况下，如果问题未在当前发布版本中修复，发布经理会将这些未解决的问题重新分配到下一个里程碑。因此，问题的里程碑更多的是表示应当关注，而不是承诺它会在该版本中被修复。

关于补丁版本发布的更多背景信息和 常见问题 可以在仓库 dev 文件夹中的 What goes into the next release 文档中找到。

我可以在演示中使用 Apache Airflow 标志吗？

是的！请确保遵守 Apache 基金会的 商标政策 和 Apache Airflow 品牌手册。最新的 logo 可以在 此仓库 和 Apache Software Foundation 官网 找到。

链接

• 文档
• 聊天
• 社区信息