架构概览
Airflow 是一个让您构建和运行 工作流 的平台。工作流以 Dag（有向无环图）的形式表示，并包含称为 任务 的单个工作单元，按照依赖关系和数据流进行组织。
Dag 指定任务之间的依赖关系，从而定义任务的执行顺序。任务描述要执行的操作，例如获取数据、运行分析、触发其他系统等。
Airflow 本身对您运行的内容保持中立 —— 它可以轻松地编排和运行任何任务，既可以通过我们的提供者提供的高级支持，也可以直接使用 shell 或 Python 算子 作为命令运行。
Airflow 组件
Airflow 的架构由多个组件组成。以下章节描述每个组件的功能，以及它们是最小化 Airflow 安装所必需的，还是用于实现更好可扩展性、性能和伸缩性的可选组件。
必需组件
最小化的 Airflow 安装包括以下组件
一个 调度器，负责触发计划好的工作流并将 任务 提交给执行器运行。执行器 是 调度器 的配置属性，而不是独立的组件，运行在调度器进程中。开箱即用提供了多种执行器，您也可以自行编写。
一个 Dag 处理器，解析 Dag 文件并将其序列化到 元数据数据库 中。有关 Dag 文件处理的更多信息，请参见 Dag 文件处理
一个 Web 服务器，提供便捷的用户界面用于检查、触发和调试 Dag 与任务的行为。
一个 Dag 文件 文件夹，供 调度器 读取，以确定要运行的任务以及运行时间。
一个 元数据数据库，通常是 PostgreSQL 或 MySQL，用于存储任务、Dag 和变量的状态。
如何设置元数据数据库请参见 设置数据库后端，这是 Airflow 正常运行所必需的。
可选组件
某些 Airflow 组件是可选的，可提升 Airflow 的可扩展性、伸缩性和性能。
可选的 worker，执行调度器分配的任务。在基础安装中，worker 可能是调度器的一部分，而非独立组件。它可以作为长时间运行的进程在 CeleryExecutor 中运行，或作为 POD 在 KubernetesExecutor 中运行。
可选的 triggerer，在 asyncio 事件循环中执行延迟任务。在基础安装中如果不使用延迟任务，则不需要 triggerer。有关任务延迟的更多信息，请参见 可延迟算子与触发器。
可选的 plugins 文件夹。插件是一种扩展 Airflow 功能的方式（类似于已安装的包）。插件由 调度器、Dag 处理器、triggerer 和 Web 服务器 读取。有关插件的更多信息，请参见 插件。
部署 Airflow 组件
所有组件都是 Python 应用程序，可以通过各种部署方式进行部署。
它们的 Python 环境中可以额外安装 已安装的包。例如，这可用于安装自定义算子或传感器，或通过自定义插件扩展 Airflow 功能。
虽然 Airflow 可以在单机上运行，仅部署 调度器 和 Web 服务器，但 Airflow 设计为可伸缩且安全，能够在分布式环境中运行——各组件可部署在不同机器上，拥有不同的安全边界，并可通过运行多个实例来扩展上述组件。
组件的分离还可提升安全性，通过将组件相互隔离并执行不同任务来实现。例如，将 Dag 处理器 与 调度器 分离，可确保调度器无法访问 Dag 文件，也无法执行由 Dag 作者 提供的代码。
此外，虽然单个人可以运行和管理 Airflow 安装，但在更复杂的部署中，可能涉及多种用户角色，这些角色可以交互系统的不同部分，这是安全部署 Airflow 的重要方面。这些角色在 Airflow 安全模型 中有详细描述，通常包括
部署管理员 — 负责安装、配置 Airflow 并管理部署的人
Dag 作者 — 编写 Dag 并提交至 Airflow 的人
运维用户 — 触发 Dag 与任务并监控其执行的人
架构图示
下面的示意图展示了部署 Airflow 的不同方式——从简单的“单机单人”部署逐步到拥有独立组件、独立用户角色，最终到更为隔离的安全边界的复杂部署。
下图中不同连接类型的含义如下
棕色实线 表示 Dag 文件 的提交与同步
蓝色实线 表示部署和访问 已安装的包 与 插件
黑色虚线 表示由 调度器（通过执行器）控制工作节点的流程
黑色实线 表示访问 UI 以管理工作流的执行
红色虚线 表示所有组件访问 元数据数据库
基础 Airflow 部署
这是最简的 Airflow 部署，通常在单台机器上运行和管理。此类部署通常使用 LocalExecutor，调度器与 worker 位于同一个 Python 进程中，Dag 文件 直接由调度器从本地文件系统读取。Web 服务器 与调度器运行在同一机器上。没有 triggerer 组件，这意味着无法使用任务延迟。
此类安装通常不区分用户角色——部署、配置、运维、编写和维护均由同一人完成，组件之间也不存在安全边界。
如果您希望在单机上以简易方式运行 Airflow，可跳过下面更复杂的示意图，直接查看 工作负载 部分。
分布式 Airflow 架构
这是 Airflow 各组件分布在多台机器上，并引入多种用户角色——部署管理员、Dag 作者、运维用户 的架构。有关这些角色的更多信息，请参阅 Airflow 安全模型。
在分布式部署中，需要关注组件的安全性。Web 服务器 并不直接访问 Dag 文件。UI 中 Code 标签的代码是从 元数据数据库 读取的。Web 服务器 不能执行由 Dag 作者 提交的代码，只能执行由 部署管理员 以 已安装的包 或 插件 形式安装的代码。运维用户 只能访问 UI，触发 Dag 与任务，但不能编写 Dag。
Dag 文件 需要在所有使用它们的组件之间同步——调度器、triggerer 和 worker。Dag 文件 可通过多种机制同步——典型的同步方式请参见我们 Helm Chart 文档中的 管理 Dag 文件。Helm Chart 是在 K8S 集群中部署 Airflow 的一种方式。
独立 Dag 处理架构
在安全性和隔离性重要的更复杂安装中，您会看到独立的 Dag 处理器 组件，它将 调度器 与访问 Dag 文件 分离。如果部署重点是任务解析的隔离，这非常适合。虽然 Airflow 目前尚未完全支持多租户功能，但可用来确保 Dag 作者 提供的代码永远不在调度器的上下文中执行。
注意
当 Dag 文件被修改时，可能出现调度器和 worker 看到不同版本的情况，直至两者同步。您可以通过在部署期间停用 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、触发规则 等特性进行自定义。
在任务之间传递数据有三种方式
Airflow 会在资源可用时将任务发送到 Worker 上执行，因此同一 Dag 中的任务不一定会在同一 Worker 或同一机器上运行。
随着 Dag 的构建变得更加复杂，Airflow 提供了多种机制以提升可维护性，例如 任务组 可在 UI 中直观地对任务进行分组。
用户界面
Airflow 提供了用户界面，您可以查看 Dag 及其任务的运行情况，触发 Dag 的运行，查看日志，并对 Dag 进行有限的调试和问题排查。
通常这是查看整个 Airflow 安装状态的最佳方式，也可以深入到单个 Dag，查看其布局、每个任务的状态以及任务日志。