声明
本文摘录了很多前辈的文章，原文如下：
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 的单结点部署，架构如下图所示：
airflow多节点（集群）部署
在稳定性要求较高的场景，如金融交易系统中，一般采用集群、高可用的方式来部署。Apache Airflow 同样支持集群、高可用的部署，airflow 的守护进程可分布在多台机器上运行，架构如下图所示：
这样做有以下好处
高可用
如果一个 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 节点的架构图：
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 并初始化。
更改 failover 配置
scheduler_nodes_in_cluster= host1,host2
注:host name 可以通过scheduler_failover_controller get_current_host命令获得
配置安装 failover 的机器之间的免密登录，配置完成后，可以使用如下命令进行验证：
scheduler_failover_controller test_connection
启动 failover
scheduler_failover_controller start
或者：nohup scheduler_failover_controller start > /softwares/airflow/logs/scheduler_failover/scheduler_failover_run.log &
因此更健壮的架构图如下所示：
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！