架构概述¶
Airflow 是一个允许您构建和运行工作流的平台。工作流表示为一个 DAG（有向无环图），其中包含称为 任务 的独立工作单元，这些工作单元按照依赖关系和数据流进行排列。
DAG 指定任务之间的依赖关系，这定义了执行任务的顺序。任务描述要做什么，无论是获取数据、运行分析、触发其他系统，还是更多。
Airflow 本身与您运行的内容无关 - 它将很乐意协调和运行任何内容，无论是有我们某个提供商的高级支持，还是直接使用 shell 或 Python 操作符 作为命令。
Airflow 组件¶
Airflow 的架构由多个组件组成。以下部分描述了每个组件的功能，以及它们是否是最低限度 Airflow 安装所必需的，或者是实现更好的 Airflow 可扩展性、性能和可伸缩性的可选组件。
必需组件¶
最小的 Airflow 安装包含以下组件
可选组件¶
一些 Airflow 组件是可选的，可以在您的 Airflow 中实现更好的可扩展性、可伸缩性和性能
可选的工作器，它执行调度器给它的任务。在基本安装中，工作器可能是调度器的一部分，而不是单独的组件。它可以在 CeleryExecutor 中作为长时间运行的进程运行，或者在 KubernetesExecutor 中作为 POD 运行。
可选的触发器，它在 asyncio 事件循环中执行延迟的任务。在不使用延迟任务的基本安装中，不需要触发器。有关延迟任务的更多信息，请参见 可延迟操作符和触发器。
可选的DAG 处理器，它解析 DAG 文件并将它们序列化到元数据数据库中。默认情况下，DAG 处理器进程是调度器的一部分，但出于可扩展性和安全原因，它可以作为单独的组件运行。如果存在DAG 处理器，调度器不需要直接读取DAG 文件。有关处理 DAG 文件的更多信息，请参见 DAG 文件处理
可选的插件文件夹。插件是一种扩展 Airflow 功能的方式（类似于安装的包）。调度器、DAG 处理器、触发器和Web服务器读取插件。有关插件的更多信息，请参见 插件。
部署 Airflow 组件¶
所有组件都是 Python 应用程序，可以使用各种部署机制进行部署。
它们可以在其 Python 环境中安装额外的已安装的包。这对于例如安装自定义操作符或传感器或使用自定义插件扩展 Airflow 功能非常有用。
虽然 Airflow 可以在一台机器上运行，并且只需部署调度器和Web服务器即可进行简单安装，但 Airflow 的设计具有可扩展性和安全性，并且能够在分布式环境中运行 - 其中各种组件可以在不同的机器上运行，具有不同的安全边界，并且可以通过运行多个组件实例来扩展。
组件的分离还允许提高安全性，通过将组件彼此隔离并允许执行不同的任务。例如，将DAG 处理器与调度器分离可以确保调度器无法访问DAG 文件，并且无法执行DAG 作者提供的代码。
此外，虽然单个人可以运行和管理 Airflow 安装，但更复杂的设置中的 Airflow 部署可能涉及可以与系统不同部分交互的各种用户角色，这是安全 Airflow 部署的一个重要方面。角色在 Airflow 安全模型 中详细描述，一般而言包括
部署管理器 - 安装和配置 Airflow 并管理部署的人员
DAG 作者 - 编写 DAG 并将其提交给 Airflow 的人员
操作用户 - 触发 DAG 和任务并监视其执行的人员
架构图¶
下图显示了部署 Airflow 的不同方式 - 从简单的“单机”和单人部署逐步过渡到具有单独组件、单独用户角色以及最终具有更隔离的安全边界的更复杂的部署。
下图中的不同连接类型的含义如下
棕色实线表示DAG 文件的提交和同步
蓝色实线表示部署和访问已安装的包和插件
黑色虚线表示调度器（通过执行器）控制工作器的流程
黑色实线表示访问 UI 以管理工作流的执行
红色虚线表示所有组件访问元数据数据库
基本 Airflow 部署¶
这是 Airflow 的最简单部署，通常在单台机器上操作和管理。这样的部署通常使用 LocalExecutor，其中调度器和工作器在同一个 Python 进程中，调度器直接从本地文件系统读取DAG 文件。Web服务器与调度器在同一台机器上运行。没有触发器组件，这意味着任务延迟是不可能的。
这样的安装通常不会分离用户角色 - 部署、配置、操作、创作和维护都由同一个人完成，并且组件之间没有安全边界。
如果您想在简单的单机设置中的单台机器上运行 Airflow，您可以跳过下面更复杂的图表，直接转到 工作负载 部分。
分布式 Airflow 架构¶
这是 Airflow 的架构，其中 Airflow 的组件分布在多台机器之间，并引入了各种用户角色 - 部署管理器、DAG 作者、操作用户。您可以在 Airflow 安全模型 中阅读有关这些各种角色的更多信息。
在分布式部署的情况下，必须考虑组件的安全方面。Web服务器不能直接访问DAG 文件。UI 的 代码 选项卡中的代码是从元数据数据库读取的。Web服务器不能执行由 DAG 作者 提交的任何代码。它只能执行由 部署管理器 作为已安装的包或插件安装的代码。操作用户只能访问 UI，并且只能触发 DAG 和任务，但不能编写 DAG。
DAG 文件需要在所有使用它们的组件（调度器、触发器和工作器）之间同步。DAG 文件可以通过各种机制同步 - 我们的 Helm Chart 文档的 管理 DAG 文件 中描述了同步 DAG 的典型方法。Helm chart 是在 K8S 集群中部署 Airflow 的方法之一。
独立的 DAG 处理架构¶
在安全性和隔离很重要的更复杂的安装中，您还会看到独立的DAG 处理器组件，它允许将调度器与访问DAG 文件分离。如果部署的重点是解析任务之间的隔离，则此功能适用。虽然 Airflow 尚未支持完全多租户功能，但它可用于确保 DAG 作者 提供的代码永远不会在调度器的上下文中执行。
注意
当 DAG 文件发生更改时，可能会出现调度器和工作器看到不同版本的 DAG 的情况，直到两个组件都完成同步。您可以通过在部署期间禁用 DAG，并在完成后重新激活来避免此问题。如果需要，可以配置 DAG 文件夹的同步和扫描频率。请确保您在更改配置时清楚自己在做什么。
工作负载¶
一个 DAG 通过一系列 任务 运行，您会看到三种常见的任务类型
操作符，预定义的任务，您可以快速将它们串联起来构建 DAG 的大部分内容。
传感器，操作符的一个特殊子类，其完全专注于等待外部事件的发生。
一个使用 TaskFlow 修饰的
@task，它是一个打包成任务的自定义 Python 函数。
在内部，这些实际上都是 Airflow 的 BaseOperator 的子类，并且任务和操作符的概念在某种程度上是可以互换的，但是将它们视为不同的概念是有用的——本质上，操作符和传感器是模板，当您在 DAG 文件中调用一个时，您正在创建一个任务。
控制流¶
DAG 被设计为多次运行，并且它们的多次运行可以并行发生。DAG 是参数化的，始终包含一个它们“运行的”时间间隔（数据间隔），但也可以包含其他可选参数。
任务 之间声明了相互依赖关系。您可以在 DAG 中看到使用 >> 和 << 操作符
first_task >> [second_task, third_task]
fourth_task << third_task
或者，使用 set_upstream 和 set_downstream 方法
first_task.set_downstream([second_task, third_task])
fourth_task.set_upstream(third_task)
这些依赖关系构成了图的“边”，以及 Airflow 如何计算出任务的运行顺序。默认情况下，一个任务会等待其所有上游任务成功后再运行，但这可以使用诸如 分支、LatestOnly 和 触发规则 等功能进行自定义。
要在任务之间传递数据，您有三种选择
XComs（“跨通信”），一个系统，您可以在其中让任务推送和拉取少量元数据。
从存储服务（您可以运行的服务，或公共云的一部分）上传和下载大型文件
TaskFlow API 通过隐式 XComs 自动在任务之间传递数据
Airflow 会在空间可用时将任务发送到工作器上运行，因此无法保证 DAG 中的所有任务都将在同一工作器或同一机器上运行。
随着您构建 DAG，它们可能会变得非常复杂，因此 Airflow 提供了多种机制来使其更具可持续性——子 DAG 让您可以创建可嵌入到其他 DAG 中的“可重用” DAG，而 任务组 让您可以在 UI 中直观地分组任务。
用户界面¶
Airflow 带有用户界面，可让您查看 DAG 及其任务的运行情况、触发 DAG 的运行、查看日志以及对 DAG 的问题进行一些有限的调试和解决。
它通常是查看您的 Airflow 安装整体状态的最佳方式，以及深入研究单个 DAG 以查看其布局、每个任务的状态以及每个任务的日志。