Apache Airflow

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

当工作流被定义为代码时，它们变得更容易维护、版本控制、测试和协作。

使用 Airflow 将工作流编写为任务的有向无环图（DAG）。Airflow 调度器在遵循指定依赖关系的同时，在一系列工作节点上执行您的任务。丰富的命令行工具使得对 DAG 进行复杂操作变得轻而易举。直观的用户界面使得可视化生产中运行的管道、监控进度以及在需要时排除故障变得容易。

项目焦点
原则
要求
入门
从 PyPI 安装
官方源代码
便利包
用户界面
语义版本控制
版本生命周期
对 Python 和 Kubernetes 版本的支持
参考 Airflow 镜像的基础操作系统支持
Airflow 依赖项的处理方法
贡献
投票政策
谁在使用 Apache Airflow？
谁在维护 Apache Airflow？
下一个版本会包含什么？
我可以在演示中使用 Apache Airflow 的标志吗？
链接
赞助商

项目焦点

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

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

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

原则

动态: Airflow 管道以代码(Python)形式配置,允许动态生成管道。这使得可以编写代码动态实例化管道。
可扩展: 可以轻松定义自己的操作符、执行器并扩展库,使其适合你环境所需的抽象级别。
优雅: Airflow 管道精简且明确。使用强大的 Jinja 模板引擎将脚本参数化已内置到 Airflow 的核心中。
可扩展: Airflow 具有模块化架构,使用消息队列来协调任意数量的工作节点。

要求

Apache Airflow 经过以下测试:

	主版本(开发版)	稳定版本(2.9.3)
Python	3.8, 3.9, 3.10, 3.11, 3.12	3.8, 3.9, 3.10, 3.11, 3.12
平台	AMD64/ARM64(*)	AMD64/ARM64(*)
Kubernetes	1.27, 1.28, 1.29, 1.30	1.26, 1.27, 1.28, 1.29
PostgreSQL	12, 13, 14, 15, 16	12, 13, 14, 15, 16
MySQL	8.0, 8.4, Innovation	8.0, Innovation
SQLite	3.15.0+	3.15.0+

实验性

注意: MySQL 5.x 版本无法运行多个调度器或存在限制 - 请参阅调度器文档。不推荐使用 MariaDB。

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

注意: Airflow 目前可以在符合 POSIX 标准的操作系统上运行。对于开发,它定期在相当现代的 Linux 发行版和最新版本的 macOS 上进行测试。在 Windows 上,你可以通过 WSL2(Windows Subsystem for Linux 2)或 Linux 容器运行它。添加 Windows 支持的工作通过 #10388 进行跟踪,但不是高优先级。你应该只使用基于 Linux 的发行版作为"生产"执行环境,因为这是唯一受支持的环境。我们的 CI 测试中使用的唯一发行版,也是社区管理的 DockerHub 镜像中使用的是 Debian Bookworm。我们还支持传统的 Debian Bullseye 基础镜像,如果你想构建自定义镜像,但它已被弃用,并且在随 Airflow 2.9.3 一起提供的 Dockerfile 中将删除该选项,因此建议你为自定义镜像切换到 Debian Bookworm。

入门

访问官方 Airflow 网站文档(最新稳定版本)以获取有关安装 Airflow、入门或完成更完整教程的帮助。

注意:如果你正在寻找主分支(最新开发分支)的文档:你可以在 s.apache.org/airflow-docs 找到它。

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

对于提供程序包、Docker 镜像、Helm Chart 等相关项目的文档,你可以在文档索引中找到。

从 PyPI 安装

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

然而,为了实现可重复安装,我们在孤立的 constraints-main 和 constraints-2-0 分支中保留了一组"已知可用"的约束文件。我们为每个主要/次要 Python 版本单独保留这些"已知可用"的约束文件。从 PyPI 安装 Airflow 时,可以将它们用作约束文件。请注意,你必须在 URL 中指定正确的 Airflow 标签/版本/分支和 Python 版本。

仅安装 Airflow:

注意:目前仅官方支持 pip 安装。

虽然可以使用 Poetry 或 pip-tools 等工具安装 Airflow,但它们与 pip 的工作流程不同 - 尤其是在约束与需求管理方面。目前不支持通过 Poetry 或 pip-tools 安装。

使用 bazel 安装 Airflow 时存在已知问题,可能会导致循环依赖。如果遇到此类问题,请切换到 pip。Bazel 社区正在 这个 PR <https://github.com/bazelbuild/rules_python/pull/1166>_ 中修复这个问题,因此较新版本的 bazel 可能会处理这个问题。

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

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

安装附加功能(例如,postgres,google)

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

有关安装提供程序包的信息,请查看 providers。

官方源代码

Apache Airflow 是 Apache 软件基金会 (ASF) 的项目,我们的官方源代码发布:

遵循 ASF 发布政策
可以从 ASF 分发目录下载
由发布经理进行加密签名
在发布审批流程期间由 PMC 成员正式投票根据ASF规则，发布的源码包必须足以让用户在获得适当平台和工具的情况下构建和测试该版本。

便利包

还有其他安装和使用Airflow的方法。这些是"便利"方法 - 它们不是ASF发布政策所述的"官方发布"，但可以被不想自己构建软件的用户使用。

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

使用标准pip工具从PyPI安装Airflow
使用docker工具通过Docker镜像安装Airflow，在Kubernetes、Helm Charts、docker-compose、docker swarm等中使用。你可以在最新文档中了解更多关于使用、定制和扩展镜像的信息，并在images文档中了解内部细节。
从GitHub标签获取用于生成官方源码包的git项目源码

所有这些制品都不是官方发布，但它们是使用官方发布的源码准备的。其中一些制品是"开发"或"预发布"版本，并按照ASF政策明确标记。

用户界面

DAGs：环境中所有DAG的概览。
网格：跨时间的DAG网格表示。
图表：特定运行的DAG依赖关系及其当前状态的可视化。
任务持续时间：不同任务随时间花费的总时间。
甘特图：DAG的持续时间和重叠。
代码：查看DAG源码的快速方式。

语义化版本

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

我们同意了一些特定规则，定义了不同包版本控制的细节：

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

版本生命周期

Apache Airflow版本生命周期：

（表格内容略）

有限支持版本将只获得安全和关键错误修复支持。 EOL版本将不会获得任何修复或支持。我们始终建议所有用户运行所使用的任何主版本的最新可用次要版本。我们强烈建议在最方便的时间和EOL日期之前升级到最新的Airflow主版本。

对Python和Kubernetes版本的支持

从Airflow 2.0开始，我们同意了某些规则，用于Python和Kubernetes支持。这些规则基于Python和Kubernetes的官方发布计划，在Python开发者指南和Kubernetes版本偏差政策中有很好的总结。

当Python和Kubernetes版本达到EOL时，我们会停止对它们的支持。对于Kubernetes，如果两个主要云提供商仍然支持某个版本，Airflow就会继续支持它。我们在EOL日期后立即在主分支中停止对这些EOL版本的支持，并在发布Airflow的第一个新的次要版本（或者如果没有新的次要版本，则在主要版本）时有效移除。例如，对于Python 3.8，这意味着我们将在2023年6月27日之后立即在主分支中停止支持，之后发布的第一个Airflow主要或次要版本将不会包含它。
我们在Python/Kubernetes官方发布后，会在主分支中支持新版本。一旦我们使其在CI管道中正常运行（由于依赖项需要时间来适应新版本的Python，这可能不会立即实现），我们就会基于可正常运行的CI设置发布新的镜像/支持。
这项政策是尽力而为的，这意味着在某些情况下，如果环境需要，我们可能会提前终止支持。

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

Airflow社区提供了方便打包的容器镜像，这些镜像在发布Apache Airflow版本时同步发布。这些镜像包含：

安装Airflow所需的基础操作系统和必要软件包（稳定的Debian操作系统）
在发布时支持的Airflow MINOR版本的基础Python安装（例如，2.3和2.2系列可能有不同的版本）
连接支持数据库所需的库（支持的数据库集合取决于Airflow的MINOR版本）
预定义的一组常用providers（详情请参见Dockerfile）
可以构建自定义镜像，用户可以选择自己的providers和库集合（参见构建镜像）
未来Airflow可能还会支持不包含providers和数据库客户端的"精简"版本

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

例如，由于Debian Buster的生命周期在2022年8月结束，Airflow在2022年2月/3月将main分支中的镜像切换为使用Debian Bullseye。这个版本在切换后的下一个MINOR版本中使用。对于Bullseye切换，2.3.0版本使用了Debian Bullseye。前一个MINOR版本发布的镜像继续使用该MINOR版本的所有其他发布所使用的版本。类似地，从Debian Bullseye到Debian Bookworm的切换在2023年10月的2.8.0版本发布之前实施，并且从Airflow 2.9.0开始，Debian Bookworm将成为唯一支持的选项。

用户将能够继续使用稳定的Debian发行版构建他们的镜像，直到常规支持结束，并且在我们的CI中进行镜像的构建和验证，但在main分支中不会使用这个镜像执行单元测试。

Airflow依赖项的处理方法

Airflow有许多直接和间接的依赖项，而且Airflow既是库又是应用程序，因此我们的依赖项政策必须同时考虑应用程序安装的稳定性和为开发DAG的用户提供升级依赖项的能力。我们开发了一种使用约束的方法，确保Airflow可以以可重复的方式安装，同时不限制用户升级大多数依赖项。因此，我们决定默认不对Airflow依赖项设置上限版本，除非我们有充分理由认为由于依赖项的重要性以及升级特定依赖项的风险，需要设置上限。我们也会对已知会造成问题的依赖项设置上限。

我们的约束机制会自动查找和升级所有没有设置上限的依赖项（前提是所有测试都通过）。如果有依赖项的版本导致我们的测试失败，我们的main构建会失败，这表明我们应该为它们设置上限或者修改我们的代码/测试以适应这些依赖项的上游变化。

每当我们为依赖项设置上限时，我们都应该解释这样做的原因——也就是说，我们应该有充分的理由来设置上限。我们还应该提及移除该限制的条件。

Airflow核心依赖项的处理方法

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

有几个依赖项我们认为足够重要，需要默认设置上限版本，因为它们遵循可预测的版本控制方案，并且我们知道这些依赖项的新版本很可能带来重大变化。我们承诺定期审查并尝试升级到这些依赖项的新版本，但这是一个手动过程。

重要的依赖项包括：

SQLAlchemy：限制到特定的MINOR版本（SQLAlchemy已知会移除废弃功能并引入重大变化，特别是对不同数据库的支持会以不同速度变化和改变）
Alembic：以可预测和高效的方式处理我们的迁移很重要。它与SQLAlchemy一起开发。我们的经验表明，Alembic在MINOR版本中非常稳定
Flask：我们使用Flask作为Web UI和API的骨干。我们知道Flask的主要版本很可能在这些版本之间引入重大变化，所以将其限制在MAJOR版本内是有意义的
werkzeug：这个库在新版本中已知会引起问题。它与Flask库紧密耦合，我们应该一起更新它们
celery：Celery是Airflow的一个关键组件，因为它用于CeleryExecutor（及类似执行器）。Celery遵循SemVer，所以我们应该将其上限设置为下一个MAJOR版本。此外，当我们提高库的上限版本时，应确保更新Celery Provider的最低Airflow版本要求
kubernetes：Kubernetes是Airflow的一个关键组件，因为它用于KubernetesExecutor（及类似执行器）。Kubernetes Python库遵循SemVer，所以我们应该将其上限设置为下一个MAJOR版本。此外，当我们提高库的上限版本时，应确保更新Kubernetes Provider的最低Airflow版本要求

Airflow Providers和extras依赖项的处理方法

Airflow的主要部分是Airflow Core，但Airflow的强大功能还来自于许多扩展核心功能的providers，这些providers单独发布，即使为了方便，我们目前将它们保存在同一个monorepo中。你可以在Providers文档中阅读更多关于providers的信息。我们还在providers文档中实施了一系列政策，用于维护和发布社区管理的providers，以及处理社区vs第三方providers的方法。

这些extras和providers依赖项在每个provider的provider.yaml中维护。

默认情况下，我们不应该为providers设置依赖项的上限版本，但每个provider的维护者可以决定添加额外的限制（并用注释解释原因）。

贡献

想要帮助构建Apache Airflow吗？查看我们的贡献文档。

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

投票政策

提交需要一个非作者提交者的+1票
当我们进行AIP投票时，PMC成员和提交者的+1都被视为有约束力的投票。

谁在使用Apache Airflow？

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

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

谁在维护Apache Airflow？

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

下一个版本会包含什么？

通常您会看到一个问题被分配到特定的里程碑和Airflow版本，或者一个PR被合并到主分支，您可能会想知道这些合并的PR会在哪个版本发布，或者修复的问题会在哪个版本中。这个问题的答案通常是 - 取决于各种情况。PR和问题的答案是不同的。

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

MAJOR版本在有重大变更时递增
MINOR版本在添加新功能时递增
PATCH版本在只有bug修复和文档变更时递增

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

在我们的发布周期中，大多数时候，当下一个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里程碑意味着它将被cherry-pick到v2-8-test分支，并在2.8.2rc1中发布，最终在2.8.2中发布。
当我们准备下一个MINOR版本时，我们会切出新的v2--test和v2--stable分支，并准备下一个MINOR版本的alpha、beta版本，合并到main的PR仍然会在下一个MINOR版本中发布，直到rc版本被切出。这是因为在准备下一个beta和rc版本时，v2--test和v2--stable分支会在main的基础上重新基准。例如，当我们切出2.10.0beta1版本时，在2.10.0rc1发布之前合并到main的任何内容都会进入2.10.0rc1。
然后，一旦我们准备了MINOR版本的第一个RC候选版本，我们就停止移动v2--test和v2--stable分支，合并到main的PR将在下一个MINOR版本中发布。然而，一些PR（bug修复和仅文档变更）在合并后，可以被cherry-pick到当前的MINOR分支，并在下一个PATCHLEVEL版本中发布 - 例如，当v2-10-stable分支的最后发布版本是2.10.0rc1时，一些来自main的PR可以被提交者标记为2.10.0里程碑，发布经理将尝试将它们cherry-pick到发布分支。如果成功，它们将在2.10.0rc2中发布，随后在2.10.0中发布。这也适用于后续的PATCHLEVEL版本。例如，当2.10.1已经发布时，将PR标记为2.10.2里程碑意味着它将被cherry-pick到v2-10-stable分支，并在2.10.2rc1中发布，最终在2.10.2中发布。

关于cherry-picking的最终决定由发布经理做出。

用里程碑标记问题有点不同。维护者通常不会用里程碑标记问题，通常只在PR中标记。如果链接到问题（并"修复它"）的PR按照上述过程被合并并在特定版本中发布，问题将自动关闭，不会为问题设置里程碑，你需要查看修复该问题的PR以了解它在哪个版本中发布。

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

关于补丁级别发布的更多背景和FAQ可以在存储库dev文件夹中的"下一个版本会包含什么"文档中找到。