Airflow Apache 架构

引言

Apache Airflow 是一个开源平台，它使用户能够以编程方式创作、调度和监控工作流。它旨在通过将复杂的工作流分解为小型、可管理的任务来帮助自动化这些工作流，主要用于数据工程领域。这些任务可以使用有向无环图 (DAG) 进行调度和编排，DAG 定义了依赖关系和执行顺序。

Airflow 的架构高度模块化且分布式，使其能够处理各种任务，从简单的脚本到大规模的数据管道。其架构包含几个核心组件，包括调度器 (Scheduler)、工作节点 (workers)、元数据数据库 (metadata database) 和 Web 服务器 (web server)，每个组件在工作流管理过程中都扮演着独特的角色。

架构

Apache Airflow 中的有向无环图 (DAG)，用于管理工作流。在这种特定情况下，DAG 代表了一系列具有特定操作符的任务（用粉色框表示），这些操作符可能定义了工作流的逻辑。

以下是对图中元素的细分

任务

每个框代表一个任务。Empty Operator (空操作符) 的标签表明这些是占位符，可能用于稍后添加的更复杂的任务。我们来逐个任务进行说明：

• Ingest (提取): 此任务可能涉及将数据从源提取到处理管道中。
• Analyse (分析): 在提取数据之后，此任务可能涉及以某种形式对提取的数据进行分析或处理。
• Check integrity (检查完整性): 此任务似乎用于验证数据的完整性，确保数据完整、准确或未损坏。
• Describe integrity (描述完整性): 在检查完完整性后，此任务可能负责记录或汇总完整性检查的结果。
• Email error (发送错误邮件): 如果在工作流中发生任何错误（可能在完整性检查期间），此任务将负责通过电子邮件通知相关人员。
• Save (保存): 在数据经过分析和验证后，此任务可能涉及保存最终处理后的数据。
• Report (报告): 此最终任务将生成并存储整个工作流或处理运行的报告。

工作流逻辑

任务之间的箭头代表执行流程。

• 工作流以 ingest (提取) 开始，然后是 analyze (分析)，接着是 check integrity (检查完整性)。
• 在 check integrity (检查完整性) 之后有一个分支：
  • 如果完整性检查通过，工作流将进入 same (相同) 任务，最后生成 report (报告)。
  • 如果完整性存在问题，工作流将触发 describe integrity (描述完整性) 任务，然后发送 an email error (错误邮件) 来通知相关人员问题。

它的工作原理

1. Ingest (提取): 第一步很可能是将数据提取到管道中，无论是从外部数据库、API 还是其他数据源。
2. Analyse (分析): 此任务处理或分析提取的数据，将其转换为有效格式。
3. Check Integrity (检查完整性): 确保处理后的数据符合某些完整性要求，例如一致性、准确性和完整性。
4. 分支逻辑
   • 如果数据通过完整性检查，将继续进行保存和报告。
   • 如果完整性检查失败，工作流将分支到描述完整性问题，并发送一封电子邮件来报告错误。
5. Save and Report (保存和报告): 如果一切顺利，数据将被保存，并创建操作报告。

此 DAG 代表 Apache Airflow 中的一个数据管道，其中包含数据提取、分析、验证、错误报告和最终存储的任务。逻辑流程包括错误处理，管道可以根据完整性检查是否通过或失败而分支。

Airflow 组件交互

此图深入探讨了 Apache Airflow 的组件级架构。主要角色包括 DAG 作者 (DAG Author)、部署管理器 (Deployment Manager) 和运维用户 (Operations User)，并强调了这些参与者如何与 Airflow 系统的关键组件进行交互。

DAG 作者 (DAG Author)

• DAG (有向无环图) 作者负责通过编写 DAG 文件来创建工作流。
• 这些 DAG 文件通常用 Python 编写，定义了任务序列、它们的依赖关系和调度间隔。
• DAG 文件被同步到系统进行处理。

部署管理器 (Deployment Manager)

• 此角色负责设置和维护运行 Apache Airflow 所需的基础设施。
• 部署管理器安装了执行 DAG 所需的必要插件、依赖项和软件包，例如外部库、自定义操作符和钩子。
• 这些安装应用于核心 Airflow 组件，使工作流能够与数据库、云存储或 API 等外部服务进行交互。

运维用户 (Operations User)

• 运维用户通过 Airflow 的 **UI** 与系统交互，以监控工作流执行和管理任务。
• 他们可以手动触发任务、暂停 DAG、检查日志并在任务失败时进行故障排除。
• 运维用户不编写 DAG，而是部署工作流后进行操作。
• DAG 文件是 Airflow 的核心。它们包含工作流的逻辑，包括需要执行的任务以及它们之间的依赖关系。
• DAG 文件存储在一个中央存储库中，调度器和其他组件可以访问。

元数据数据库

• 元数据数据库 (Metadata DB) 存储有关任务和 DAG 状态的关键信息。
• 它充当执行历史、任务状态、调度信息和配置的中央事实来源。
• Airflow 中的每个组件（调度器、工作节点、Web 服务器）都与元数据数据库交互以检索或更新任务状态。

执行组件 (Execution Components)

• Worker (工作节点): 工作节点是执行 DAG 中定义的单个任务的实体。
• 它们负责实际运行任务的代码并将状态更新到元数据数据库。
• Trigger (触发器): 触发器是处理基于事件的调度的专用组件。它们监听外部事件并在满足条件时唤醒任务。
• DAG Processor (DAG 处理器): DAG 处理器读取 DAG 文件，对其进行解析，并准备好执行。它将 DAG 定义同步到调度器和其他组件。

调度组件 (Scheduling Components)

• Scheduler (调度器): 调度器根据 DAG 的调度逻辑协调任务的执行。它扫描 DAG 以查找需要执行的任务，并将它们排队以供执行。
• Executor (执行器): 执行器负责管理任务如何分发和执行。根据使用的执行器类型（例如，Celery Executor、Kubernetes Executor），任务可以分发到多个工作节点甚至不同的集群。
• Web 服务器提供了一个用户友好的 UI，允许运维用户与 Airflow 系统进行交互。

DAG 编写和同步

• DAG 作者创建定义工作流逻辑、任务依赖关系和调度的 DAG 文件。
• 然后，这些 DAG 文件与 DAG 处理器同步，DAG 处理器解析它们并使其可供执行。

调度和任务执行

• 调度器读取 DAG，确定哪些任务需要执行，并使用执行器将它们分配给工作节点。
• 任务由工作节点拾取并执行。结果（成功或失败）写回元数据数据库。
• 对于基于事件的任务，触发器会监听特定条件，当条件满足时，执行器会调度任务。

操作管理

• 运维用户使用 UI 来监控任务进度。他们可以检查日志、监控任务状态，并在必要时进行干预（例如，重新运行失败的任务、暂停/恢复 DAG）。
• Web 服务器作为运维用户与元数据数据库之间的接口，提供工作流执行的实时更新。

使用执行器优化 Airflow 处理

这呈现了稍微简化的架构版本，重点关注核心调度、任务执行和监控流程。关键组件保持不变，但交互被简化以强调调度器和工作节点的作用。

DAG 作者、部署管理器和运维用户

• 这里看到了类似的角色，DAG 作者定义工作流，部署管理器管理基础设施，运维用户监控和管理任务执行。
• 触发器 (Trigger(s)): 处理基于事件的任务，这些任务在满足特定条件时执行（例如，文件到达文件夹或某个传感器被触发）。
• 调度器 (Scheduler(s)): 通过读取 DAG 并将任务发送给工作节点来协调任务的整体执行。
• 工作节点 (Worker(s)): 执行实际任务。它们从 DAG 中提取任务定义并将状态更新到元数据数据库。

元数据数据库

• 元数据数据库继续存储 DAG、任务和执行历史的状态。
• 它充当调度器、工作节点和 Web 服务器之间的中央通信点。

Web 服务器 (UI)

• Web 服务器为运维用户提供了一个 UI，用于与工作流进行交互和监控。
• 运维用户使用 Web 界面检查 DAG 运行、查看日志，并在必要时手动触发任务。

DAG 编写和同步: DAG 作者创建 DAG 文件，并将其与系统同步。

• 调度器读取这些 DAG 以计划和调度任务执行。

调度和执行: 调度器扫描 DAG 以查找需要运行的任务，并使用执行器将它们分配给工作节点。

• 工作节点执行任务，并将任务的状态（成功、失败、重试等）更新到元数据数据库。

监控和 UI 交互

• 运维用户使用 Web 服务器（显示从元数据数据库检索的信息）来监控 DAG 和任务的状态。
• 通过 UI 可以访问日志、任务状态和执行时间，用户可以通过触发或暂停任务与工作流进行交互。

简化的 Airflow 架构

此图呈现了 Airflow 架构的简化概述，整合了组件以提供对 Airflow 如何运行的高级理解。主要角色包括 **Airflow 用户 (Airflow User)**，他负责编写和监控工作流。

DAG 文件

• Airflow 用户编写定义任务及其依赖关系的 DAG 文件。
• 调度器读取这些 DAG 文件以确定工作流应如何执行。

调度器

• 调度器解析 DAG 文件，规划任务执行，并与工作节点交互以管理任务执行。
• 它与元数据数据库通信，以更新任务和 DAG 运行的状态。

Web 服务器 (UI)

• Web 服务器 为 **Airflow 用户** 提供了一个 UI，用于监控和管理工作流。
• 通过 UI，用户可以看到 DAG 执行状态、检查日志并与系统交互（例如，触发 DAG 运行或重新运行失败的任务）。

插件文件夹和已安装的软件包

• Airflow 允许使用自定义插件来扩展其功能。这些插件可以包括自定义操作符、传感器、钩子和执行器。
• Airflow 用户可以安装这些插件和外部库，使 Airflow 能够与云提供商、数据库和 API 等外部系统进行交互。

元数据数据库

• 元数据数据库继续作为跟踪 DAG 和任务状态的中央存储库。
• 它存储有关工作流执行、任务状态和日志的历史数据。

系统流程

DAG 编写

• Airflow 用户创建 DAG 文件并将其上传到系统。调度器解析这些 DAG 并确定任务应运行的顺序。

任务调度和执行

• 调度器根据 DAG 的逻辑调度任务，并将任务发送给工作节点 (Worker) 执行。
• 随着任务的执行，它们的 **元数据数据库** 中的状态会被更新。

监控和运维

• Airflow 用户使用 Web 服务器 (UI) 来监控任务执行。UI 从元数据数据库中提取数据以显示 DAG 运行的实时信息。
• 用户可以通过暂停/恢复 DAG、重新运行任务和检查日志来与系统进行交互。
• 它们提供了对 Apache Airflow 架构的不同视角，从组件之间的详细交互到简化的、高级的视图。

注意

当修改 DAG 文件时，可能会出现调度器和工作节点暂时使用不同版本的 DAG 的情况，直到两个组件同步。为避免潜在问题，建议在部署期间停用 DAG，并在更改完成后重新激活它。如有必要，您可以调整 DAG 文件夹的同步和扫描间隔的频率。但是，在修改这些配置时要小心，并确保您完全理解任何更改的影响。

当修改 DAG 文件时，可能会出现调度器和工作节点暂时使用不同版本的 DAG 的情况，直到两个组件同步。为避免潜在问题，建议在部署期间停用 DAG，并在更改完成后重新激活它。如有必要，您可以调整 DAG 文件夹的同步和扫描间隔的频率。但是，在修改这些配置时要小心，并确保您完全理解任何更改的影响。