DataStrategy

——合抱之木,生于毫末;九层之台,起于累土

【原创】Airflow 简介&如何部署一个健壮的 apache-airflow 调度系统

声明

本文摘录了很多前辈的文章,原文如下:

https://www.jianshu.com/p/2ecef979c606


Airflow 简介

Airflow是一个可编程,调度和监控的工作流平台,基于有向无环图(DAG),airflow可以定义一组有依赖的任务,按照依赖依次执行。airflow提供了丰富的命令行工具用于系统管控,而其web管理界面同样也可以方便的管控调度任务,并且对任务运行状态进行实时监控,方便了系统的运维和管理。

基本概念

airflow守护进程

airflow 系统在运行时有许多守护进程,它们提供了 airflow 的全部功能。守护进程包括 Web服务器-webserver、调度程序-scheduler、执行单元-worker、消息队列监控工具-Flower等。下面是 apache-airflow 集群、高可用部署的主要守护进程。

webserver

webserver 是一个守护进程,它接受 HTTP 请求,允许你通过 Python Flask Web 应用程序与 airflow 进行交互,webserver 提供以下功能:

  • 中止、恢复、触发任务。
  • 监控正在运行的任务,断点续跑任务。
  • 执行 ad-hoc 命令或 SQL 语句来查询任务的状态,日志等详细信息。
  • 配置连接,包括不限于数据库、ssh 的连接等。

webserver 守护进程使用 gunicorn 服务器(相当于 java 中的 tomcat )处理并发请求,可通过修改{AIRFLOW_HOME}/airflow.cfg文件中 workers 的值来控制处理并发请求的进程数。

例如:

workers = 4 #表示开启4个gunicorn worker(进程)处理web请求

启动 webserver 守护进程:

$ airflow webserver -D

scheduler

scheduler 是一个守护进程,它周期性地轮询任务的调度计划,以确定是否触发任务执行。

启动的 scheduler 守护进程:

$ airflow scheduler -D

worker

worker 是一个守护进程,它启动 1 个或多个 Celery 的任务队列,负责执行具体 的 DAG 任务。

当设置 airflow 的 executors 设置为 CeleryExecutor 时才需要开启 worker 守护进程。

推荐你在生产环境使用 CeleryExecutor :

executor = CeleryExecutor

启动一个 worker守护进程,默认的队列名为 default:

$ airflow worker -D

flower

flower 是一个守护进程,用于是监控 celery 消息队列。启动守护进程命令如下:

$ airflow flower -D

默认的端口为 5555,您可以在浏览器地址栏中输入 "http://hostip:5555" 来访问 flower ,对 celery 消息队列进行监控。

执行器(Executor)

Airflow本身是一个综合平台,它兼容多种组件,所以在使用的时候有多种方案可以选择。比如最关键的执行器就有四种选择:

  • SequentialExecutor:单进程顺序执行任务,默认执行器,通常只用于测试
  • LocalExecutor:多进程本地执行任务
  • CeleryExecutor:分布式调度,生产常用
  • DaskExecutor :动态任务调度,主要用于数据分析

生产环境建议使用CeleryExecutor作为执行器。

celery是一个分布式调度框架,其本身无队列功能,需要使用第三方组件,比如redis或者rabbitmq。

核心概念

  • DAGs:即有向无环图(Directed Acyclic Graph),将所有需要运行的tasks按照依赖关系组织起来,描述的是所有tasks执行顺序。
  • Operators:可以简单理解为一个class,描述了DAG中某个的task具体要做的事。其中,airflow内置了很多operators,如BashOperator 执行一个bash 命令,PythonOperator 调用任意的Python 函数,EmailOperator 用于发送邮件,HTTPOperator 用于发送HTTP请求, SqlOperator 用于执行SQL命令等等,同时,用户可以自定义Operator,这给用户提供了极大的便利性。
  • Tasks:Task 是 Operator的一个实例,也就是DAGs中的一个node。
  • Task Instance:task的一次运行。Web 界面中可以看到task instance 有自己的状态,包括"running", "success", "failed", "skipped", "up for retry"等。
  • Task Relationships:DAGs中的不同Tasks之间可以有依赖关系,如 Task1 >> Task2,表明Task2依赖于Task2了。

通过将DAGs和Operators结合起来,用户就可以创建各种复杂的 工作流(workflow)。

操作符-Operators

DAG 定义一个作业流,Operators 则定义了实际需要执行的作业。airflow 提供了许多 Operators 来指定我们需要执行的作业:

  • BashOperator - 执行 bash 命令或脚本。
  • SSHOperator - 执行远程 bash 命令或脚本(原理同 paramiko 模块)。
  • PythonOperator - 执行 Python 函数。
  • EmailOperator - 发送 Email。
  • HTTPOperator - 发送一个 HTTP 请求。
  • MySqlOperator, SqliteOperator, PostgresOperator, MsSqlOperator, OracleOperator, JdbcOperator, 等,执行 SQL 任务。
  • DockerOperator, HiveOperator, S3FileTransferOperator, PrestoToMysqlOperator, SlackOperator 你懂得。除了以上这些 Operators 还可以方便的自定义 Operators 满足个性化的任务需求。

airflow 的守护进程是如何一起工作的?

需要注意的是 airflow的守护进程彼此之间是独立的,他们并不相互依赖,也不相互感知。每个守护进程在运行时只处理分配到自己身上的任务,他们在一起运行时,提供了 airflow 的全部功能。

调度器 scheduler 会间隔性的去轮询元数据库(Metastore)已注册的 DAG(有向无环图,可理解为作业流)是否需要被执行。如果一个具体的 DAG 根据其调度计划需要被执行,scheduler 守护进程就会先在元数据库创建一个 DagRun 的实例,并触发 DAG 内部的具体 task(任务,可以这样理解:DAG 包含一个或多个task),触发其实并不是真正的去执行任务,而是推送 task 消息至消息队列(即 broker)中,每一个 task 消息都包含此 task 的 DAG ID,task ID,及具体需要被执行的函数。如果 task 是要执行 bash 脚本,那么 task 消息还会包含 bash 脚本的代码。
用户可能在 webserver 上来控制 DAG,比如手动触发一个 DAG 去执行。当用户这样做的时候,一个DagRun 的实例将在元数据库被创建,scheduler 使同 #1 一样的方法去触发 DAG 中具体的 task 。
worker 守护进程将会监听消息队列,如果有消息就从消息队列中取出消息,当取出任务消息时,它会更新元数据中的 DagRun 实例的状态为正在运行,并尝试执行 DAG 中的 task,如果 DAG 执行成功,则更新任 DagRun 实例的状态为成功,否则更新状态为失败。

airflow单节点部署

将以上所有守护进程运行在同一台机器上即可完成 airflow 的单结点部署,架构如下图所示:

clip_image001

airflow多节点(集群)部署

在稳定性要求较高的场景,如金融交易系统中,一般采用集群、高可用的方式来部署。Apache Airflow 同样支持集群、高可用的部署,airflow 的守护进程可分布在多台机器上运行,架构如下图所示:

clip_image002

这样做有以下好处

高可用

如果一个 worker 节点崩溃或离线时,集群仍可以被控制的,其他 worker 节点的任务仍会被执行。

分布式处理

如果你的工作流中有一些内存密集型的任务,任务最好是分布在多台机器上运行以便得到更快的执行。

扩展 worker 节点

水平扩展

你可以通过向集群中添加更多 worker 节点来水平地扩展集群,并使这些新节点指向同一个元数据库,从而分发处理过程。由于 worker 不需要在任何守护进程注册即可执行任务,因此worker 节点可以在不停机,不重启服务下的情况进行扩展,也就是说可以随时扩展。

垂直扩展

你可以通过增加单个 worker 节点的守护进程数来垂直扩展集群。可以通过修改 airflow 的配置文件-{AIRFLOW_HOME}/airflow.cfg 中 celeryd_concurrency 的值来实现,例如:

celeryd_concurrency = 30

#您可以根据实际情况,如集群上运行的任务性质,CPU 的内核数量等,增加并发进程的数量以满足实际需求。

扩展 Master 节点

还可以向集群中添加更多主节点,以扩展主节点上运行的服务。您可以扩展 webserver 守护进程,以防止太多的 HTTP 请求出现在一台机器上,或者您想为 webserver 的服务提供更高的可用性。

需要注意的一点是,每次只能运行一个 scheduler 守护进程。如果您有多个 scheduler运行,那么就有可能一个任务被执行多次。这可能会导致您的工作流因重复运行而出现一些问题。

下图为扩展 Master 节点的架构图:

clip_image003

scheduler failover(HA)

看到这里,可能有人会问,scheduler 不能同时运行两个,那么运行 scheduler 的节点一旦出了问题,任务不就完全不运行了吗?

答案: 这是个非常好的问题,不过已经有解决方案了,我们可以在两台机器上部署 scheduler ,只运行一台机器上的 scheduler 守护进程 ,一旦运行 scheduler 守护进程的机器出现故障,立刻启动另一台机器上的 scheduler 即可。我们可以借助第三方组件 airflow-scheduler-failover-controller 实现 scheduler 的高可用。

具体步骤如下所示:

下载 failover

git clone https://github.com/teamclairvoyant/airflow-scheduler-failover-controller

使用 pip 进行安装

cd{AIRFLOW_FAILOVER_CONTROLLER_HOME}

pip install -e .

初始化 failover

scheduler_failover_controller init

注:初始化时,会向airflow.cfg中追加内容,因此需要先安装 airflow 并初始化。

clip_image004

更改 failover 配置

scheduler_nodes_in_cluster= host1,host2

注:host name 可以通过scheduler_failover_controller get_current_host命令获得

配置安装 failover 的机器之间的免密登录,配置完成后,可以使用如下命令进行验证:

scheduler_failover_controller test_connection

clip_image005

启动 failover

scheduler_failover_controller start

或者:nohup scheduler_failover_controller start > /softwares/airflow/logs/scheduler_failover/scheduler_failover_run.log &

因此更健壮的架构图如下所示:

clip_image006

airflow 集群部署的具体步骤

前提条件

节点运行的守护进程如下:

节点

运行服务

master1

webserver, scheduler
master2 webserver
worker1 worker
worker2 worker

队列服务处于运行中. (RabbitMQ, Redis, etc)

安装 RabbitMQ 方法参见: http://site.clairvoyantsoft.com/installing-rabbitmq/
如果正在使用 RabbitMQ, 推荐 RabbitMQ 也做成高可用的集群部署,并为 RabbitMQ 实例配置负载均衡。

步骤

  • 在所有需要运行守护进程的机器上安装 Apache Airflow。具体安装方法可参考airflow 安装,部署,填坑
  • 修改 {AIRFLOW_HOME}/airflow.cfg 文件,确保所有机器使用同一份配置文件。
  • 修改 Executor 为 CeleryExecutor

       executor = CeleryExecutor

  • 指定元数据库(metestore)

       sql_alchemy_conn = mysql://{USERNAME}:{PASSWORD}@{MYSQL_HOST}:3306/airflow

  • 设置中间人(broker)

       如果使用 RabbitMQ

       broker_url = amqp://guest:guest@{RABBITMQ_HOST}:5672/

       如果使用 Redis

       broker_url = redis://{REDIS_HOST}:6379/0 #使用数据库 0

       设定结果存储后端 backend

       result_backend = db+mysql://{USERNAME}:{PASSWORD}@{MYSQL_HOST}:3306/airflow

       #当然您也可以使用 Redis :result_backend =redis://{REDIS_HOST}:6379/1

       #密码认证使用:broker_url = redis://:{yourpassword}@{REDIS_HOST}:6489/db

  • 在 master1 和 master2 上部署您的工作流(DAGs)。
  • 在 master 1,初始 airflow 的元数据库

       airflow initdb

  • 在 master1, 启动相应的守护进程

       airflow webserver –D

       airflow scheduler -D

  • 在 master2,启动 Web Server

       airflow webserver -D

  • 在 worker1 和 worker2 启动 worker

       airflow worker -D

  • 使用负载均衡处理 webserver

       可以使用 nginx,AWS 等服务器处理 webserver 的负载均衡,不在此详述

至此,所有均已集群或高可用部署,apache-airflow 系统已坚不可摧。


官方文档如下:

Documentation: https://airflow.incubator.apache.org/

Install Documentation: https://airflow.incubator.apache.org/installation.html

GitHub Repo: https://github.com/apache/incubator-airflow


如果您觉得此文章对您有帮助,请点击右下方【推荐】让更多人看到,thanks!

作者:DataStrategy

出处:https://www.cnblogs.com/xiongnanbin/

联系:1183744742@qq.com;xiongnanbin@126.com

本文版权归作者和博客园共有(转载的归原作者所有),欢迎转载,但是请在文章页面明显位置给出原文连接。如有问题或建议,请多多留言、赐教,非常感谢。

posted @ 2019-11-11 16:12  John.Xiong  阅读(5885)  评论(1编辑  收藏  举报