airflow
Apache Airflow 2.10.3
Apache Airflow（或简称 Airflow）是一个以编程方式编写、安排和监控工作流程的平台。
当工作流被定义为代码时，它们变得更加可维护、可版本化、可测试和协作。
使用 Airflow 将工作流程创作为任务的有向无环图 (DAG)。 Airflow 调度程序在一组工作人员上执行您的任务，同时遵循指定的依赖关系。丰富的命令行实用程序使在 DAG 上执行复杂的操作变得轻而易举。丰富的用户界面可以轻松可视化生产中运行的管道、监控进度并在需要时解决问题。
目录
Airflow 最适合大多数静态且缓慢变化的工作流程。当一次运行与下一次运行的 DAG 结构相似时，它澄清了工作单元和连续性。其他类似的项目包括 Luigi、Oozie 和 Azkaban。
Airflow 通常用于处理数据，但认为任务在理想情况下应该是幂等的（即任务的结果将是相同的，并且不会在目标系统中创建重复的数据），并且不应传递大量数据从一个任务到下一个任务（尽管任务可以使用 Airflow 的 XCom 功能传递元数据）。对于大批量、数据密集型任务，最佳实践是委托给专门从事该类型工作的外部服务。
Airflow 不是流式解决方案，但它通常用于处理实时数据，批量从流中提取数据。
Apache Airflow 经过以下测试：
| 主要版本（开发） | 稳定版本（2.10.3） | |
|---|---|---|
| Python | 3.9、3.10、3.11、3.12 | 3.8、3.9、3.10、3.11、3.12 |
| 平台 | AMD64/ARM64(*) | AMD64/ARM64(*) |
| 库伯内斯 | 1.28、1.29、1.30、1.31 | 1.27、1.28、1.29、1.30 |
| PostgreSQL | 13, 14, 15, 16, 17 | 12, 13, 14, 15, 16 |
| MySQL | 8.0、8.4、创新 | 8.0、8.4、创新 |
| SQLite | 3.15.0+ | 3.15.0+ |
* 实验性的
注意：MariaDB 未经测试/推荐。
注意：Airflow 测试中使用 SQLite。不要在生产中使用它。我们建议使用最新稳定版本的 SQLite 进行本地开发。
注意：Airflow 目前可以在符合 POSIX 标准的操作系统上运行。为了进行开发，它会定期在相当现代的 Linux 发行版和最新版本的 macOS 上进行测试。在 Windows 上，您可以通过 WSL2（适用于 Linux 2 的 Windows 子系统）或 Linux 容器运行它。添加 Windows 支持的工作通过 #10388 进行跟踪，但这并不是一个高优先级。您应该仅使用基于 Linux 的发行版作为“生产”执行环境，因为这是唯一受支持的环境。我们的 CI 测试中使用的以及社区管理的 DockerHub 映像中使用的唯一发行版是Debian Bookworm 。
请访问 Airflow 官方网站文档（最新稳定版本），获取有关安装 Airflow、入门或逐步完成更完整教程的帮助。
注意：如果您正在寻找主分支（最新开发分支）的文档：您可以在 s.apache.org/airflow-docs 上找到它。
有关气流改进建议 (AIP) 的更多信息，请访问 Airflow Wiki。
相关项目的文档，例如提供程序包、Docker 映像、Helm Chart，您可以在文档索引中找到它。
我们在 PyPI 中将 Apache Airflow 作为apache-airflow包发布。然而，安装它有时可能会很棘手，因为 Airflow 既是一个库，又是一个应用程序。库通常保持它们的依赖关系开放，应用程序通常固定它们，但我们应该两者都不做，或者同时做。我们决定尽可能保持依赖项的开放性（在pyproject.toml中），以便用户可以根据需要安装不同版本的库。这意味着pip install apache-airflow有时会无法工作，或者会产生无法使用的 Airflow 安装。
然而，为了实现可重复安装，我们在孤立的constraints-main和constraints-2-0分支中保留了一组“已知有效”的约束文件。我们为每个主要/次要 Python 版本单独保留那些“已知有效”的约束文件。从 PyPI 安装 Airflow 时，您可以将它们用作约束文件。请注意，您必须在 URL 中指定正确的 Airflow 标签/版本/分支和 Python 版本。
注意：目前官方仅支持
pip安装。
虽然可以使用 Poetry 或 pip-tools 等工具安装 Airflow，但它们不与pip共享相同的工作流程 - 特别是在约束与需求管理方面。目前不支持通过Poetry或pip-tools安装。
bazel存在一些已知问题，在使用 bazel 安装 Airflow 时可能会导致循环依赖。如果遇到此类问题请切换到pip 。 Bazel社区致力于解决this PR <https://github.com/bazelbuild/rules_python/pull/1166>中的问题_因此较新版本的bazel可能会处理该问题。
如果您希望使用这些工具安装 Airflow，则应使用约束文件并将其转换为您的工具所需的适当格式和工作流程。
pip install ' apache-airflow==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "pip install ' apache-airflow[postgres,google]==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "有关安装提供程序包的信息，请检查提供程序。
Apache Airflow 是 Apache Software Foundation (ASF) 项目，我们的官方源代码发布：
遵循 ASF 规则，发布的源代码包必须足以让用户构建和测试该版本，前提是他们可以访问适当的平台和工具。
还有其他安装和使用 Airflow 的方法。这些都是“方便”的方法——它们不是ASF Release Policy中规定的“官方发布”，但不想自己构建软件的用户可以使用它们。
这些是 - 按照人们安装 Airflow 的最常见方式的顺序排列：
pip工具安装 Airflowdocker工具安装airflow，在 Kubernetes、Helm Charts、 docker-compose 、 docker swarm等中使用它们。您可以在最新文档中阅读有关使用、自定义和扩展镜像的更多信息，并了解内部细节在图像文档中。所有这些工件都不是官方发布的，但它们是使用官方发布的源代码准备的。其中一些工件是“开发”或“预发布”工件，并且它们按照 ASF 政策明确标记为此类。
DAG ：环境中所有 DAG 的概述。
网格：跨越时间的 DAG 的网格表示。
图表：DAG 的依赖关系及其特定运行的当前状态的可视化。
任务持续时间：一段时间内花在不同任务上的总时间。
甘特图：DAG 的持续时间和重叠。
代码：查看 DAG 源代码的快速方法。
从 Airflow 2.0.0 开始，我们对所有发布的软件包都支持严格的 SemVer 方法。
我们同意的一些具体规则定义了不同包的版本控制细节：
google 4.1.0和amazon 3.0.3提供商可以轻松地与Airflow 2.1.2一起安装。如果提供程序和 Airflow 包之间存在交叉依赖关系限制，它们会作为install_requires限制出现在提供程序中。我们的目标是保持提供程序与所有先前发布的 Airflow 2 版本的向后兼容性，但有时会发生重大更改，可能会使某些或所有提供程序指定最低 Airflow 版本。Apache Airflow 版本生命周期：
| 版本 | 当前补丁/次要补丁 | 状态 | 首次发布 | 有限支持 | EOL/终止 |
|---|---|---|---|---|---|
| 2 | 2.10.3 | 支持 | 2020 年 12 月 17 日 | 待定 | 待定 |
| 1.10 | 2015年10月10日 | 停产 | 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 主要版本。
从 Airflow 2.0 开始，我们同意遵循 Python 和 Kubernetes 支持的某些规则。它们基于 Python 和 Kubernetes 的官方发布时间表，在 Python 开发人员指南和 Kubernetes 版本倾斜政策中得到了很好的总结。
当 Python 和 Kubernetes 版本达到 EOL 时，我们将不再支持它们。除 Kubernetes 之外，如果两个主要云提供商仍然提供支持，则 Airflow 仍会支持该版本。在 EOL 日期之后，我们在 main 中放弃了对这些 EOL 版本的支持，并且当我们发布 Airflow 的第一个新的 MINOR（如果没有新的 MINOR 版本，则为 MAJOR）时，它会被有效删除。例如，对于 Python 3.9，这意味着我们将在 2023 年 6 月 27 日之后放弃对 main 的支持，之后发布的 Airflow 的第一个 MAJOR 或 MINOR 版本将不再支持它。
在正式发布后，我们在 main 中支持新版本的 Python/Kubernetes，一旦我们让它们在我们的 CI 管道中工作（由于依赖项主要赶上新版本的 Python，这可能不会立即生效），我们就会发布新镜像Airflow 中的 /support 基于工作 CI 设置。
此政策是尽力而为，这意味着在某些情况下，如果情况需要，我们可能会提前终止支持。
Airflow 社区提供方便的打包容器映像，每当我们发布 Apache Airflow 版本时都会发布这些映像。这些图像包含：
基础操作系统映像的版本是 Debian 的稳定版本。 Airflow 支持使用所有当前活动的稳定版本 - 只要所有 Airflow 依赖项都支持构建，并且我们设置了用于构建和测试操作系统版本的 CI 管道。在之前稳定版本操作系统的常规支持结束之前大约 6 个月，Airflow 将发布的映像切换为使用最新支持的操作系统版本。
例如，从Debian Bullseye到Debian Bookworm切换已在 2023 年 10 月发布 2.8.0 之前实现，并且Debian Bookworm将是 Airflow 2.10.0 起支持的唯一选项。
用户将继续能够使用稳定的 Debian 版本构建他们的镜像，直到我们的 CI 中的常规支持和镜像构建和验证结束，但在main分支中没有使用该镜像执行单元测试。
Airflow 有很多依赖项 - 直接依赖项和传递依赖项，而且 Airflow 既是库又是应用程序，因此我们对依赖项的策略必须包括 - 应用程序安装的稳定性，以及为开发的用户安装更新版本的依赖项的能力DAG。我们开发了一种方法，其中使用constraints来确保气流可以以可重复的方式安装，同时我们不限制用户升级大多数依赖项。因此，我们决定默认不设置 Airflow 依赖项的上限版本，除非我们有充分的理由相信需要对它们进行上限，因为依赖项的重要性以及升级特定依赖项涉及的风险。我们还限制了已知会导致问题的依赖关系。
我们的约束机制负责自动查找和升级所有非上限依赖项（前提是所有测试都通过）。我们的main构建失败将表明是否存在破坏我们测试的依赖项版本 - 表明我们应该对它们进行上限绑定，或者我们应该修复我们的代码/测试以考虑这些依赖项的上游更改。
每当我们对这样的依赖关系进行上限时，我们应该总是注释为什么我们这样做——即我们应该有一个很好的理由为什么依赖关系是上限的。另外我们还应该提到解除绑定的条件是什么。
这些依赖项保存在pyproject.toml中。
我们认为很少有依赖项足够重要，可以在默认情况下对它们进行上限限制，因为众所周知，它们遵循可预测的版本控制方案，并且我们知道这些依赖项的新版本很可能会带来重大更改。我们承诺定期审查并尝试升级到发布的较新版本的依赖项，但这是手动过程。
重要的依赖项是：
SQLAlchemy ：特定 MINOR 版本的上限（众所周知，SQLAlchemy 会删除弃用内容并引入重大更改，特别是对不同数据库的支持各不相同且以不同的速度进行更改）Alembic ：以可预测和高性能的方式处理我们的迁移非常重要。它是与 SQLAlchemy 一起开发的。我们对 Alembic 的经验是它在 MINOR 版本中非常稳定Flask ：我们使用 Flask 作为 Web UI 和 API 的骨干。我们知道 Flask 的主要版本很可能会在这些版本之间引入重大更改，因此将其限制为主要版本是有意义的werkzeug ：已知该库会在新版本中引起问题。它与 Flask 库紧密耦合，我们应该一起更新它们celery ：Celery 是 Airflow 的重要组成部分，因为它用于 CeleryExecutor （和类似的）。 Celery 遵循 SemVer，因此我们应该将其上限限制为下一个 MAJOR 版本。另外，当我们升级库的较高版本时，我们应该确保 Celery Provider 最低 Airflow 版本已更新。kubernetes ：Kubernetes 是 Airflow 的重要组成部分，因为它用于 KubernetesExecutor（以及类似的）。 Kubernetes Python 库遵循 SemVer，因此我们应该将其上限限制为下一个主要版本。此外，当我们升级库的更高版本时，我们应该确保 Kubernetes Provider 最低 Airflow 版本已更新。Airflow 的主要部分是 Airflow Core，但 Airflow 的强大功能还来自许多扩展核心功能并单独发布的提供商，即使我们（目前）为了方便起见将它们保留在同一个 monorepo 中。您可以在提供程序文档中阅读有关提供程序的更多信息。我们还实施了一套用于维护和发布社区管理的提供商的政策，以及提供商文档中社区与第三方提供商的方法。
这些extras和providers依赖项均保存在每个提供程序的provider.yaml中。
默认情况下，我们不应该对提供者的依赖关系设置上限，但是每个提供者的维护者可能会决定添加额外的限制（并通过注释证明它们的合理性）。
想要帮助构建 Apache Airflow？查看我们的贡献者指南，全面了解如何贡献，包括设置说明、编码标准和拉取请求指南。
如果您迫不及待地想贡献并希望尽快开始，请在此处查看贡献快速入门！
镜像中描述了 Apache Airflow 的官方 Docker（容器）镜像。
+1s都被视为具有约束力的投票。 据我们所知，大约有 500 个组织正在使用 Apache Airflow（但可能还有更多）。
如果您使用 Airflow - 请随时制作 PR 将您的组织添加到列表中。
Airflow 是社区的工作，但核心提交者/维护者负责审查和合并 PR，以及围绕新功能请求引导对话。如果您想成为维护者，请查看 Apache Airflow 提交者要求。
通常，您会看到分配给 Airflow 版本的特定里程碑的问题，或者合并到主分支的 PR，您可能想知道合并的 PR 将在哪个版本中发布，或者修复的问题将在哪个版本中发布这个问题的答案和往常一样——这取决于不同的场景。 PR 和 Issue 的答案是不同的。
为了添加一些上下文，我们遵循 Airflow 发布流程中所述的 Semver 版本控制方案。更多细节在本自述文件的语义版本控制章节中进行了详细解释，但简而言之，我们有 Airflow 的MAJOR.MINOR.PATCH版本。
MAJOR版本会增加MINOR版本会增加PATCH版本会增加通常，我们会从以 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（错误修复和仅文档更改）在合并时可以被挑选到当前的MINOR分支并在下一个PATCHLEVEL版本中发布。例如，如果2.8.1已经发布，并且我们正在开发2.9.0dev ，那么用2.8.2里程碑标记 PR 意味着它将被挑选到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（错误修复和仅文档更改）在合并时可以被挑选到当前的MINOR分支并在下一个PATCHLEVEL版本中发布 - 例如，当v2-10-stable分支的最后发布版本是2.10.0rc1 ，来自 main 的一些 PR 可以被提交者标记为2.10.0里程碑，发布经理将尝试将它们挑选到发布分支中。如果成功，它们将在2.10.0rc2和随后的2.10.0中发布。这也适用于后续的PATCHLEVEL版本。例如，当2.10.1已经发布时，用2.10.2里程碑标记 PR 将意味着它将被挑选到v2-10-stable分支并在2.10.2rc1中发布，最终在2.10.2中发布。
关于挑选的最终决定由发布经理做出。
用里程碑标记问题有点不同。维护者通常不会用里程碑标记问题，通常只在 PR 中标记。如果与该问题相关的 PR（以及“修复它”）按照上述流程合并并在特定版本中发布，则该问题将自动关闭，不会为该问题设置里程碑，您需要检查该 PR修复了该问题以查看它发布的版本。
然而，有时维护人员会用特定的里程碑来标记问题，这意味着该问题对于成为准备发布时要查看的候选者很重要。由于这是一个开源项目，基本上所有贡献者都自愿投入时间，因此不能保证特定问题将在特定版本中得到解决。我们不想因为某些问题未修复而推迟发布，因此在这种情况下，发布经理会将此类未修复的问题重新分配到下一个里程碑，以防它们没有在当前版本中及时修复。因此，问题的里程碑更多的是应该关注它的意图，而不是承诺它将在版本中修复。
有关补丁级别版本的更多上下文和常见问题解答可以在存储库的dev文件夹中的下一个版本的内容文档中找到。
是的！请务必遵守 Apache 基金会商标政策和 Apache Airflow 品牌手册。最新的徽标可以在此存储库和 Apache 软件基金会网站上找到。
Apache Airflow 的 CI 基础设施得到了以下机构的赞助：
