Apache Airflow开源程序是一个以编程方式编写、计划和监控工作流程的平台

一、软件介绍

文末提供程序和源码下载

       Apache Airflow开源程序是一个以编程方式编写、计划和监控工作流程的平台，当工作流被定义为代码时，它们将变得更加可维护、可版本化、可测试和协作性。使用 Airflow 将工作流创作为任务的有向无环图 （DAG）。Airflow 计划程序在一系列工作程序上执行您的任务，同时遵循指定的依赖关系。丰富的命令行实用程序使在 DAG 上执行复杂的手术变得轻而易举。丰富的用户界面使您可以轻松地可视化生产中运行的管道、监控进度并在需要时解决问题。

二、项目重点

• Airflow 最适合大多数静态且缓慢变化的工作流。当 DAG 结构在每次运行中相似时，它会阐明工作单元和连续性。其他类似的项目包括 Luigi、Oozie 和 Azkaban。
• Airflow 通常用于处理数据，但认为任务理想情况下应该是幂等的（即，任务的结果将是相同的，并且不会在目标系统中创建重复的数据），并且不应将大量数据从一个任务传递到下一个任务（尽管任务可以使用 Airflow 的 XCom 功能传递元数据）。对于大容量、数据密集型任务，最佳实践是将委托给专门从事该类型工作的外部服务。
• Airflow 不是流式处理解决方案，但它通常用于处理实时数据，批量从流中提取数据。

三、原则

• 动态 ：Airflow 管道是配置即代码 （Python），允许生成动态管道。这允许编写动态实例化管道的代码。
• 可扩展 ：轻松定义您自己的运算符、执行程序并扩展库，使其适合适合您环境的抽象级别。
• 优雅 ： Airflow 管道精简而明确。使用强大的 Jinja 模板引擎将脚本参数化内置于 Airflow 的核心中。
• 可扩展 ：Airflow 具有模块化架构，并使用消息队列来编排任意数量的工作线程。

四、要求

Apache Airflow 经过以下测试：

注意 ：Airflow 目前可以在符合 POSIX 的作系统上运行。对于开发，它会定期在相当现代的 Linux 发行版和最新版本的 macOS 上进行测试。在 Windows 上，您可以通过 WSL2（适用于 Linux 2 的 Windows 子系统）或通过 Linux 容器运行它。添加 Windows 支持的工作通过 #10388 进行跟踪，但这不是高优先级。您应该只使用基于 Linux 的发行版作为“生产”执行环境，因为这是唯一受支持的环境。在我们的 CI 测试中使用的唯一发行版以及社区托管的 DockerHub 映像中使用的发行版是 Debian 书虫

五、开始

访问 Airflow 官方网站文档（最新稳定版本）以获取帮助 安装 Airflow， 入门 ，或演练更完整的教程 

从 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. Installing just Airflow:  仅安装 Airflow：

Note: Only pip installation is currently officially supported.
注意：目前官方仅支持 pip 安装。

While it is possible to install Airflow with tools like Poetry or pip-tools, they do not share the same workflow as pip - especially when it comes to constraint vs. requirements management. Installing via Poetry or pip-tools is not currently supported.
虽然可以使用 Poetry 或 pip-tools 共享相同的工作流，它们与 pip - 尤其是在约束与需求管理方面。目前不支持通过 Poetry 或 pip-tools 安装。

There are known issues with bazel that might lead to circular dependencies when using it to install Airflow. Please switch to pip if you encounter such problems. Bazel community works on fixing the problem in this PR <https://github.com/bazelbuild/rules_python/pull/1166>_ so it might be that newer versions of bazel will handle it.
Bazel 存在一些已知问题，在使用 Bazel 安装 Airflow 时可能会导致循环依赖关系。如果您遇到此类问题，请切换到 pip。Bazel 社区致力于修复 _ 中 this PR <https://github.com/bazelbuild/rules_python/pull/1166> 的问题，因此可能会有较新版本的 Bazel 来处理该问题。

If you wish to install Airflow using those tools, you should use the constraint files and convert them to the appropriate format and workflow that your tool requires.
如果您希望使用这些工具安装 Airflow，则应使用约束文件并将它们转换为工具所需的适当格式和工作流程。

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

1. Installing with extras (i.e., postgres, google)
   使用 extras（即 postgres、google）安装

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

从 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 版本将不会有它。
• 在正式发布后，我们主要支持新版本的 Python/Kubernetes，一旦我们让它们在 CI 管道中工作（由于依赖项主要赶上了新版本的 Python，这可能不是立即的），我们就会根据工作的 CI 设置在 Airflow 中发布新的映像/支持。
• 此政策是尽力而为的，这意味着在某些情况下，如果情况需要，我们可能会提前终止支持。

基本作系统对参考 Airflow 映像的支持

Airflow 社区提供方便打包的容器映像，每当我们发布 Apache Airflow 版本时，都会发布这些映像。这些映像包含：

• Base OS with necessary packages to install Airflow (stable Debian OS)
  具有安装 Airflow 所需的软件包的基础作系统（稳定的 Debian 作系统）
• Base Python installation in versions supported at the time of release for the MINOR version of Airflow released (so there could be different versions for 2.3 and 2.2 line for example)
  在发布时支持的版本中进行基本 Python 安装，以用于发布的 Airflow 的 MINOR 版本（因此，例如，2.3 和 2.2 行可能有不同的版本）
• Libraries required to connect to supported Databases (again the set of databases supported depends on the MINOR version of Airflow)
  连接到支持的数据库所需的库（同样，支持的数据库集取决于 Airflow 的 MINOR 版本）
• Predefined set of popular providers (for details see the Dockerfile).
  预定义的常用提供程序集（有关详细信息，请参阅 Dockerfile）。
• Possibility of building your own, custom image where the user can choose their own set of providers and libraries (see Building the image)
  可以构建您自己的自定义映像，用户可以在其中选择自己的一组提供程序和库（请参阅构建映像 ）
• In the future Airflow might also support a "slim" version without providers nor database clients installed
  将来，Airflow 可能还支持没有安装提供程序和数据库客户端的“精简”版本

Airflow 依赖项的方法

• Airflow 有很多依赖项 - 直接和传递，而且 Airflow 既是库又是应用程序，因此我们的依赖项策略必须包括 - 应用程序安装的稳定性，以及为开发 DAG 的用户安装更新版本的依赖项的能力。我们开发了一种使用约束的方法，以确保 airflow 可以以可重复的方式安装，同时我们不限制我们的用户升级大多数依赖项。因此，我们决定默认不使用 Airflow 依赖项的上限版本，除非我们有充分的理由相信它们需要上限，因为依赖项的重要性以及升级特定依赖项所涉及的风险。我们还对我们知道会导致问题的依赖项进行了上限设置。
• 我们的约束机制负责自动查找和升级所有非上限依赖项（前提是所有测试都通过）。我们的主要构建失败将指示是否存在破坏测试的依赖项版本 - 表明我们应该对它们进行上绑，或者我们应该修复我们的代码/测试以考虑来自这些依赖项的上游更改。
• 每当我们对这样的依赖进行上限时，我们应该始终说明我们为什么要这样做 - 即我们应该有一个很好的理由为什么依赖是上限的。我们还应该提到删除绑定的条件是什么。

Those dependencies are maintained in pyproject.toml.
这些依赖项在 pyproject.toml 中维护。

There are few dependencies that we decided are important enough to upper-bound them by default, as they are known to follow predictable versioning scheme, and we know that new versions of those are very likely to bring breaking changes. We commit to regularly review and attempt to upgrade to the newer versions of the dependencies as they are released, but this is manual process.
默认情况下，我们认为很少有依赖项足够重要，因此可以对其进行上限限制，因为众所周知，它们遵循可预测的版本控制方案，并且我们知道这些依赖项的新版本很可能会带来重大变化。我们承诺定期审查并在依赖项发布时尝试升级到新版本，但这是手动过程。

The important dependencies are:
重要的依赖项包括：

• SQLAlchemy: upper-bound to specific MINOR version (SQLAlchemy is known to remove deprecations and introduce breaking changes especially that support for different Databases varies and changes at various speed)
  SQLAlchemy：特定 MINOR 版本的上限（众所周知，SQLAlchemy 会删除弃用并引入重大更改，尤其是对不同数据库的支持会有所不同，并且以不同的速度进行更改）
• Alembic: it is important to handle our migrations in predictable and performant way. It is developed together with SQLAlchemy. Our experience with Alembic is that it very stable in MINOR version
  Alembic：以可预测和高性能的方式处理我们的迁移非常重要。它是与 SQLAlchemy 一起开发的。我们对 Alembic 的经验是，它在 MINOR 版本中非常稳定
• Flask: We are using Flask as the back-bone of our web UI and API. We know major version of Flask are very likely to introduce breaking changes across those so limiting it to MAJOR version makes sense
  Flask：我们使用 Flask 作为 Web UI 和 API 的主干。我们知道 Flask 的主要版本很可能会引入重大更改，因此将其限制为主要版本是有意义的
• werkzeug: the library is known to cause problems in new versions. It is tightly coupled with Flask libraries, and we should update them together
  Werkzeug：众所周知，该库会在新版本中引起问题。它与 Flask 库紧密耦合，我们应该一起更新它们
• celery: Celery is a crucial component of Airflow as it used for CeleryExecutor (and similar). Celery follows SemVer, so we should upper-bound it to the next MAJOR version. Also, when we bump the upper version of the library, we should make sure Celery Provider minimum Airflow version is updated.
  celery：Celery 是 Airflow 的关键组件，因为它用于 CeleryExecutor（和类似）。 芹菜 遵循 SemVer，因此我们应该将其上限绑定到下一个 MAJOR 版本。此外，当我们提升库的上层版本时，我们应该确保 Celery Provider 最低 Airflow 版本已更新。
• kubernetes: Kubernetes is a crucial component of Airflow as it is used for the KubernetesExecutor (and similar). Kubernetes Python library follows SemVer, so we should upper-bound it to the next MAJOR version. Also, when we bump the upper version of the library, we should make sure Kubernetes Provider minimum Airflow version is updated.
  kubernetes：Kubernetes 是 Airflow 的关键组件，因为它用于 KubernetesExecutor（和类似）。Kubernetes Python 库遵循 SemVer，因此我们应该将其上限到下一个 MAJOR 版本。此外，当我们提升库的上限版本时，我们应该确保 Kubernetes Provider 最低 Airflow 版本已更新。

The main part of the Airflow is the Airflow Core, but the power of Airflow also comes from a number of providers that extend the core functionality and are released separately, even if we keep them (for now) in the same monorepo for convenience. You can read more about the providers in the Providers documentation. We also have set of policies implemented for maintaining and releasing community-managed providers as well as the approach for community vs. 3rd party providers in the providers document.
Airflow 的主要部分是 Airflow 核心，但 Airflow 的力量也来自许多 扩展核心功能并单独发布的提供程序，即使我们保留它们（暂时） 为方便起见，在同一个 monorepo 中。您可以在 提供商文档 。我们还实施了一套策略来维护和发布社区管理的提供商，以及提供商文档中的社区与第三方提供商的方法。

Those extras and providers dependencies are maintained in provider.yaml of each provider.
这些 extras 和 providers 依赖项在每个提供程序的 provider.yaml 中维护。

By default, we should not upper-bound dependencies for providers, however each provider's maintainer might decide to add additional limits (and justify them with comment).
默认情况下，我们不应该对 provider 的依赖项进行上限限制，但是每个 provider 的维护者可能会决定添加额外的限制（并通过评论来证明它们）。

七、软件下载

夸克网盘分享

本文信息来源于GitHub作者地址：https://github.com/apache/airflow