为何Airflow 2.1+任务中使用multiprocessing.Pool会触发daemonic报错

底层多进程限制 #

Python multiprocessing 模块原生禁止从守护进程中创建新的子进程：守护进程的设计逻辑是随主进程退出自动销毁，若允许其创建子进程，会导致主进程退出后出现孤儿进程残留的问题，因此Python底层直接做了断言限制，也就是你日志中出现的AssertionError: daemonic processes are not allowed to have children。

Airflow版本运行模型差异 #

你使用的LocalExecutor在两个版本的任务运行属性有区别：

• Airflow v1.10版本中，LocalExecutor启动的任务执行进程默认是非守护进程，因此在业务代码中直接创建multiprocessing.Pool不会触发限制，可以正常运行。
• Airflow v2.1+版本为了解决旧版本任务退出时孤儿进程残留的问题，调整了LocalExecutor的进程属性：所有任务执行进程默认被设置为守护进程，此时你在任务代码中再尝试启动新的进程池，就会触发Python的多进程限制。

• 替换并行实现：IO密集型的BigQuery查询导出场景可以用concurrent.futures.ThreadPoolExecutor替代multiprocessing.Pool，线程没有守护进程派生限制，改造成本极低，仅需要替换进程池相关代码即可。
• 用Airflow原生并行能力：把原本进程池处理的逻辑拆分为多个动态生成的独立Airflow任务，靠Airflow调度层实现并行，更符合Airflow的设计理念，也便于任务监控、重试。
• 修改Airflow配置：如果必须保留代码内多进程逻辑，可以在airflow.cfg中设置core.execute_tasks_new_python_interpreter = True，让每个任务在独立的非守护进程中运行，不过该配置会增加任务启动的额外开销，需要根据实际场景权衡。

内容的提问来源于stack exchange，提问作者Canovice