使用Airbnb的Airflow来管理数据工作流

Airbnb 最近在Apache许可证下开源了它自己的数据工作流管理框架  Airflow 。Airflow被Airbnb内部用来创建、监控和调整数据管道。任何工作流都可以在这个使用Python来编写的平台上运行。 

Airflow是一种允许工作流开发人员轻松创建、维护和周期性地调度运行工作流（即有向无环图或成为DAGs）的工具。在Airbnb中，这些工作流包括了如数据存储、增长分析、Email发送、A/B测试等等这些跨越多部门的用例。这个平台拥有和 Hive、Presto、MySQL、HDFS、Postgres和S3交互的能力，并且提供了钩子使得系统拥有很好地扩展性。除了一个命令行界面，该工具还提供了一个  基于Web的用户界面 让您可以可视化管道的依赖关系、监控进度、触发任务等。 

InfoQ采访了Airflow的创造者  Maxime Beauchemin 、  Agari 的数据架构师和框架的早期使用者  Siddharth Anand ，讨论了Airflow的使用场景和未来发展计划。 

InfoQ：你们能不能给我们概括一下Airflow的架构？

Maxime:

在一个可扩展的生产环境中，Airflow含有以下组件：

• 一个元数据库（MySQL或Postgres）

• 一组Airflow工作节点

• 一个调节器（Redis或RabbitMQ）

• 一个Airflow Web服务器

所有这些组件可以在一个机器上随意扩展运行。如果使用LocalExcuter来适度的安装则可以获得相当多的额外性能。

Sid:我非常认同Maxime提到的上述观点。我们（Agari）进行一个适度的安装：

• Airflow Web服务器

• Airflow 调度器

• 元数据库（Postgres）

上述两个组件（Web服务器和调度器）运行于一个单机上，而数据库运行在一个共享数据库实例中。我们在测试环境和生产环境都是用Airflow，这就意味着上述的架构重复了。作为早期使用者，我们一直在寻找一种安装简单、易于维护并且在云端运行的工作流调度器。我们不希望出现分布式架构涉及的分布式代理和一组远程机器带来的麻烦。这种麻烦就是私有专用数据中心和痛苦地公有云，再后来，无论是一个服务器还是分布式代理调节器，当服务器重启时你经常需要实现一些工具去处理IP地址的更换。

我们希望的是一个在最初就是简单、随着需求增长弹性扩充并且能使得分布式代理架构更加具有投资价值的架构。

InfoQ：拿Airflow与Azkaban (LinkedIn)、 Luigui (Spotify) 和 Oozie (Yahoo) 这些比较结果会是怎样?

Maxime:

一个关键的区别是，Airflow管道被定义为代码（相较于Oozie和Azkaban被定义为标记语言），并且任务是被动态实例化的（而不是像Luigi是由派生类创建任务）。这使得Airflow成为动态管道生产的最佳解决方案，Airflow可以被用作“分析作为一种服务”、“分析自动化”和计算框架这样强大的概念。Airflow包括我们的A/B测试框架、一个异常检测框架、一个聚合框架和其他框架组成了上述概念的一个范例。

Sid:

参考  我们最近的博客 中的“为什么是Airflow？”这一章 

InfoQ：作为早期使用者和这一框架中的专家，在你看来Airflow的主要缺陷是什么？

Maxime:

Airflow还是一个年轻的项目并在快速的成长中，所以非常有理由去使用它，过程中当然会遇到一些错误。当然Pypi发布版本还是相当稳定。

Sid:

同意Maxime的看法。正如你所知道的任何刚开始的项目，Airflow在Github上有一个未解决问题清单。但对于我们来说没有一个问题能够阻挡我们，随着社区的发展和Airbnb投入更多工程师来支持，Airflow将成文DAG调度领域的强力竞争者，我预计bug清单将会越来越短而特性需求清单将增加。使得LocalExecutor成为一流公民是一个值得关注的问题。这感觉就像如Airbnb一样使用CeleryExcutor作为短暂的垫脚石。当然，我们还需要一定的时间转向Celery。一个原因是设置到云中并不简单。为了提高采用率和提升早期使用者的使用体验，我强烈建议和LocalExcutors一起使用从而达到尽可能地平滑和完美。既然Airbnb使用CeleryExcutors，他们将尽可能优化它提升体验。这就是说，Airbnb团队一直对社区的需求尽快响应，我期望我所提到的将会成为现实。

InfoQ：我们都知道，在这个领域里，安装方便不是最重要的，就像Oozie。Airflow的安装有多容易？你们认为这对于开发者和Devops评估它有多重要？Docker 容器是否在一个稳定的状态？

Maxime:它的安装极其简单，任何人在几分钟之内通过几个命令可以运行一个Airflow Web服务器和Airflow例子。虽然设置到生产环境会有一点点挑战但还是很简单。我认为Airflow是最易于安装的解决方案之一。 

InfoQ：Airflow作为工作流管理解决方案会显得大材小用了么？

Maxime:Airflow在Airbnb中并没有大材小用。所有功能的产生都是因为我们需要它，我保证如果你有一支数据团队，不管团队有多小，你将会慢慢使用其中的很多功能。 

Sid:同意。这需要一定的时间和小规模数据团队的努力。我们Agari的数据团队，至少有一个工作流依赖于Airflow的产物，但只需要一小队人和很少的时间去管理Airflow，节省了时间否则通过人工的方式将很难完成。 

InfoQ：一个是的HighCharts 可视化的插件是一个有价值的功能么？

Maxime:我认为这已经超出了工作流调度的范畴，但这是一个手边极其有用的功能，能够用于Airflow连接的所有数据库。你可能有一个更好的螺丝刀在你的地下室，但这个就在你的工具袋里。 

InfoQ：未来目标：你认为YARN计划的执行者会促进Airflow被更广泛的采纳么？你是否认为Airflow社区是充满生机和活力的？

Maxime:关于Yarn，我还没有找到一种有效的方式来为一个任务分配少一个一个CPU核心。在Airflow中我们通常分配4到16个任务给每个CUP因为大多数的任务都是分布式运行然后等待外部系统给出成功或失败的报告。这样一来，一个Yarn节点会比Celery节点更加耗费资源，并且Celery到目前为止工作地非常好。我认为随着规模的扩大资源的占用率越来越重要 

你可以在  Github 获得Airflow框架，Hadoop的首脑会议2015年的介绍性发言可在 Youtube 上看到。Sid关于基于Airflow的Agari的架构的详细介绍在他的  博客 上可以看到。