Airflow LocalExecutor 用于并行运行任务的高内存使用率 : expected or fixable?

Question

情况:
Airflow 1.10.3 在 Kubernetes pod、LocalExecutor、parallelism=25 上运行
每天晚上，我们的 DAG 都会开始它们的预定运行，这意味着许多任务将并行运行。每个任务要么是在另一个 Pod 上开始实际工作的 KubernetesPodOperator，要么是等待另一个任务完成的 ExternalTask​​Sensor(在 ETL DAG 中)。

问题:
每个启动的任务将创建另外 2 个本地进程(除了工作进程)，每个进程占用 70MB。但所有这些进程都在等待，要么等待另一个 Pod (KubernetesPodOperator) 完成，要么等待另一个任务完成 (ExternalTask​​Sensor)。这是一个巨大的内存开销，似乎过分了。我们明确地选择了这个设置来将资源负载放在其他地方 (Kubernetes) 并使用 Airflow 轻量级:仅用于调度其他 pod。我们 future 的增长意味着我们希望在 Airflow pod 上扩展到数十个甚至数百个并行任务，但这在这些内存要求下不太可行。

题:
我们能做些什么呢？是否有设置可以减少每个并行任务的内存开销？也许在工作进程中运行 Operator？欢迎任何建议，谢谢!
(也许答案是:这就是 Airflow 的工作方式，在这种情况下:有没有更轻量级的调度解决方案的替代方案？)

我们尝试过的:
- 使用传感器“重新安排”模式而不是“戳”，以免传感器在等待时占用资源。是否导致任务卡在 up_for_reschedule 中。
- 玩并行度设置，但最终我们需要很多进程，所以这个值需要非常高。

附言这是我关于 SO 的第一个问题，因此欢迎改进/要求提供更多信息，谢谢!

更新
我知道 LocalExecutor 在这样的专业版中不能很好地工作。如果您有资源繁重的任务，比如 Airflow 运算符(operator)，那么切换到分布式设置是有意义的。但我一直认为我们的设置既有魅力又有纯粹的工作流程设置:只有 1 个 Airflow pod，它只安排其他 pod 并等待它们完成。使用 JVM 设置意味着很多线程大多处于空闲状态，等待 IO。一个 JVM 线程的开销大约是每个线程 1 MB，而使用 Airflow，我们每个任务必须处理 140MB!我可能会尝试创建一个 LocalThreadedExecutor ，它不会启动额外的进程......

Answer 1

这是 LocalExecutor 的固有问题。它基于 fork 过程。即使任务只是触发启动另一个 Pod，对于每个任务，Airflow 仍然会调度一个进程，这当然有很高的开销。

我的建议是转移到 Kubernetes 执行器 https://airflow.apache.org/docs/1.10.1/kubernetes.html .然后每个任务将自 Action 为一个 Pod 运行。然后，您不再需要显式使用 KubernetesPodOperator，而只需使用常规 Airflow 操作符，因为它们无论如何都将作为 pod 在 Kubernetes 中执行。最后，如果这是一种可行的方法，我认为从长远来看它会带来最好的结果。