架构概述¶
Airflow 是一个允许您构建和运行*工作流*的平台。工作流由一个 DAG（有向无环图）表示，包含称为 任务 的独立工作单元，这些单元根据依赖关系和数据流进行安排。
DAG 指定了任务之间的依赖关系，定义了任务的执行顺序。任务描述了要做什么，无论是获取数据、运行分析、触发其他系统等等。
Airflow 本身与您运行的内容无关——它可以愉快地编排和运行任何内容，无论是通过我们提供商的高级支持，还是直接使用 Shell 或 Python Operator 作为命令。
Airflow 组件¶
Airflow 的架构由多个组件组成。以下部分描述了每个组件的功能，以及它们是 Airflow 最基本安装所需的必需组件，还是为了实现更好的 Airflow 扩展性、性能和可伸缩性而提供的可选组件。
必需组件¶
最基本的 Airflow 安装包括以下组件
一个 调度器 (scheduler)，它负责触发调度的工作流，并将 任务 (Task) 提交给 Executor 运行。Executor 是*调度器*的一个配置属性，而不是一个独立的组件，它运行在调度器进程内部。有多种 Executor 可供选择，您也可以编写自己的 Executor。
一个*DAG 处理器 (dag processor)*，它解析 DAG 文件并将其序列化到*元数据数据库*中。有关处理 DAG 文件的更多信息，请参见 DAG 文件处理
一个*Web 服务器 (webserver)*，它提供了一个方便的用户界面来检查、触发和调试 DAGs 和任务的行为。
一个*DAG 文件*文件夹，供*调度器*读取，以确定要运行哪些任务以及何时运行。
一个*元数据数据库 (metadata database)*，Airflow 组件用它来存储工作流和任务的状态。有关设置元数据数据库的信息，请参见 设置数据库后端，这是 Airflow 工作的必需步骤。
可选组件¶
一些 Airflow 组件是可选的，可以提高 Airflow 的扩展性、可伸缩性和性能
可选的*工作进程 (worker)*，它执行调度器分配给它的任务。在基本安装中，工作进程可能是调度器的一部分，而不是一个独立的组件。它可以在 CeleryExecutor 中作为常驻进程运行，或者在 KubernetesExecutor 中作为 Pod 运行。
可选的*触发器 (triggerer)*，它在 asyncio 事件循环中执行延迟任务。在不使用延迟任务的基本安装中，触发器不是必需的。有关延迟任务的更多信息，请参见 可延迟 Operator & 触发器。
可选的*插件 (plugins)*文件夹。插件是一种扩展 Airflow 功能的方式（类似于安装的软件包）。插件由*调度器*、*DAG 处理器*、*触发器*和*Web 服务器*读取。有关插件的更多信息，请参见 插件。
部署 Airflow 组件¶
所有组件都是 Python 应用程序，可以使用各种部署机制进行部署。
它们可以在其 Python 环境中安装额外的*已安装软件包 (installed packages)*。例如，这对于安装自定义 Operator 或 Sensor，或使用自定义插件扩展 Airflow 功能非常有用。
虽然 Airflow 可以在单台机器上通过仅部署*调度器*和*Web 服务器*的简单安装运行，但 Airflow 设计为可伸缩且安全，并且能够在分布式环境中运行——其中各种组件可以在不同的机器上运行，具有不同的安全边界，并且可以通过运行上述组件的多个实例来进行伸缩。
组件的分离也有助于提高安全性，通过将组件彼此隔离并允许执行不同的任务。例如，将*DAG 处理器*与*调度器*分离可以确保调度器无法访问*DAG 文件*，也无法执行由*DAG 作者 (DAG author)*提供的代码。
此外，虽然单个人可以运行和管理 Airflow 安装，但在更复杂的设置中，Airflow 部署可能涉及与系统不同部分交互的各种用户角色，这是安全 Airflow 部署的重要方面。这些角色在 Airflow 安全模型 中有详细描述，通常包括：
部署管理器 (Deployment Manager) - 负责安装和配置 Airflow 并管理部署的人员
DAG 作者 (DAG author) - 编写 DAGs 并将其提交到 Airflow 的人员
运维用户 (Operations User) - 触发 DAGs 和任务并监控其执行的人员
架构图¶
下图展示了 Airflow 的不同部署方式——从简单的“单机”和单人部署，逐步演变为具有独立组件、独立用户角色以及最终具有更隔离安全边界的更复杂部署。
下图中不同连接类型的含义如下
棕色实线 表示*DAG 文件*的提交和同步
蓝色实线 表示部署和访问*已安装软件包*和*插件*
黑色虚线 表示*调度器*通过 Executor 对*工作进程*的控制流
黑色实线 表示访问 UI 管理工作流的执行
红色虚线 表示所有组件访问*元数据数据库*
基本 Airflow 部署¶
这是最简单的 Airflow 部署，通常在单台机器上操作和管理。这种部署通常使用 LocalExecutor，其中*调度器*和*工作进程*在同一个 Python 进程中，并且*调度器*直接从本地文件系统读取*DAG 文件*。*Web 服务器*与*调度器*在同一台机器上运行。没有*触发器*组件，这意味着无法进行任务延迟。
这种安装通常不区分用户角色——部署、配置、操作、编写和维护都由同一个人完成，组件之间没有安全边界。
如果您想在单台机器上以简单的单机设置运行 Airflow，可以跳过下面更复杂的图表，直接转到 工作负载 部分。
分布式 Airflow 架构¶
这是 Airflow 的分布式架构，Airflow 的组件分布在多台机器上，并引入了各种用户角色——*部署管理器*、*DAG 作者*、*运维用户*。您可以在 Airflow 安全模型 中阅读有关这些不同角色的更多信息。
在分布式部署的情况下，考虑组件的安全性方面非常重要。*Web 服务器*无法直接访问*DAG 文件*。UI 中“代码”选项卡中的代码是从*元数据数据库*中读取的。*Web 服务器*无法执行由*DAG 作者*提交的任何代码。它只能执行由*部署管理器*安装为*已安装软件包*或*插件*的代码。*运维用户*只能访问 UI，并且只能触发 DAGs 和任务，但不能编写 DAGs。
*DAG 文件*需要在所有使用它们的组件之间同步——*调度器*、*触发器*和*工作进程*。*DAG 文件*可以通过各种机制进行同步——有关 DAGs 如何同步的典型方法在我们的 Helm Chart 文档中的 管理 DAG 文件 中有描述。Helm Chart 是在 K8S 集群中部署 Airflow 的一种方式。
DAG 处理分离架构¶
在更复杂的安装中，如果安全性与隔离性非常重要，您还会看到独立的*DAG 处理器*组件，它允许将*调度器*与访问*DAG 文件*分开。如果部署重点是解析任务之间的隔离，这种架构就很适合。虽然 Airflow 尚未完全支持多租户功能，但它可用于确保*DAG 作者*提供的代码永远不会在调度器的上下文中执行。
注意
当 DAG 文件更改时，可能会出现调度器和工作进程看到不同版本的 DAG 的情况，直到两个组件都同步完成。您可以通过确保在部署期间停用 DAG，并在完成后重新激活来避免此问题。如果需要，可以配置 DAG 文件夹的同步和扫描频率。如果您更改配置，请确保您清楚自己在做什么。
工作负载¶
DAG 通过一系列 任务 运行，您会看到三种常见的任务类型：
Operator，预定义的任务，您可以快速将它们串联起来构建大部分 DAG。
Sensor，Operator 的一个特殊子类，专门用于等待外部事件发生。
一个由 TaskFlow 装饰器
@task标记的任务，它是一个打包成任务的自定义 Python 函数。
在内部，这些实际上都是 Airflow 的 BaseOperator 的子类，Task 和 Operator 的概念在某种程度上可以互换，但将它们视为独立的概览很有用——本质上，Operator 和 Sensor 是*模板*，当您在 DAG 文件中调用其中一个时，您正在创建一个 Task。
控制流¶
DAGs 被设计为可以多次运行，并且可以并行进行多次运行。DAGs 是参数化的，总是包含它们“运行的”时间间隔（数据间隔），但也包含其他可选参数。
任务 之间声明了依赖关系。您会在 DAG 中看到这一点，例如使用 >> 和 << Operator
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 如何确定任务执行顺序的方式。默认情况下，一个任务会等待其所有上游任务成功后才会运行，但可以使用诸如 分支 (Branching)、只运行最新 (LatestOnly) 和 触发规则 (Trigger Rules) 等功能进行定制。
在任务之间传递数据，您有三个选项
XComs（“跨任务通信”），一个系统，任务可以在其中推送和拉取少量元数据。
从存储服务（无论是您自己运行的还是公共云的一部分）上传和下载大文件
TaskFlow API 通过隐式的 XComs 自动在任务之间传递数据
Airflow 会在*工作进程*空间可用时将任务发送给它们运行，因此无法保证 DAG 中的所有任务都在同一个工作进程或同一台机器上运行。
随着您构建 DAGs，它们可能会变得非常复杂，因此 Airflow 提供了几种机制使其更易于维护，例如 TaskGroups 允许您在 UI 中直观地对任务进行分组。
此外，还有一些功能允许您轻松预配置对中央资源（如数据存储）的访问，形式为 连接 & Hook (Connections & Hooks)，以及通过 连接池 (Pools) 限制并发性。
用户界面¶
Airflow 提供了一个用户界面，您可以查看 DAGs 及其任务的执行情况，触发 DAG 运行，查看日志，并对 DAG 问题进行一些有限的调试和解决。
这通常是查看整个 Airflow 安装状态的最佳方式，也可以深入查看单个 DAGs，了解其布局、每个任务的状态以及每个任务的日志。