前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >大数据调度平台Airflow(二):Airflow架构及原理

大数据调度平台Airflow(二):Airflow架构及原理

作者头像
Lansonli
修改2022-09-18 00:51:48
5.9K1
修改2022-09-18 00:51:48
举报
文章被收录于专栏:Lansonli技术博客

Airflow架构及原理

一、Airflow架构

Airflow我们可以构建Workflow工作流,工作流使用DAG有向无环图来表示,DAG指定了任务之间的关系,如下图:

Airflow架构图如下:

Airflow在运行时有很多守护进程,这些进程提供了airflow全部功能,守护进程包括如下:

  • webserver:

WebServer服务器可以接收HTTP请求,用于提供用户界面的操作窗口,主要负责中止、恢复、触发任务;监控任务;断点续跑任务;查询任务状态、详细日志等。

  • Scheduler:

调度器,负责周期性调度处理工作流,并将工作流中的任务提交给Executor执行。

  • Executor:

执行器,负责运行task任务,在默认本地模式下(单机airflow)会运行在调度器Scheduler中并负责所有任务的处理。但是在airflow集群模式下的执行器Executor有很多类型,负责将任务task实例推送给Workers节点执行。

在Airflow中执行器有很多种选择,最关键的执行器有以下几种:

  • SequentialExecutor:默认执行器,单进程顺序执行任务,通常只用于测试。
  • LocalExecutor:多进程本地执行任务。
  • CeleryExecutor:分布式执行任务,多用于生产场景,使用时需要配置消息队列。
  • DaskExecutor:动态任务调度,支持远程集群执行airflow任务。

生产环境中建议使用CeleryExecutor作为执行器,Celery是一个分布式调度框架,本身无队列功能,需要使用第三方插件,例如:RabbitMQ或者Redis。

关于不同Executor类型可以参考官网:https://airflow.apache.org/docs/apache-airflow/stable/executor/index.html

  • work:

Worker负责执行具体的DAG任务,会启动1个或者多个Celery任务队列,当ariflow的Executor设置为CeleryExecutor时才需要开启Worker进程。

  • DAG Directory:

存放定义DAG任务的Python代码目录,代表一个Airflow的处理流程。需要保证Scheduler和Executor都能访问到。

  • metadata database:

Airflow的元数据库,用于Webserver、Executor及Scheduler存储各种状态数据,通常是MySQL或PostgreSQL。

二、Airflow术语

  • DAG

DAG是Directed Acyclic Graph有向无环图的简称,描述其描述数据流的计算过程。

  • Operators

描述DAG中一个具体task要执行的任务,可以理解为Airflow中的一系列“算子”,底层对应python class。不同的Operator实现了不同的功能,如:BashOperator为执行一条bash命令,EmailOperator用户发送邮件,HttpOperators用户发送HTTP请求,PythonOperator用于调用任意的Python函数。

  • Task

Task是Operator的一个实例,也就是DAG中的一个节点,在某个Operator的基础上指定具体的参数或者内容就形成一个Task,DAG中包含一个或者多个Task。

  • Task Instance

task每一次运行对应一个Task Instance,Task Instance有自己的状态,例如:running,success,failed,skipped等。

  • Task Relationships:

一个DAG中可以有很多task,这些task执行可以有依赖关系,例如:task1执行后再执行task2,表明task2依赖于task1,这就是task之间的依赖关系。

三、​​​​​​​Airflow工作原理

airflow中各个进程彼此之间是独立不互相依赖,也不互相感知,每个进程在运行时只处理分配到自身的任务,各个进程在一起运行,提供了Airflow全部功能,其工作原理如下:

  1. 调度器Scheduler会间隔性轮询元数据库(Metastore)已注册的DAG有向无环图作业流,决定是否执行DAG,如果一个DAG根据其调度计划需要执行,Scheduler会调度当前DAG并触发DAG内部task,这里的触发其实并不是真正的去执行任务,而是推送task消息到消息队列中,每一个task消息都包含此task的DAG ID,Task ID以及具体需要执行的函数,如果task执行的是bash脚本,那么task消息还会包含bash脚本代码。
  2. Worker进程将会监听消息队列,如果有消息就从消息队列中获取消息并执行DAG中的task,如果成功将状态更新为成功,否则更新成失败。
  3. 用户可以通过webserver webui来控制DAG,比如手动触发一个DAG去执行,手动触发DAG与自动触发DAG执行过程都一样。
本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2022/03/20 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Airflow架构及原理
    • 一、Airflow架构
      • 二、Airflow术语
        • 三、​​​​​​​Airflow工作原理
        相关产品与服务
        消息队列 CMQ 版
        消息队列 CMQ 版(TDMQ for CMQ,简称 TDMQ CMQ 版)是一款分布式高可用的消息队列服务,它能够提供可靠的,基于消息的异步通信机制,能够将分布式部署的不同应用(或同一应用的不同组件)中的信息传递,存储在可靠有效的 CMQ 队列中,防止消息丢失。TDMQ CMQ 版支持多进程同时读写,收发互不干扰,无需各应用或组件始终处于运行状态。
        领券
        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档