在许多行业中,数据分析在业务的各个阶段的决策过程中一直发挥着关键作用。 在当今的大数据时代,采用水平只会越来越高。 看到每周出现的所有大数据技术都能满足大数据解决方案实施的各个阶段,真是令人难以置信。 随着各种来源(使业务流程自动化的应用程序)以极快的速度生成数据,实施了针对用例的解决方案,例如“从各种来源实时摄取数据”,“以不同数据摄取水平处理数据”以及“准备用于分析的最终数据”变得充满挑战。 尤其是,对数据平台进行稳定,可靠的编排,调度,管理和监视管道是一项非常关键的任务。 而且,由于数据源的动态特性,数据流入率,数据模式,处理需求等,工作流程管理(管道生成/维护/监控)变得更具挑战性。
这是一个由三个部分组成的系列,其中“概述和气流的一些建筑细节”作为第一部分的第(1)部分进行了介绍。 本部分介绍生产中气流的部署选项。
第2部分:部署视图:提供更好的画面
根据需要,可能需要进行简单的设置或对Airflow进行复杂的设置。 可以使用不同的方式来部署气流(尤其是从执行者的角度来看)。 以下是部署选项以及每个选项的描述。
独立部署模式
描述:如上一节所述,开始的典型Airflow安装如下所示。
- 配置文件(airflow.cfg) :包含以下详细信息:从何处选择DAG,要运行的执行程序,调度程序应多久轮询DAGs文件夹以获取新定义,在哪个端口上启动Web服务器等。
- 元数据存储库 :通常,Mysql或postgres数据库用于此目的。 与DAG,度量标准,任务和状态,SLA,变量等相关的所有元数据都存储在此处。
- Webserver :呈现精美的UI,显示所有DAG,它们的当前状态以及指标(从回购中提取)。
- 调度程序 :读取DAG,将有关DAG的详细信息放入Repo。 它启动执行器。
- 执行程序 :负责读取schedule_interval信息,并将DAG和任务的实例创建到Repo中。
- Worker :Worker读取任务实例并实际执行任务,并将状态写回到仓库。

分布式部署方式
描述: “独立”部分提到的大多数组件的描述均保持不变,除了执行器部分和工人部分。
- RabbitMQ:RabbitMQ是Celery Executor用来将任务实例放入其中的分布式消息传递服务。 这是工作人员通常从中读取任务以执行的地方。 基本上,RabbitMQ公开了一个代理URL,供Celery执行人员和工人进行交谈。
- 执行程序:这里的执行程序将是Celery执行程序(在airflow.cfg中配置)。Celery执行程序配置为指向RabbitMQ代理。
- 工作程序:工作程序安装在不同的节点上(基于需求),并且已配置为从RabbitMQ代理读取任务信息。 这些工作程序还配置了一个Worker_result_backend,通常可以将其配置为MySQL存储库本身。
这里要注意的几个要点是:
- 工人除了自己安装的气流装置外,什么也没有。 只是只会启动工作进程。
- DAG定义应在所有节点(主要气流安装和Worker节点)上同步

设置了高可用性的分布式部署模式
描述:作为气流安装高可用性安装程序的一部分,我们假设将MySQL系统信息库配置为高度可用,而RabbitMQ将高度可用。 重点在于如何使气流组件(如Web服务器和调度程序)高度可用。
大多数组件的描述将与上面相同。 以下是更改内容:
- 新的气流实例(备用):将有另一个气流设置实例作为备用实例。
- 绿色显示的是主要的气流实例。
- 红色的是一个备用。
- 必须放置一个新的DAG。 称为“ CounterPart Poller”的东西。 此DAG的目的有两个
- 连续轮询对接部件计划程序以查看其是否已启动并正在运行。
- 如果配对零件实例无法访问(这意味着该实例已关闭),
- 声明当前的气流实例为主要
- 将(先前)主实例的DAG从DAGs文件夹中移出,并将对等轮询DAG移到DAGs文件夹中。
- 将实际的DAG移到DAGs文件夹中,然后将对等轮询器移到备用服务器上的DAGs文件夹中(现在将其声明为主要服务器)。
请注意,实例可以声明为主要服务器,可以作为某些mysql表中的标志。
运作方式如下:
- 最初,主调度程序(例如实例1)和备用调度程序(例如实例2)将启动并运行。 实例1将在mysql表中声明为主要气流服务器。
- 主实例(实例1)的DAGs文件夹将包含实际的DAG,而DAGs文件夹和备用实例(例如,实例2)将包含Counterpart poller(例如PrimaryServerPoller)。
- 主服务器将根据需要调度实际的DAG。
- 备用服务器将运行PrimaryServerPoller,它将连续轮询Primary Airflow调度程序。
- 假设主服务器已关闭。 在这种情况下,PrimaryServerPoller将检测到相同的
- 在Mysql表中将其声明为主要的气流服务器。
- 将实际的DAG移出DAGs文件夹,并将PrimaryServerPoller DAG移到较旧的主服务器上的DAGs文件夹中(实例1)
- 将实际的DAG移到DAGs文件夹中,并将PrimaryServerPoller DAG从旧的备用数据库上的DAGs文件夹移出(实例2)。
- 因此,此时,主服务器和备用服务器已交换位置。
- 即使当前备用服务器(实例1)上的气流计划程序恢复了,由于仅在其上运行CounterServerPoller DAG,也不会造成危害。 并且该服务器(实例1)将保持待命状态,直到当前的主服务器(实例2)关闭。
- 如果当前的主服务器出现故障,则将重复相同的过程,并且实例1上运行的气流将成为主服务器。

希望这可以更好地展示气流的部署选项。 请查看本系列的第3部分,了解有关如何安装气流的步骤以及大多数步骤的命令。