Airflow任务中安全使用多进程：避开连接池与日志陷阱

干了这么多年数据调度，Airflow 里最容易翻车的操作之一，就是任务里 Python 代码自己开多进程。我见过不止一次生产事故：凌晨数据库连接数直接打满，所有上游任务排队；也见过一个好好的任务，因为函数里加了 multiprocessing，日志全部乱成一团，最后排查了两天。要知道 Airflow 的 worker 本身已经是一个多进程环境，你在任务里再 fork 一波子进程，整个进程树立刻变成“三层楼”，文件描述符、连接池、信号处理全都被复制了一遍，任何一个环节出错，排查难度都是指数级上升。

但“在 Airflow 中安全使用多进程”这件事，并没有一个简单的一刀切答案。你需要分场景决定：是拆成多个 task 让 Airflow 自己调度，还是在单个 task 内部用进程池；是用 ProcessPoolExecutor 还是 multiprocessing.Queue；是 fork 还是 spawn；子进程的日志和数据库连接该怎么处理。这些问题，官方文档讲得很浅，生产环境里踩坑全得靠自己摸索。

这篇文章我就把这几年的实战经验整理成一套可复用的方法论。不讲那些理想化模板，只讲我在真实集群里验证过的方案，包括完整代码、参数选择逻辑、以及每个环节“为什么这么做”的原因。项目标题里说的“安全”，我理解成两层意思：资源安全，别把 worker 和数据库搞崩；语义安全，子进程的结果能正确回来、状态能正确上报、日志不串线。这两个维度，下面的内容都会覆盖到。

1. 为什么在 Airflow 任务里开多进程特别容易翻车

1.1 先搞清楚 Airflow 本身的进程模型

很多人一上来就写 multiprocessing，但根本没意识到 Airflow 的 worker 已经是一个多进程环境。以最常用的 LocalExecutor 为例，scheduler 进程每到达一个 task 实例的调度时间，就会在本机上 fork 出一个新的进程来执行这个 task。如果你用的是 CeleryExecutor，任务最终会发送到 Celery worker，由一个专门的工作进程去执行。再极端一点，KubernetesExecutor 下每个 task 是一个独立 pod 里的独立 Python 进程。

也就是说，你的 task 代码跑在一个已经被 Airflow 管理起来的进程当中。这时候你再在代码里调用 multiprocessing 开子进程，问题就来了：

• 子进程不是 Airflow 管理的，它不会遵守 Airflow 的 task 超时策略，比如 execution_timeout 只对父进程生效，子进程可能无限期挂住。
• 子进程继承了父进程的文件描述符，包括数据库连接、日志文件的写句柄、Redis 连接等。fork 之后这些资源在被复制时处于什么状态，子进程根本不知道，容易出现“父进程关闭了连接，子进程还在写”这种诡异行为。
• 日志系统是按 task_id 组织的，但子进程如果直接打印到 stdout，Airflow 的日志处理器并不会自动感知到这些子进程，导致日志缺一段或者全丢。

这还不是最头大的。真正危险的是，Airflow scheduler 在决定一个 task 是否完成时，只看 task 进程的退出状态。如果你在 task 里启动了一个非 daemon 的子进程，而父进程没有 join 就退出，Python 解释器会等待所有非 daemon 子进程结束才真正退出。这就出现了一个很经典的现象：任务日志显示代码已经执行完，但 task 一直显示 running，直到子进程超时被杀。

1.2 最容易踩的四个坑

我在生产环境里总结出了几个高频事故点，几乎每个团队都会踩中至少一个：

数据库连接数暴涨。 这是最常见、也最致命的一个。Airflow 的 task 进程本身已经维护了一个 SQLAlchemy 连接池。你去 fork 子进程，等于把这个连接池完整复制了一份。如果一个 task 开了 8 个子进程，等于瞬间多出 8 份连接池副本，每个副本可能包含多个物理连接。几十个 task 同时跑的时候，数据库连接数直接翻上百倍，DB 很快就不响应了。这个坑在 PostgreSQL + CeleryExecutor 的组合下尤其明显。

日志文件描述符污染。 fork 出的子进程继承了父进程打开的所有文件句柄，包括 Airflow 的日志处理器正在写入的那个文件。表面上看日志好像都能写进去，但多个进程同时写同一个文件，没有锁保护，日志会交错、截断、甚至直接丢失。你排查问题的时候会发现某几行日志凭空消失了，这在生产环境里极其痛苦。

信号处理失效。 Airflow 对 task 进程发送 SIGTERM 是做 graceful shutdown 的，会尝试清理资源、写状态。但子进程自己跑的时候，如果注册了自定义的 signal handler，或者压根没处理信号，父进程收到 SIGTERM 后不会自动把信号转发给子进程。结果就是父进程正常退出，子进程变成了孤儿进程继续运行。

结果传递失败。 有的团队用 multiprocessing 是为了并行跑一堆函数然后汇总结果，但代码写得不严谨，把 Queue 放在 fork 之前创建，结果子进程往 queue 里写数据时父进程已经空了。或者父进程没有正确 join，直接退出，queue 里的数据就丢了。

这四个坑本质上都源于同一件事：你粗暴地把通用多进程逻辑搬进了 Airflow 的管理边界里。所以要安全使用多进程，第一步不是写代码，而是先问自己一个问题：真的需要在 task 里开多进程吗？

2. 先想清楚：你真的需要在任务里开多进程吗

2.1 分清“任务级并发”和“函数级并发”

Airflow 本身就是一套分布式任务调度框架，它天生的并发单元是 task 实例。你可以在 DAG 里定义 10 个互不依赖的任务，让 scheduler 并行执行；也可以打开 Dynamic Task Mapping，基于一组输入动态生成一批 task。这些都是“任务级并发”，由 Airflow 的 executor 来调度，资源回收、失败重试、日志收集全部由框架统一处理，不会出上面说的那些坑。

而“函数级并发”是指在单个 task 进程内部，把一个大函数的计算拆给多个子进程。比如一个 task 里要处理 100 万条数据，你想让 8 个进程每个处理 12.5 万条。这种并发方式的好处是共享一个 task 的调度、日志、状态管理，坏处是你得自己处理进程生命周期、资源隔离、结果汇总。

很多情况其实更适合前者。比如你有一个文件处理任务，要处理 20 个文件，最优雅的做法是定义 20 个 task 实例，或者用 Dynamic Task Mapping 动态生成 20 个 mapped task，而不是在一个 task 里开 20 个进程。这样 Airflow 可以帮你管理并发度、重试、超时和日志，运维成本低得多。

2.2 用一张表快速判断该选哪条路

我这里整理了一张决策表，建议你在写代码之前先对照一下：

这张表的逻辑是：多进程是最后手段，不是第一选择。Airflow 的设计理念本身就是“把工作拆成一个个任务，交给调度器统一管理”，你非要在一个任务里手写一套进程调度，等于自己重新实现了一个 mini scheduler，还放弃了 Airflow 提供的所有保障。

2.3 如果确实需要，先评估资源限制

假设你确定要在 task 内开多进程，那必须遵循一条核心原则：子进程数量要受到严格限制，并且要基于集群资源合理设置。比如你运行的机器是 8 核 16G，那一个 task 里开 4 个子进程是合理的；如果你同时有 20 个 task 在跑，而每个 task 都开了 4 个子进程，那这台机器实际在处理 80 个进程，负载直接爆掉。

我见过一个很典型的例子：某团队有一个耗时任务，2 秒延迟就受不了，于是开了 16 个进程并行。单看这一个任务，速度确实提升了。但 scheduler 同时调度了 30 个这样的任务，机器上瞬间 480 个进程抢 CPU，最后所有任务都变慢了，数据库也被拖垮。这就是只盯着单任务优化、忽略了全局资源池的后果。

所以建议你在用多进程前，先看一眼机器当前负载和连接数，给自己定一个硬性上限。比如我一般会设置 max_processes_per_task = min(os.cpu_count() // 2, 8)，绝不无脑开满。这个上限不是写死的，要根据任务特性和集群规模调整，但一定要有。

3. 安全使用多进程的三种正确姿势

3.1 姿势一：ProcessPoolExecutor + spawn context + 独立日志

如果你只是想简单地把一个大计算分块并行，然后等待所有结果返回，那 concurrent.futures.ProcessPoolExecutor 是最稳妥的方案。它天然帮你管理了进程生命周期，你只需要把任务函数传进去，拿到 Future 对象，然后收集结果。

但直接照搬普通 Python 项目的写法是不够的。在 Airflow 里，有几个关键点必须处理：

第一，选择 spawn 而不是 fork。 Linux 下 Python 默认的 multiprocessing 启动方式是 fork，会复制父进程的全部内存空间和打开的文件描述符。这在单独运行的 Python 脚本里通常问题不大，但在 Airflow task 里，父进程已经打开了数据库连接、日志文件、Redis 连接等大量资源，fork 会把它们全部复制到子进程，这就是前面说的连接数爆炸的根源。

spawn 方式是重新启动一个 Python 解释器，只导入必要的模块，然后通过 pickle 把任务函数和数据传给子进程。它不会继承父进程打开的文件描述符，也就不会复制数据库连接和日志句柄。缺点是启动子进程更慢，每次都要加载模块，但对任务执行的正确性来说，这点性能开销完全值得。

code复制import multiprocessing as mp
from concurrent.futures import ProcessPoolExecutor, as_completed
import os

def process_chunk(chunk_id: int, data: list) -> dict:
    # 每个子进程独立运行，不会继承父进程的数据库连接
    # 如果子进程也需要写日志，用独立 logger，不要直接用 logging 全局句柄
    result = {"chunk_id": chunk_id, "count": len(data), "pid": os.getpid()}
    # 业务计算逻辑写在这里
    return result

def run_parallel_task(all_data: list):
    num_processes = min(os.cpu_count() // 2, 8)
    chunk_size = (len(all_data) + num_processes - 1) // num_processes
    chunks = [all_data[i * chunk_size: (i + 1) * chunk_size] for i in range(num_processes)]
    
    results = []
    # 关键是使用 spawn 上下文创建 ProcessPoolExecutor
    ctx = mp.get_context("spawn")
    with ProcessPoolExecutor(max_workers=num_processes, mp_context=ctx) as executor:
        future_map = {executor.submit(process_chunk, i, chunks[i]): i for i in range(len(chunks))}
        for future in as_completed(future_map):
            result = future.result(timeout=60)
            results.append(result)
    return results

这段代码里有个细节容易忽略：mp_context=ctx。ProcessPoolExecutor 在 Python 3.7+ 支持传入自定义的 multiprocessing context，如果直接写上 ctx，在 Linux 下默认还是 fork。所以我显式调用 mp.get_context("spawn") 来强制使用 spawn。这个是我在 Airflow 环境里实战验证过的，不加这一行，fork 模式下很容易出问题。

第二，子进程里不要用 Airflow 的日志句柄。 因为 spawn 模式下子进程不是 fork 出来的，它不会自动继承父进程的日志处理器，但你如果直接 import logging 然后 logging.getLogger()，默认 logger 会在子进程里创建一个空白 root logger，没有任何 handler。这样你在子进程里打的日志不会出现在 Airflow 的 task 日志里，排查问题的时候啥也看不到。

我建议的做法是：在子进程函数里显式使用 Python 的 logging 模块配一个简单独立 handler，或者写入一个以 chunk_id 命名的独立日志文件。等所有子进程跑完，再由父进程统一读回这些日志内容追加到 Airflow 日志中。

code复制import logging

def setup_child_logger(child_id: int):
    logger = logging.getLogger(f"child_{child_id}")
    logger.setLevel(logging.INFO)
    # 日志写到独立文件，避免和 Airflow 主日志互相污染
    fh = logging.FileHandler(f"/tmp/airflow_child_{child_id}.log")
    fh.setFormatter(logging.Formatter("%(asctime)s %(levelname)s %(message)s"))
    logger.addHandler(fh)
    return logger

第三，设置合理的 timeout。 ProcessPoolExecutor 的 future.result() 可以传入 timeout 参数，这个必须有。否则子进程一旦死循环，父进程会永远等待，Airflow 的 execution_timeout 到了也无法中断它，因为中断的是父进程，子进程还在跑。我一般会给每个 future 设一个 60~120 秒的 timeout，超时就直接让任务失败。

3.2 姿势二：multiprocessing.Queue + 主动管理进程生命周期

ProcessPoolExecutor 适合“全部结果都要收集”的场景。但有的场景是流水线型并行：主进程不断产生数据，子进程不断消费并处理，处理结果还要实时传回主进程。这种情况下 Executor 就不太够用了，需要更底层的 multiprocessing.Queue 搭配 Process 来使用。

在 Airflow 里这样做，核心难点在于生命周期管理。你可以这样设计模式：一个主进程（task 进程）作为生产者，N 个 worker 子进程消费任务队列，并把处理结果写入结果队列。主进程通过 queue.Empty 异常或者一个特殊哨兵值来判断所有工作是否结束。

code复制import multiprocessing as mp
import os
import time

def worker(task_queue, result_queue, worker_id):
    ctx = mp.get_context("spawn")
    while True:
        try:
            task = task_queue.get(timeout=5)
        except Exception:
            break  # 没有新任务了，退出
        # 模拟业务处理
        result = {"worker": worker_id, "task": task, "result": task * 2, "pid": os.getpid()}
        result_queue.put(result)

def main_task_process(all_tasks):
    ctx = mp.get_context("spawn")
    task_queue = ctx.Queue()
    result_queue = ctx.Queue()
    workers = []
    num_workers = 4
    
    for w in range(num_workers):
        p = ctx.Process(target=worker, args=(task_queue, result_queue, w), daemon=True)
        p.start()
        workers.append(p)
    
    # 生产任务
    for t in all_tasks:
        task_queue.put(t)
    
    # 给每个 worker 发一个哨兵，告诉它没有更多任务了
    for _ in range(num_workers):
        task_queue.put(None)
    
    # 等待所有 worker 处理完毕
    for p in workers:
        p.join(timeout=60)
    
    # 收集结果
    results = []
    while True:
        try:
            r = result_queue.get(timeout=1)
            results.append(r)
        except Exception:
            break
    return results

这版代码有几个关键设计点：

为什么用 Queue 而不是 Manager： multiprocessing.Manager 也可以实现进程间数据共享，但它额外启动了一个独立的 Manager 服务器进程，增加了通信链路和故障点。在 Airflow 任务里，我优先用 Queue，因为它的进程模型更简单、更容易预测，而且在 Spawn 模式下不会出现 Manager 版本兼容问题。

为什么把 Queue 放在 spawn context 之后创建： 因为 spawn 模式下，子进程不会继承父进程的内存结构，所以 Queue 必须是 pickle 后可传递的。如果用默认的 fork 上下文，Queue 通过文件描述符继承，但 spawn 模式下，Queue 则通过管道传输。在 ctx.Queue() 中显式创建，能确保 Queue 类型与上下文匹配。很多人踩的坑就是用了全局的 mp.Queue()，和自定义的 ctx.Process 混用，结果子进程收不到数据，就是因为上下文不匹配。

为什么 daemon=True： Airflow 任务进程如果是非 daemon 子进程，父进程退出时，Python 会自动等待它结束再退出。如果 worker 真的出现了死循环，整个 task 进程会被卡住，Airflow 执行超时也无法杀掉它。daemon=True 意味着父进程退出时，子进程立即被终止，这是最后一道防线。副作用是如果子进程里有未保存的中间状态，会丢失，但总比任务永久挂住好。

3.3 姿势三：把重活完全拆到外部，Airflow 只负责调度

前两种姿势都是把多进程放在 task 内部，说实话，我还是会在心里给它们标一个“尽量少用”的记号。因为无论你多小心，task 内多进程仍然是自建体系，Airflow 并没有完整感知子进程的运行状态，你等于在一个成熟的调度系统内部维护了一套自己写的 mini 调度器，出问题的概率远高于 Airbnb 官方推荐的做法。

所以当任务的计算量已经大到“一个 task 跑不动，必须多进程”的时候，我反而建议你退一步，把工作重心放到架构层面。具体方案是把重计算抽出去，部署成一个独立服务或者脚本，Airflow 只负责启动它，然后定期检查它的执行状态。比如：

• 把计算封装成一个 Python 脚本或者一个独立的服务进程，通过 SSH 或 RPC 调用，Airflow 用 SSHOperator 或 BashOperator 调用它。
• 处理后结果写入数据库或文件，Airflow 任务结束后再读取结果。
• 如果并发量很高，还可以用 Celery 或者任务队列来管理，Airflow 只负责把任务分发到队列，不直接参与计算。

这样做的好处很直接：Airflow worker 进程的内存、连接、日志不会被污染；任务失败了可以通过脚本退出码或者状态文件来判断；超时可以直接通过脚本本身的超时逻辑或外部 kill 控制。而且计算量再大的时候，你可以横向扩容，把多台机器加进来跑计算，而不是在一台 worker 上堆更多进程。这条路的后劲更足，也更容易运维。

当然，这种方式也有缺点：你需要额外的部署和监控，而 task 内多进程不需要额外部署，只要写对代码就能用。所以我的建议是一个分水岭式判断：如果是临时脚本、单次数据处理、规模小，可以接受 3.1 和 3.2 的方案；如果是长期运行、频繁调度、计算量大的任务，宁可前期多花时间把计算抽成独立服务，也别长期扛着 task 内多进程这种“技术债”。

4. 实操中我踩过的坑与排查方法

4.1 日志全乱，怎么定位每个子进程的任务

这个问题在 fork 模式下特别明显。因为 fork 的子进程继承了父进程的 stdout 和 Airflow 的日志文件句柄，它们打印的内容会一股脑写到同一个 Airflow task 日志里。多个进程同时写同一个文件描述符，没有锁，内容就会互相穿插，看起来就是一大片乱码。

我踩过的具体场景是这样的：一个任务开了 8 个进程，每个进程处理 20 万条数据。在业务代码里用 print 打了一些进度信息，结果 8 个进程的输出全部混在一起，最后连哪个进程先结束都看不出来，更没法定位是哪一段代码抛的异常。

解决方法有两种，第一种是用 3.1 提到的独立日志文件；第二种更简单粗暴，在每个子进程的 print 里加上进程 ID 和 chunk 编号：

code复制print(f"[{os.getpid()}][chunk_{chunk_id}] 开始处理第 {i} 条数据", flush=True)

这个办法调试时很有用，但生产环境我一般还是倾向于独立日志文件，因为日志文件是持久的，比 stdout 漂在 Airflow 日志里稳定得多。你可以用一个公共的日志目录 /tmp/airflow_subprocess_logs/，每个子进程往自己的文件里写，父进程不管子进程日志写没写完，最终把文件内容拼接到 Airflow 主日志里。

code复制def collect_subprocess_logs(log_dir: str):
    import glob
    all_log_lines = []
    for log_file in sorted(glob.glob(os.path.join(log_dir, "child_*.log"))):
        with open(log_file, "r") as f:
            all_log_lines.extend(f.readlines())
        os.remove(log_file)
    return "".join(all_log_lines)

4.2 数据库连接数暴涨的排查与规避

这个我在文章开头提过，是 Airflow 多进程问题里最危险的一个。排查方法不复杂，你去数据库侧执行 show processlist（MySQL）或 select * from pg_stat_activity（PostgreSQL），会发现大量来自同一台 worker 机器的空闲连接，连接数从几十跳到几百。这些连接大概率就是 fork 出来的子进程持有的连接副本，它们没有活跃事务、没有 SQL 执行，只是空占着连接数。

关键规避手段就是：不要 fork 携带数据库连接的进程。用 spawn 上下文可以规避掉大多数情况，但还有一个细节很多人会忽略——如果你在模块顶部导入了 from airflow.providers.postgres.hooks.postgres import PostgresHook，spawn 模式下模块会重新导入，但这个导入是干净的，不会带连接。真正的风险在于你在子进程函数内部直接用了父进程传入的 connection、session 或 engine 对象，这些对象在 spawn 模式下虽然没法被 pickle 传递（会报错），但万一你用了 fork 模式，就会把自己坑死。

我建议的规范是：子进程函数里永远不要接收父进程的数据库连接对象，要么自己创建全新的连接，要么干脆不直接连数据库，把处理结果通过 Queue 传回主进程，由主进程统一写库。这样连接数始终保持在一个稳定的数量，不会随着子进程数量线性膨胀。

code复制def worker(task_queue, result_queue, database_dsn):
    # 注意这里的 database_dsn 是字符串，不是连接对象
    from sqlalchemy import create_engine
    engine = create_engine(database_dsn)
    while True:
        task = task_queue.get()
        # 业务处理
        result_queue.put({"result": ...})

4.3 任务状态永远显示 running 的谜团

之前遇到一个同事反馈，DAG 里某个任务运行了一个多小时，日志文件没有任何新增内容，但任务状态一直是 running。他的代码逻辑很简单，就是调了一个函数，函数里面用 multiprocessing.Process 开了两个子进程去跑两个独立的业务。然后他调用了 process.start() 但忘了 process.join()，函数就返回了。

问题就在这：Python 的 multiprocessing.Process 默认是非 daemon 的，父进程退出时，Python 解释器会调用 join() 等待所有非 daemon 子进程结束才真正退出。Airflow 看到 task 进程还活着，就觉得任务还在运行。但日志文件已经没有新内容了，因为子进程去执行别的计算去了，没往日志里打东西。

解决方式就是 3.2 里强调的：要么显式 join 并设置 timeout，要么把子进程设为 daemon=True。但如果你是用了 ProcessPoolExecutor，它内部会自动管理 join 的过程，所以出问题的概率小很多。此外，我还建议在 task 里加一个 execution_timeout 参数，比如：

code复制run_parallel = PythonOperator(
    task_id="run_parallel",
    python_callable=run_parallel_task,
    execution_timeout=timedelta(hours=1),
    dag=dag,
)

这样即使子进程真的失控，Airflow 至少会在 1 小时后强制杀掉父进程。注意，父进程被 kill 时，如果是 daemon 子进程会被一起杀掉，非 daemon 子进程则会变孤儿继续运行。所以最好还是配合 daemon=True 使用。

4.4 结果莫名丢失，Queue 的坑

另外一个很经典的坑是，你在子进程里把计算结果放进了 Queue，但父进程等到子进程全部结束后再去读 Queue，发现结果为空。原因通常是父进程读 Queue 的时机太晚，或者子进程在退出时根本没有把数据成功 flush 到 Queue。

有一种易错写法：使用 multiprocessing.JoinableQueue，子进程处理完一个任务调用 task_done()，但父进程在 join() 的时候，JoinableQueue 的 join 会等待所有任务被标记 done。如果你在父进程里忘了调用 q.join()，而直接调用了 p.join()，父进程不会知道 Queue 中还有数据，而子进程已经结束了。这样结果虽然在 Queue 里，但你已经不会再去读了。

我建议的稳妥做法是：结果收集必须在所有子进程 join 完成后，立即从 Queue 中读取，并且要循环读到 Queue.Empty 异常抛出为止。我在 3.2 的代码里就用了这个模式。还有一种情况是 Queue 的容量满了，子进程往里面写数据时阻塞住，看起来是子进程没退出，实际上是 Queue 没有消费者，导致死锁。这种问题一般出现在生产者和消费者的速率不匹配时，解决办法是把 Queue 的 maxsize 调大，或者启用一个独立的结果收集线程。

5. 进阶思路：从“任务内多进程”走向“分布式并发”

5.1 为什么我建议你优先考虑 CeleryExecutor

如果你真的长期在 Airflow 里跑大数据量任务，我强烈建议你把视线从任务内多进程转向 CeleryExecutor。这不是说任务内多进程就不能用，而是说当你的并发需求已经远超单机多进程的承载范围时，用 Celery 做分布式 worker 是更安全、更符合 Airflow 设计哲学的选择。

简单解释一下，CeleryExecutor 是 Airflow 的一种执行器实现。scheduler 探测到任务到期后，会把任务作为一个消息发布到 Broker（通常用 Redis 或 RabbitMQ），Celery worker 监听队列并消费任务执行。这样你不需要在单个 task 进程内部去手动开多进程，而是由 Celery 在多个 worker 节点上并发执行多个 task。所有 Airflow 的日志、状态、重试机制仍然都由 Celery worker 统一上报。

这正好对应了前文提到的“任务级并发”思路：并行单位是 task，而不是进程。多个 task 可以分布在多台机器上执行，负载均衡、失败重试、日志汇总，全由框架处理。这种架构下，你完全不用操心 fork、spawn、Queue、日志冲突、连接数爆炸等问题，因为Airflow 和 Celery 已经帮你管理好了进程生命周期。

5.2 什么时候该用 Celery，什么时候还是用任务内多进程

我整理一个更细致的决策矩阵，帮你判断当前阶段适合哪一种：

这个表格可以看作是决策参考，但核心逻辑很简单：如果你的计算能被拆成多个独立的、可并行执行的单元，那就应该是多个 task 而不是多个子进程。只有当拆分不了、只能在一个大任务内部做并行时，再考虑任务内多进程。

5.3 结合 Celery 架构的实际落地方案

如果你打算切换到 CeleryExecutor，有几点落地建议，都是我在真实环境里验证过的：

第一，Broker 选型。Redis 和 RabbitMQ 都可以，但如果你团队已经用了 Redis，就直接用 Redis。要让 Broker 有足够的内存容量，因为如果任务积压得太多，消息队列满了，scheduler 会阻塞。我一般会监控 broker queue 的长度，超过阈值就告警。

第二，Worker 并发度设置。Celery worker 启动时可以指定 --concurrency 参数，代表这个 worker 进程能同时处理多少个任务。这个值不是越大越好，我一般根据 worker 节点的 CPU 核数设置为 N 或 2N，并配合 --prefetch-multiplier=1 防止一个 worker 一次性拉取太多任务导致任务分配不均。

第三，仍然注意任务内的 DB 连接。就算换到了 CeleryExecutor，task 代码里如果直接用 SQLAlchemy engine，也还是要小心连接池大小。建议在连接字符串中使用合理的 pool_size 和 max_overflow，并且确保每个 task 在 finally 里关闭连接。因为一个 Celery worker 进程并发跑多个 task，连接池的复用逻辑更容易引发连接数堆积。

第四，如果用了 Celery，日志的查看方式变了。任务日志不再只在 scheduler 进程的文件系统上，而是分散在每个 worker 节点上。最好配置统一的日志系统，比如把 worker 日志打到 stdout 或 syslog，再由日志采集系统统一收集。

5.4 终极建议：把多进程看成是“最后手段”

我见过太多团队，一遇到性能问题就条件反射式地想开多进程，结果把系统搞得更复杂、更难维护。实际上，在你的 Airflow 架构演进过程中，应该按照这样的优先级顺序来处理并发需求：

1. 先优化单个任务的执行逻辑，能用索引、缓存、批量写等手段解决的就不要上并行。
2. 任务天然可拆分时，用 Dynamic Task Mapping，让 Airflow 自身调度。
3. 单机多任务并发不够时，切到 CeleryExecutor 或 KubernetesExecutor。
4. 只有在单个 task 内部确实无法拆分、且必须并行的情况下，才使用任务内多进程。

这中间最大的逻辑在于：Airflow 是一个成熟的分布式调度系统，它的核心能力就是帮你管理任务的并发、重试、超时和资源隔离。你用了多进程，等于绕开了这个成熟体系，自己亲手在刀尖上跳舞。能交给 Airflow 的事情，尽量交给 Airflow；非自己做不可的，严格遵守我上面讲的 spawn 模式、独立日志、合理 join、daemon 保护、以及连接池隔离这些原则。

我个人在实际操作中的体会是，Airflow 任务内多进程这件事，代码本身不难写，难的是你要时刻意识到你正在处理的是一个受管环境，一个不小心就会破坏 Airflow 的管理假设。慢慢来，先在测试环境把进程数、日志、连接池全部检查一遍，再上生产，你会少走至少一半弯路。最后再分享一个小技巧：给 task 函数定义一个清晰的名字，比如 run_parallel_processing，同时在命名的 chunk 里包含任务实例 ID，这样你排查问题的时候，只要看日志里的任务实例 ID，就知道这个 chunk 属于哪一次调度，不用靠猜。