Airflow的Executor选哪个——执行架构选型
先说结论
三种Executor的选择标准：LocalExecutor适合小规模（<50个并行Task）、CeleryExecutor适合中大规模（50-500并行）、KubernetesExecutor适合弹性伸缩需求（云原生环境）。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Executor决定了Airflow的任务在哪里执行——本地进程、Celery Worker、还是Kubernetes Pod。选错了Executor要么资源浪费要么扛不住规模。在某短视频平台从LocalExecutor升级到CeleryExecutor后，并行能力从32个Task提升到200+个Task，ETL完成时间减少了40%。
三种Executor对比
| 维度 | LocalExecutor | CeleryExecutor | KubernetesExecutor |
|---|---|---|---|
| 执行方式 | Scheduler机器上的子进程 | 分布式Celery Worker | 每个Task一个K8s Pod |
| 并行能力 | 受单机CPU/内存限制 | 多Worker机器扩展 | 理论无限（K8s集群） |
| 资源隔离 | 无（共享内存） | 弱（Worker进程隔离） | 强（Pod级别隔离） |
| 弹性伸缩 | 不支持 | 手动扩Worker | 自动（Pod按需创建） |
| 运维复杂度 | 最低 | 中（Redis/RabbitMQ） | 高（需要K8s集群） |
| 冷启动 | 无 | 无 | 有（Pod创建10-30秒） |
| 适用规模 | <50 Task并行 | 50-500 Task并行 | 弹性/大规模 |
# LocalExecutor配置
executor = LocalExecutor
parallelism = 32 # 单机最多32个并行Task
# CeleryExecutor配置
executor = CeleryExecutor
parallelism = 200
# 需要额外组件：
# Redis/RabbitMQ作为消息队列
# 多台Worker机器运行celery worker
# KubernetesExecutor配置
executor = KubernetesExecutor
# 每个Task启动一个Pod
# Pod的资源（CPU/内存）可以按Task定制
# Task完成后Pod自动销毁CeleryExecutor——生产环境最常用
# CeleryExecutor架构
# Scheduler --> Redis(消息队列) --> Worker1
# --> Worker2
# --> Worker3
#
# Scheduler把Task放入Redis队列
# Worker从队列取Task执行
# 结果写回MetaDB
# Worker扩容：加机器跑celery worker
# Worker缩容：停掉Worker（正在运行的Task会完成后停止）
# 关键配置
worker_concurrency = 16 # 每个Worker最多并行16个Task
# 4台Worker × 16并发 = 64个Task并行KubernetesExecutor——云原生的未来
优势：① 完美的资源隔离——每个Task一个Pod，互不影响；② 弹性伸缩——忙时K8s自动创建Pod，闲时销毁；③ 异构资源——不同Task可以请求不同的CPU/内存/GPU；④ 不需要常驻Worker——按需创建节省成本。
劣势：① 冷启动延迟——创建Pod需要10-30秒（拉镜像+启动容器）；② 运维复杂——需要K8s集群和容器镜像管理；③ 日志分散——每个Pod的日志在不同地方需要统一收集。
实战经验：Local到Celery的升级
某短视频平台初期用LocalExecutor（单机），任务增长到100+后并行度不够（parallelism=32限制），排队严重。
升级到CeleryExecutor：① 部署Redis作为消息队列；② 增加3台Worker机器（每台worker_concurrency=16）；③ parallelism调到200。总并行能力从32提升到64（实际根据Worker数可以更多）。
效果：ETL从4.5小时降到2.7小时（减少40%）。主要收益是减少了排队时间——之前很多Task在等Worker空闲。
面试高频追问
追问一：CeleryExecutor的Redis/RabbitMQ挂了怎么办？
Redis挂了新Task无法分发给Worker（在队列中的Task丢失），但正在Worker上执行的Task不受影响。恢复后Scheduler重新把pending的Task放入队列。生产建议Redis用主从+Sentinel高可用。RabbitMQ同理用镜像队列。
追问二：能混合使用Executor吗？
Airflow 2.x不支持同时用两种Executor。但CeleryKubernetesExecutor（Airflow 2.7+）可以——默认用Celery执行，特定Task标记为kubernetes Pod执行。适合大部分Task轻量级用Celery、少数重量级Task需要资源隔离用K8s的场景。
追问三：MWAA用的什么Executor？
AWS MWAA（Managed Workflows for Apache Airflow）用的是CeleryExecutor+Fargate。Worker运行在Fargate容器上自动伸缩。用户不需要管理Worker——AWS自动根据负载增减。这是托管Airflow的核心价值——不用操心Executor运维。
总结
Executor选型讲三种方案：① LocalExecutor（小规模<50并行，零运维，单机受限）；② CeleryExecutor（中大规模，多Worker扩展，需要Redis，生产最常用）；③ KubernetesExecutor（弹性伸缩，Pod级隔离，云原生趋势但冷启动和运维复杂）。能讲出Local升级Celery后ETL减少40%的实际案例，面试官觉得你有Executor选型和调优的实战经验。
下一篇聊调度平台的可观测性：任务运行日志找不到了怎么办？
你们Airflow用什么Executor？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长