Airflow架构与扩容

Posted 2022-12-04 bluishglc

整体上，Airflow是一种主从架构的作业调度系统，其官方给出的架构图如下：

像Metadata DB, Webserver这些组件不必过多解释，作为一个web应用，这些是常规组件，我们重点关注以下核心组件：

• Scheduler：生成作业排期，将各种Task提交给executor实行
• Executor：是一个偏抽象的概念，落地可以是多种不同的形式，但逻辑上，Executor扮演一个“队列”的角色，Scheduler生成的Task都会放入Executor（队列）中，由Executor委派给各个Worker节点执行，从这个角度上看，Scheduler是Task队列的生产者，Worker是Task队列的消费者。
• Worker：实际执行任务的节点，与多数主从架构中的Worker节点类似。

Airflow的Executor有多种不同的类型可供选择，主要影响的是逻辑上的队列本身的伸缩性。当然，Worker节点的数量也很关键，但是Worker节点的伸缩很简单，后面会补充谈一下。上图中Executor和Scheduler是画在一起的，这是因为Airflow在默认安装方式中，会将Executor（默认的Executor是Sequential Executor）和Scheduler安装在一起，但是在生产环境中，往往会使用更健壮，伸缩性更好的Executor（往往也是独立服务器安装的）。以下是几类Executor的介绍:

• Sequential Executor: 顾名思义，按顺序执行Task，无并行能力，使用SQLite存储Task元数据。不适用于生产环境
• Local Executor：可并行执行Task，使用一个专职的关系型数据库（如PG）存储元数据。健壮性比Sequential Executor强
• Celery Executor：使用专职的 Redis or RabbitMQ来分发消息，可同时分发多个Task到多个Worker节点上，同样需要一个专职的关系型数据库（如PG）。这是多数大规模生产环境上部署Airflow采用的Executor，以下是以Redis作为Celery Executor的架构示例：

或是：

• Kubernetes Executor： 基于Kubernetes工作，为每一个Task创建一个Pod，这显然适用于基础设施已经Kubernetes化的IT环境，相应的，这种模式下扩缩容会更加敏捷。

最后，我们再来看一个Worker节点扩缩容，我们可以通过向集群中添加更多 worker 节点来水平地扩展集群，并使这些新节点指向同一个元数据库，从而分发处理过程。由于 worker 不需要在任何守护进程注册即可执行任务，因此所以 worker 节点可以在不停机，不重启服务下的情况进行扩展，也就是说可以随时扩展。如果是垂直扩展 你可以通过增加单个 worker 节点的守护进程数来垂直扩展集群。可以通过修改 airflow 的配置文件AIRFLOW_HOME/airflow.cfg 中 celeryd_concurrency 的值来实现，例如：

参考：

https://blog.knoldus.com/airflow-scaling-using-celery-executor/

https://valohai.com/blog/scaling-airflow-machine-learning/

https://valohai.com/blog/scaling-airflow-machine-learning/