Airflow 学习笔记1 -- 介绍和概念

介绍

Airflow是一个开源的工作流程管理平台，它使用Python编写，具有高度可扩展性和灵活性。它能够帮助你通过开发、定义、调度和监控工作流程来管理数据管道/工作流，从而使得数据的处理变得更加可靠、高效和可维护。 Airflow 的可扩展 Python 框架使您能够构建与几乎任何技术连接的工作流。 它拥有网页界面有助于管理工作流程的状态。
官网介绍

概念

1 DAG（Directed Acyclic Graph）有向无环图：

定义任务（Task）之间的依赖关系，用于表示工作流。

2 DAG Run

DAG Run 是一个代表 DAG 实例化对象。 每当执行 DAG 时，都会创建 DAG Run 并执行其中的所有Task。每个 DAG Run 都相互独立运行，这意味着您可以同时运行多个 DAG。

3 Task 任务

任务是 Airflow 中的基本执行单元。 任务被安排到 DAG 中，然后在它们之间设置上游和下游依赖关系，以表达它们应该运行的顺序。与 DAG 每次运行时被实例化为 DAG Run 的方式非常相似，DAG 下的任务被实例化为任务实例。以下是三种类型的Task

2.1 Operators

预定义的任务模板，您可以将它们快速串在一起以构建 DAG 的大部分。

3.2 Sensors

Sensors 是 Operator 的一个特殊子类，它完全是关于等待外部事件发生的。

3.3 TaskFlow

一个 TaskFlow 修饰的 @task，它是一个打包为任务的自定义 Python 函数。

3.4 Task状态

Task 的实例是该任务针对给定 DAG（因此对于给定数据间隔）的特定运行。 它们也是具有状态的任务的表示，表示它处于生命周期的哪个阶段。Task实例的可能状态是：

none：任务尚未排队等待执行（尚未满足其依赖性）

scheduled：调度程序已确定满足任务的依赖关系并且应该运行

queued：任务已分配给执行者并正在等待工作人员

running：任务正在 worker 上运行（或在 local/synchronous executor）

success：任务完成运行没有错误

shutdown：任务运行时被外部请求关闭

restarting：任务在运行时被外部请求重启

failed：任务在执行过程中出错，未能运行

skipped：由于分支、LatestOnly 或类似原因，任务被跳过。

upstream_failed：上游任务失败，触发规则说我们需要它

up_for_retry：任务失败，但还有重试次数，将重新安排。

up_for_reschedule：任务是一个处于重新调度模式的传感器

deferred：任务已被推迟到触发器

removed：任务自运行开始后已从 DAG 中消失

理想情况下，任务应该从none到scheduled、queued、running，最后到success。

3.5 任务关系

任务关系是指任务之间的依赖关系，即前置任务执行完成后，后续任务才能执行的关系。任务之间的依赖可以是单向依赖，也可以是双向依赖。任务之间的依赖关系可以通过设置任务的 upstream 和 downstream 属性来定义。upstream 指的是当前任务的前置任务，downstream 指的是当前任务的后继任务。默认情况下，Task将在其所有上游（父）任务都成功时运行。Task不会相互传递信息，而是完全独立运行。 如果你想将信息从一个Task传递到另一个Task，要考虑使用 XComs。

# 方法一
a_task.set_downstream(b)
b_task.set_downstream(d)
d_task.set_upstream(c)
c_task.set_upstream(a)
# 方法二
a_task >> [b_task, c_task] >> d_task

4 Scheduler 调度程序

Scheduler 监控所有Task和 DAG，然后在它们的依赖关系完成后，触发Task实例。 在后台，Scheduler 启动了一个子进程，该子进程监视指定 DAG 目录中的所有 DAG 并与之保持同步。 默认情况下，调度程序每分钟收集一次 DAG 解析结果并检查是否有任何active task可以被触发。

5 Executor 执行器

Airflow 一次只能配置一个执行器； 这是由配置文件的 [core] 部分中的 executor 选项设置的。

5.1 种类

有两种类型的执行器 - 那些在本地运行任务（在scheduler进程内），以及那些远程运行Task（通常通过pool of workers 工作池）。 Airflow 默认配置了 SequentialExecutor，这是一个本地执行器，也是最安全的执行选项，但强烈建议将其更改为 LocalExecutor 用于小型单机安装，或远程执行器之一用于多机 /云安装。

5.1.1 本地执行器

• Testing DAGs with dag.test()
• Debugging Airflow DAGs on the command line
• Debug Executor (deprecated)
• Local Executor
• Sequential Executor

5.1.2 远程执行器

• Celery Executor
• CeleryKubernetes Executor
• Dask Executor
• Kubernetes Executor
• LocalKubernetes Executor

6 WebServer（UI）

Airflow提供的Web界面，用于展示DAG和任务的状态，并提供操作和管理Airflow的各种功能。

下面只最简单的本地执行器的流程图，在默认的 Airflow 安装中，会在Scheduler中运行所有内容，但大多数适合生产的执行程序实际上会将Task执行推送给worker。

metadata database 元数据库（一般用MySQL或者Postgresql）, scheduler, executor，webserver 用来存储状态。

下面是使用了远程执行器的流程图

（worker可以理解是执行Task的具体进程）

7 流程

Airflow 执行一个 DAG的整个流程通常如下：
在Airflow中，scheduler定期扫描DAG，检查Task之间的依赖关系和状态，决定哪些任务需要运行，然后将Task发送给Executor。Executor负责将Task提交到worker上执行，worker执行完Task后将结果返回给Executor，Executor再将结果保存到meta DB中。通过这个过程，Airflow实现了任务的调度和执行，并将所有Task的状态和运行结果保存在meta DB中，方便后续的任务管理和监控。