Maxime:

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

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

• 一组Airflow工作节点

• 一个调节器（Redis或RabbitMQ）

• 一个Airflow Web服务器

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

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

• Airflow Web服务器

• Airflow 调度器

• 元数据库（Postgres）

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

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

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

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

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

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

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