HuaweiCloud-Airflow-provider: HuaweiCloud-Airflow-provider

Apache Airflow

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

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

使用Airflow以有向无环图（DAG）的形式编写工作流。Airflow调度器根据指定的依赖关系，在工作机阵列上执行任务。丰富的命令行工具使得对DAG进行复杂操作变得轻而易举。丰富的用户界面使得在生产环境中可视化管道运行、监控进度以及在需要时排除问题变得简单。

目录

• 项目重点
• 原则
• 需求
• 快速入门
• 从PyPI安装
• 官方源代码
• 便捷包
• 用户界面
• 语义版本控制
• 版本生命周期
• 对Python和Kubernetes版本的支持
• 参考Airflow镜像的基础操作系统支持
• Airflow依赖处理方法
• Provider发布流程
• 贡献指南
• Apache Airflow的用户
• Apache Airflow的维护者
• 我可以在我的演示中使用Apache Airflow的标志吗？
• Airflow周边商品
• 链接
• 赞助商

项目重点

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

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

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

原则

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

需求

Apache Airflow经过以下环境的测试：

	主要版本（开发）	稳定版本（2.5.2）
Python	3.7, 3.8, 3.9, 3.10	3.7, 3.8, 3.9, 3.10
平台	AMD64/ARM64(*)	AMD64/ARM64(*)
Kubernetes	1.23, 1.24, 1.25, 1.26	1.21, 1.22, 1.23, 1.24, 1.25
PostgreSQL	11, 12, 13, 14, 15	11, 12, 13, 14, 15
MySQL	5.7, 8	5.7, 8
SQLite	3.15.0+	3.15.0+
MSSQL	2017(*), 2019(*)	2017(*), 2019(*)

* 试用

注意：MySQL 5.x版本无法或有限制地运行多个调度器——请参阅调度器文档。 MariaDB未经测试/不推荐。

注意：SQLite用于Airflow测试。不要在生产环境中使用它。我们建议使用最新稳定版本的SQLite进行本地开发。

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

开始使用

访问官方Airflow网站文档（最新稳定版本）以获取帮助：

• 安装Airflow
• 入门指南
• 或者跟随更完整的教程。

注意：如果您需要主分支（最新开发分支）的文档，请访问 s.apache.org/airflow-docs。

关于Airflow改进提案（AIPs）的更多信息，请访问 Airflow Wiki。

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

从PyPI安装

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

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

1. 仅安装Airflow：

注意：目前仅官方支持使用pip安装。

虽然可以使用像Poetry或pip-tools这样的工具来安装Airflow，但它们的流程与pip不同 - 尤其是在约束与需求管理方面。 使用Poetry或pip-tools进行安装目前不受支持。

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

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

2. 带有附加组件的安装（例如，PostgreSQL、Google）

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

关于安装提供者包的信息，请查阅提供者文档。

官方源代码

Apache Airflow 是 Apache 软件基金会（ASF）的项目，我们的官方源代码发布遵循以下原则：

• 遵循 ASF 发布政策
• 可以从 ASF 分发目录 下载
• 由发布管理者进行加密签名
• 在 发布审批过程 中由项目管理委员会（PMC）成员正式投票

根据 ASF 规则，发布的源代码包必须足够用户构建和测试所提供的版本，前提是他们能够访问到适当的平台和工具。

方便的安装包

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

以下是最常见的安装 Airflow 方法：

• 使用标准的 pip 工具安装 PyPI 发布版
• 使用 Docker 镜像 通过 docker 工具安装 Airflow，用于 Kubernetes、Helm 图表、docker-compose、docker swarm 等。您可以阅读更多关于使用、自定义和扩展这些镜像的内容在 最新文档，并了解内部的详细信息在 IMAGES.rst 文档中。
• 通过 GitHub 标签 获取生成官方源代码包所使用的 git 项目源码

所有这些构建都不是官方发布，但它们都是使用官方发布源码准备的。其中一些构建是“开发”或“预发布”版本，并且它们会根据 ASF 政策明确标记为这类版本。

用户界面

• DAGs：您环境中所有 DAGs 的概览。

  

• 网格：跨时间的 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 版本对提供者来说是破坏性更改，因为安装新提供者可能会自动升级 Airflow（这可能是不希望将提供者升级作为副作用）。
• Airflow Helm 图表：SemVer 规则仅适用于图表的更改。图表的 SemVer 主版本和次版本与 Airflow 版本独立。我们旨在保持 Helm 图表与所有发布的 Airflow 2 版本的向后兼容性，但某些新功能可能仅从特定的 Airflow 版本开始支持。但我们可能会限制 Helm 图表依赖于最低 Airflow 版本。
• Airflow API 客户端：SemVer 主版本和次版本遵循 Airflow 的主版本和次版本。Airflow 的第一个主版本或次版本 X.Y.0 发布后，应该总是跟随 X.Y.0 版本的客户端。Airflow 的修补版本 X.Y.Z 可以跟随客户端的修补版本，只有当此修补版本与客户端相关时。然后，客户端可以独立于 Airflow 修补版本发布自己的修补版本以修复错误。因此，每个 API 客户端将拥有可能与 Airflow 修补版本同步或不同步的自己的修补版本。对于特定的主版本/次版本 Airflow，用户应该优先选择最新版本的客户端，而独立于他们的 Airflow 修补版本。

版本生命周期

Apache Airflow 版本生命周期如下：

版本	当前修补/次级版本	状态	首次发布日期	有限支持	生命结束/终止
2	2.5.2	受支持	Dec 17, 2020	TBD	TBD
1.10	1.10.15	生命结束	Aug 27, 2018	Dec 17, 2020	June 17, 2021
1.9	1.9.0	生命结束	Jan 03, 2018	Aug 27, 2018	Aug 27, 2018
1.8	1.8.2	生命结束	Mar 19, 2017	Jan 03, 2018	Jan 03, 2018
1.7	1.7.1.2	生命结束	Mar 28, 2016	Mar 19, 2017	Mar 19, 2017

有限支持版本将仅支持安全和关键错误修复。生命结束版本将不会获得任何修复或支持。我们总是建议所有用户使用正在使用的任何主版本的最新次级版本。我们强烈建议尽早升级到最新的 Airflow 主版本，并在生命结束日期之前完成升级。

Python 和 Kubernetes 版本支持

自 Airflow 2.0 起，我们确定了一些关于 Python 和 Kubernetes 支持的规则。这些规则基于 Python 和 Kubernetes 的官方发布计划，并在Python 开发者指南及Kubernetes 版本偏差政策中进行了清晰的总结。

1. 当 Python 和 Kubernetes 版本达到生命周期结束（EOL）时，我们会停止支持。对于 Kubernetes，如果两个主要云服务提供商仍然支持该版本，则 Airflow 会继续支持。我们在生命周期结束日期之后立即在主分支中停止对这些 EOL 版本的支持，并在发布首个新的 MINOR（如果没有新的 MINOR 版本，则为 MAJOR）版本时彻底移除。例如，对于 Python 3.7，这意味着我们将在 2023 年 6 月 27 日之后立即在主分支中停止支持，并且之后发布的首个 MAJOR 或 MINOR 版本将不再包含它。

2. 直到我们决定切换到更高版本之前，“最旧”的支持版本是默认版本。这里的“默认”仅在有意义的烟雾测试中才有意义，这些测试使用默认版本和默认的参考镜像。目前 apache/airflow:latest 和 apache/airflow:2.5.2 镜像是 Python 3.7 镜像。这意味着，当我们开始准备停止支持 3.7（在 Python 3.7 生命周期结束前几个月）时，默认参考镜像将变为默认。

3. 在 Python/Kubernetes 版本正式发布后，我们会尽快在主分支中支持新版本，一旦我们在 CI 流程中使它们正常工作（这可能不是立即的，因为依赖项需要赶上 Python 的新版本），我们就会根据工作的 CI 设置发布新的镜像/支持。

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

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

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

基础 OS 镜像的版本是 Debian 的稳定版本。Airflow 支持 所有当前活跃的稳定版本——一旦所有 Airflow 依赖项支持构建，并且我们为构建和测试 OS 版本设置了 CI 流程。在先前稳定版本的 OS 生命周期结束前大约 6 个月，Airflow 会将发布的镜像切换到最新的支持版本。例如，由于 Debian Buster 的生命周期结束时间是 2022 年 8 月，Airflow 在 2022 年 2 月/3 月将 main 分支中的镜像切换到使用 Debian Bullseye。该版本在切换发生后的下一个 MINOR 版本中使用。在 Bullseye 切换的情况下——2.3.0 版本使用了 Debian Bullseye。在先前的 MINOR 版本中发布的镜像继续使用所有其他版本使用的版本。

在 2022 年 8 月，Debian Buster 镜像的支持完全停止，所有人应停止使用 Debian Buster 构建他们的镜像。

用户将继续能够使用稳定 Debian 版本构建他们的镜像，直到生命周期结束，镜像的构建和验证会在我们的 CI 中进行，但在 main 分支中不会使用此镜像执行单元测试。

Airflow 依赖项的处理方法

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

我们的约束机制负责自动查找和升级所有未上限的依赖项（前提是所有测试通过）。我们的 main 构建失败将表明存在会破坏我们测试的依赖项版本——这意味着我们应该要么上限它们，要么修复我们的代码/测试以适应依赖项的上游更改。

每次我们上限这样的依赖项时，我们都应该注明为什么这么做——即我们应该有一个上限依赖项的好理由。我们还应该提到移除限制的条件。

Airflow 核心依赖项的处理方法

那些 extras 和 providers 依赖项在 setup.cfg 中维护。

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

重要的依赖项包括：

• SQLAlchemy：上限到特定的 MINOR 版本（SQLAlchemy 以移除弃用项和引入破坏性更改而闻名，特别是不同数据库的支持变化和速度各不相同，例如：SQLAlchemy 1.4 版本破坏了 Airflow 的 MSSQL 集成）
• Alembic：处理我们的迁移需要可预测且高效的方式。它与 SQLAlchemy 一起开发。我们从 Alembic 的经验是 MINOR 版本非常稳定
• Flask：我们使用 Flask 作为我们的 Web UI 和 API 的基础。我们知道 Flask 的主要版本很可能会引入破坏性更改，因此将其限制在 MAJOR 版本是有意义的
• werkzeug：新版本此库已知会引发问题。它与 Flask 库紧密耦合，我们应该一起更新它们
• celery：Celery 是 Airflow 的关键组件，因为它用于 CeleryExecutor（和类似的）。Celery 遵循 SemVer，因此我们应该上限到下一个 MAJOR 版本。当我们提升库的上限版本时，我们还应该确保 Celery 提供程序的最低 Airflow 版本得到更新）。
• kubernetes：Kubernetes 是 Airflow 的关键组件，因为它用于 KubernetesExecutor（和类似的）。Kubernetes Python 库 遵循 SemVer，因此我们应该上限到下一个 MAJOR 版本。当我们提升库的上限版本时，我们还应该确保 Kubernetes 提供程序的最低 Airflow 版本得到更新。

Airflow 依赖项与附加组件处理方法

各个提供商的 extras 和 providers 依赖项在各自提供商的 provider.yaml 文件中维护。

默认情况下，我们不应为提供商设置依赖项的上限，但每个提供商的维护者可以决定添加额外的限制（并加以注释说明）。

提供商发布流程

由社区发布的提供商（大约每月一次）受限于支持 Airflow 的最低版本。Airflow 的最低版本为 MINOR 版本（例如 2.2、2.3 等），表明提供商可能使用了该版本中出现的新特性。Airflow 最低版本默认的支持时段（可能有合理例外）是：当自该 MINOR 版本首次发布以来满 12 个月时，我们提升最低 Airflow 版本。

例如，这意味着在 2023 年 4 月 30 日之后的第一次提供商发布中，我们将提供商支持的最低版本升级到 2.4.0。2022 年 4 月 30 日是首个 PATCHLEVEL 版本 2.3（即 2.3.0）发布的日期。

当我们提升最低 Airflow 版本时，这并不是提升提供商 MAJOR 版本的理由（除非提供商中还有其他破坏性更改）。原因在于使用旧版 Airflow 的用户将无法使用该提供商（因此对他们而言并非破坏性更改），而对于使用受支持版本 Airflow 的用户，这本身也不是破坏性更改——他们能够无缝使用新版本而不影响工作流。当我们升级到 2.2+ 版本的最低版本时，我们的做法不同，但从 2.3+ 版本升级（2022 年 11 月）起，我们仅在当地提升 Airflow 版本时提升提供商的 MINOR 版本。

提供商通常与一些关键利益相关者相关联，他们对维护其集成的向后兼容性有着极大的兴趣（例如云服务提供商或特定服务提供商）。但是，我们也受制于 Apache 软件基金会发布政策，其中描述了谁负责发布以及如何发布 ASF 软件。我们所说的提供商治理模式是“混合治理”——即我们遵循发布政策，而维护和测试挑选的版本的负担则落在那些承诺执行挑选并针对旧版本分支提出 PR 的人身上。

“混合治理”（每个提供商可选）意味着：

• Airflow 社区和发布经理决定何时发布这些提供商。这完全由社区管理和遵循 Apache 软件基金会发布政策的常规发布管理流程。
• 贡献者（可能是也可能不是提供商的直接利益相关者）将承担挑选和测试提供商旧版本的责任。
• 没有选择和接受流程来确定发布提供商的哪个版本。这由贡献者通过提出挑选变更的 PR 来决定，并遵循常规的 PR 审查流程，由维护者批准（或不批准）并合并（或不合并）此类 PR。简单地说，挑选和测试提供商旧版本的行为使其有资格发布。除非有人自愿执行挑选和测试，否则不会发布提供商版本。
• 当贡献者承诺执行挑选时，会创建用于提出 PR 的分支（例如在 PR 中挑选注释）。

通常，社区的努力集中在每个提供商的最新版本。社区的策略是我们在提供商的“主要”版本中应该积极地移除弃用功能——每当有机会提升提供商的主要版本时，我们都会尝试移除所有弃用功能。然而，有时会有贡献者（可能代表也可能不代表利益相关者）愿意在挑选和测试提供商选定旧版本的非破坏性变更上投入努力。这导致了一次最多发布两个提供商版本：

• 可能具有破坏性的“最新”主要版本
• 由贡献者应用非破坏性变更的选定旧主要版本

挑选此类变更遵循与为前一个 Airflow 次要版本发布修补级别版本相同的流程。通常在存在重要的错误修复且最新版本包含与错误修复不相关的破坏性变更时进行此类挑选。将它们一起发布在提供商的最新版本中实际上将它们关联起来，因此它们是分开发布的。挑选的变更必须由提交者按照社区的常规规则合并。

没有义务挑选和发布提供商的旧版本。只要贡献者愿意执行挑选并继续测试旧版本的提供商，社区将继续发布此类旧版本。

如果有关键利益相关者能够管理“面向服务”的维护并同意承担此类责任，这也将推动我们接受未来的新提供商成为社区管理的意愿。

贡献指南

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

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

谁在使用 Apache Airflow？

超过 400 家组织在实际环境中使用 Apache Airflow。

谁维护 Apache Airflow？

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

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

当然可以！请确保遵守 Apache 基金会的商标政策和 Apache Airflow 的品牌手册。最新标志可以在这个仓库和 Apache 软件基金会网站上找到。

Airflow 商品

如果您想要 Apache Airflow 贴纸、T 恤等商品，请查看Redbubble 商店。

链接

• 文档
• 聊天室

赞助商

Apache Airflow 的持续集成基础设施得到了以下赞助商的支持：