我目前已经设置了Airflow，并使用CeleryExecutor作为后端以提供水平缩放功能正常工作。这特别有效，尤其是当工作节点位于EC2上的自动伸缩组中时。
除了Airflow之外，我还使用普通Celery处理来自Flask / Python的简单异步任务（不需要整个管道）。到现在为止，这些普通的Celery任务的数量非常少，我只是在与Flask相同的机器上运行了普通Celery工人。现在需要在系统中运行大量普通Celery任务，因此我也需要扩展普通Celery。
一种方法是在Airflow工作者服务器上也运行普通的Celery工作者服务（以受益于自动缩放等），但这似乎不是一个优雅的解决方案，因为它创建了两个不同的“同一台计算机上的“芹菜工人类型”。我的问题是，是否可以将一些配置设置组合传递给我的普通Celery应用程序，这将导致@ celery.task装饰的功能直接作为普通Celery任务在我的Airflow工作人员群集上执行，从而完全绕过了Airflow中间件。 / p>
感谢您的帮助。
答案 0 :(得分：0)
如果我没记错的话，应用程序是airflow.executors.celery_executor.app。尝试使用celery -A airflow.executors.celery_executor.app inspect active作为当前Airflow基础架构中的示例进行测试。但是，我建议您不要这样做，因为您的Celery任务可能会影响Airflow DAG的执行，并且可能会影响SLA。
我们在我工作的公司中所做的正是您的建议-我们维护着一个大型Celery集群，有时我们会根据用例将一些Airflow任务的执行工作转移到Celery集群中。当我们的Airflow DAG中的一项任务实际触发成千上万的小型工作时，这特别方便。我们的芹菜群集在忙碌的一天中运行800万个任务。