执行器决定任务在哪跑
执行器（executor）决定 Airflow 任务实际在什么地方运行：SequentialExecutor 单进程串行，只适合本地验证；LocalExecutor 在单机上多进程并行，小规模部署常见；CeleryExecutor 把任务分发到多个 worker 组成的队列，需要 Redis 或 RabbitMQ 作为 broker；KubernetesExecutor 每个任务起一个 Pod，隔离性与弹性最好。选型要看任务画像与运维能力，而不是只比并发数字。
基本信息
| SequentialExecutor | 单进程串行，仅适合本地验证 |
|---|---|
| LocalExecutor | 单机并行，小规模部署常见 |
| CeleryExecutor | 多 worker 分布式，需要 Redis 或 RabbitMQ |
| KubernetesExecutor | 每任务一个 Pod，隔离与弹性较好 |
典型使用场景
- 小团队日调度几百个任务：LocalExecutor 单机足够，运维最简单
- 任务量大需横向扩容：CeleryExecutor 加 worker 节点即可
- 依赖复杂、镜像差异大：KubernetesExecutor 让每个任务独立环境
- 成本敏感场景：常驻 worker 承载大量短任务比每任务起 Pod 更省
- 混合部署：KubernetesExecutor 处理重任务，Celery 承载常规任务
关键配置
关键配置
[core]
executor = CeleryExecutor # 选择执行器
parallelism = 64 # 全局同时运行的任务数上限
[celery]
broker_url = redis://redis:6379/0 # 任务队列
result_backend = db+postgresql://airflow:***@pg:5432/airflow # 结果存储执行器对照
| 执行器 | 扩展方式 | 适用与代价 |
|---|---|---|
| Sequential | 不支持扩展 | 仅本地验证，串行执行 |
| Local | 纵向提升单机配置 | 部署简单，无法横向扩容 |
| Celery | 增加 worker 节点 | 需维护 broker，worker 版本要一致 |
| Kubernetes | 按任务起 Pod | 隔离好、弹性强，启动与镜像管理成本高 |
选执行器要看任务画像：大量短任务适合常驻 worker，避免每任务起 Pod 的启动开销；镜像依赖复杂、隔离要求高的任务更适合 Kubernetes 方案。
Celery worker 与调度器的版本或依赖库不一致时，任务会随机失败且报错位置飘忽，升级时必须同步升级全部 worker。
换执行器要注意什么
更换执行器是一次架构变更，不是改一行配置：LocalExecutor 迁到 Celery 需要新增 broker、worker 进程与日志汇聚；迁到 KubernetesExecutor 还要准备镜像与 Pod 模板，并确认任务所需的依赖、密钥和环境变量都能注入。迁移期最容易被忽略的是任务里的本地文件依赖：原来在单机上共享的临时目录，换成分散 worker 或独立 Pod 后不再互通，必须在迁移前改成走对象存储或共享挂载。