【发布时间】：2018-08-29 02:57:48
【问题描述】：
有没有人报告说他们能够让 Airflow 在他们的公司扩大规模？我正在考虑实施 Airflow 以执行 5,000 多个任务，每个任务将每小时运行一次，并且有朝一日将其扩展到 20,000 多个任务。在检查调度程序时，它看起来可能是一个瓶颈，因为它只有一个实例可以运行，而且我担心调度程序将难以跟上这么多任务。我应该是吗？
【问题讨论】：
【发布时间】：2018-08-29 02:57:48
【问题描述】：
我们公司每天运行数千个任务，并且在 2 年的大部分时间里一直在使用 Airflow。这些 dag 每 15 分钟运行一次，并通过可以随时更改的配置文件生成（从 UI 输入）。
简短的回答 - 是的，它绝对可以扩展至此，具体取决于您的基础架构。一些新的 1.10 特性应该比我们运行的运行所有这些任务的 1.8 版本更容易。我们在一个大型 Mesos/DCOS 上运行此程序，经过大量微调以达到稳定点。
长答案 - 虽然它可以扩展至此，但我们发现更好的解决方案是 多个 Airflow 实例 具有不同的配置（调度程序设置、工作人员数量等）针对它们正在运行的类型进行了优化。一组运行长时间运行的机器学习作业的 DAG 应该托管在一个不同于运行 5 分钟 ETL 作业的 Airflow 实例上。这也使不同的团队更容易维护他们负责的工作，并使迭代任何所需的微调变得更容易。
【讨论】：
-
请注意，尽管 Airflow 中有一个不可扩展的关键依赖项 - 调度程序。您不能为不同的 DAG 使用多个调度程序，因此运行调度程序的唯一选择是大规模实例，即垂直扩展。除非有一个好的选择，否则使用多个 Airflow 实例将是扩展的最佳选择。
-
好主意，谢谢。在运行多个 Airflow 实例时，您是否遇到过希望在一个 Airflow 实例中运行的 DAG 成为单独 Airflow 实例中 DAG 的依赖项，还是让它们在很大程度上保持独立？
-
一般来说，我们尽量让它们独立于另一个。但是，如果需要类似的东西，我们可能在 Airflow A 中有一个任务在外部文件存储（例如 S3）中输出一个文件，并在 Airflow B 中有一个 DAG，其中有一个等待该文件的传感器
-
你们为 Airflow 使用什么样的后端来帮助它扩展到数千个任务？我们使用 MySQL 后端，并在大约同时启动一千个任务时达到 CPU/连接峰值的限制。