airflow架构详解

关于airflow，大家应该很清楚它是干嘛的，怎么使用，那么它底层的调度原理到底是啥样的呢？
我大概从2018年下半年，开始使用airflow，第一次使用时，是团队一起调研的，所以，从搭建，到基本使用，再到参数优化，都是经历过的。

后面进入到另一家公司，也是由于我使用过airflow调度系统才找我进去的，所以会使用airflow调度系统，也算一个优势吧。
在这家公司的话，对airflow的使用，就详细到了每一个功能，包括血缘，与atlas结合、升级、参数化等。于是对airflow有了更深入的了解。

今天就为大家介绍airflow的架构，下面来看看。

如果不清楚，可以看一看我的另一篇介绍文章：
airflow介绍

先画一张架构图来看：

先介绍下各个角色的作用吧

• scheduler: 任务调度，不停轮询编译dag文件，发送可执行的任务到消息队列中，将dag信息和调度信息写入mysql中，不停更新dag状态；
• webserver: 提供web ui界面的dag操作，dag任务的启停，task的运行管理等，查看task的运行情况；
• worker: 具体执行任务的节点，从celery消费获取到task执行命令，执行对于的脚本语句。将task执行情况写入mysql中；
• rabbitmq/redis: 消息队列，接收从scheduler端发送过来的task执行命令，等待worker端的celery去消费task；

Dag调度原理

airflow以dag为调度单位，一个dag包含一个或多个task。
dag文件定义了dag的调度详情，其中包含dag的基本信息和dag中task的基本信息。
scheduler不停地编译dag文件，根据dag文件中的crontab表达式、dag运行的历史记录、dag的开关状态，去发现哪些dag需要进行调度，发现了dag需要调度，立马新增一个dag_run实例，修改为running状态，接着不停地调度该dag中的task。
dag的生命周期分为：

none
running
success
failed

正常生命周期的task分为以下几个状态：

none
scheduled
queued
running
success

异常生命周期的task分为：

up_for_retry
failed
shutdown

Task运行原理

scheduler发送每一个可以运行的task任务命令（运行参数、脚本）到消息队列中，然后继续去发现待运行的dag，task的执行就不管了。
airflow worker这个角色，每个worker对应一个celery服务，celery就是分布式任务队列，它也是一个服务，不停地去消费队列中的task任务命令，去执行这些命令、脚本。
当任务执行完之后，就将结果写入到后台元数据库中。

嗯，今天就这样，大概讲了下dag是如何调度的，下次带大家详细了解airflow的元数据库。

关注我，我会持续输出一个airflow的专栏，详细讲解airflow相关的技术，希望对大家有帮助。

airflow调度系统，yyds。

---

书山有路勤为径，学海无涯苦作舟。

欢迎关注我的微信公众号，比较喜欢分享知识，也喜欢宠物，所以做了这2个公众号：

喜欢宠物的朋友可以关注：【电巴克宠物Pets】

一起学习，一起进步。