小程序地图开发：marker随屏幕缩放自适应的完整方案
2026/9/16 6:37:36
Airflow 是 Apache 软件基金会旗下的开源项目，定位是 production scheduler。在实际数据平台中，Airflow 被广泛用于编排周期任务：从数据同步、ETL 到模型训练和报表生成，都可以通过 DAG 描述。标题里 “built with Colors” 并不是指界面做得花哨，而是指 Airflow 把任务状态可视化成了颜色：绿色、红色、黄色、灰色分别代表成功、失败、等待重试和未运行。对运维和开发来说，颜色是最直观的信号系统。下面以 Airflow 2.x 为背景，先拆解它作为生产调度器的核心机制，再给出安装部署、最小 DAG、运行验证和排错路径，最后说明生产环境与学习环境的差异。整个过程不需要大量前置经验，熟悉命令行和基本 Python 语法即可。
1. 先理解 Airflow 为什么适合做生产级调度器
1.1 调度器与单机定时任务的区别
很多团队早期用 cron 或内部定时任务框架完成任务调度，但生产环境问题很快就暴露出来：无法记录每次运行的历史结果；一个任务失败之后没有自动重试；任务之间有依赖关系时没有统一管理；多个开发人员修改同一套配置时容易互相影响。Airflow 把所有任务定义成代码，用 DAG 表达任务之间的依赖，调度器按时间规则创建 Dag Run，执行器负责运行任务实例，元数据库记录每次运行的状态。这样任务系统就变成了可追溯、可重试、可扩展的工程系统。
这里要区分两个概念：
- 调度编排：Airflow 负责在什么时间点触发什么任务，以及按什么顺序运行。
- 数据计算：Airflow 本身不做高并发数据处理，它把运算交给 Python、SQL、Spark、Kubernetes 等执行环境。
Airflow 的核心价值在于把“什么时候跑、按什么顺序跑、失败怎么处理”这些运维逻辑固化下来，而不是替代具体的数据计算引擎。
1.2 核心组件和职责
Airflow 的数据模型和运行模型有一些常用术语：
- DAG：有向无环图，描述一组任务及其执行顺序。
- Task：DAG 中的一个最小执行单元。
- Task Instance：某个 Task 在某次运行中的具体实例，包含调度时间、状态、开始和结束时间。
- DAG Run：DAG 在某次调度时间点的运行记录。
- Operator：定义任务类型的类，比如 PythonOperator、BashOperator、EmailOperator。
运行模型组件表：
| 组件 | 职责 | 生产环境建议 |
|---|---|---|
| Scheduler | 扫描 DAG 文件，生成 DAG Run 和 Task Instance | 至少独立进程，配置高可用 |
| Web Server | 提供 Web UI 和 REST API | 可交给负载均衡层 |
| Worker | 执行任务实例 | 按并发扩缩容 |
| Metadata Database | 保存 DAG 定义、运行记录、日志引用、变量和连接信息 | 使用 PostgreSQL，独立高可用 |
| Executor | 决定任务实例如何被执行 | LocalExecutor 适合单机，CeleryExecutor/KubernetesExecutor 适合集群 |
DAG 文件只是定义工作流，真正运行任务的是 Worker 或本地进程。常见的理解误区是“Airflow 就是运行 Python 脚本的框架”。实际上它更关心任务何时运行和如何恢复，而不是任务内部的计算逻辑。
1.3 颜色是 Airflow 的运维信号
在 Web UI 中，DAG Graph 和 Grid 视图里每个圆角矩形表示 Task Instance，不同状态会用不同颜色区分。默认主题下常见对应关系如下，不同版本或主题可能略有差异，界面中会有图例：
| 状态 | 颜色 | 说明 |
|---|---|---|
| success | 绿色 | 任务执行成功 |
| failed | 红色 | 任务执行失败 |
| running | 蓝色或闪烁 | 任务正在执行 |
| queued | 灰色或黄色 | 任务已排队，等待执行器调度 |
| upstream_failed | 浅红 | 依赖的上游任务失败 |
| retry | 黄色或橙色 | 任务失败后等待重试 |
| skipped | 灰色斜线 | 任务被跳过 |
| scheduled | 通常用浅色 | 已生成实例但还没有开始运行 |
颜色存在的意义不是为了让界面好看，而是让运维人员一眼看出整条链路的状态。例如一个 DAG 有多个分支，如果某个任务变红，同层的下游任务通常显示 upstream_failed；这时候先从红色任务查日志，比逐个看日志更高效。
1.4 什么场景适合，什么场景不适合
Airflow 适合：
- 周期型数据管道，例如小时级、天级 ETL。
- 任务依赖明确、每个步骤可以独立重跑。
- 需要历史执行记录和审计追溯的流程。
Airflow 不适合：
- 秒级或毫秒级实时计算。调度器和任务实例的生成都有开销，实时场景应该交给流处理引擎。
- 任务内部本身就包含完整的状态机逻辑。Airflow 更擅长把流程编排变成可视化 DAG，不适合承担业务状态存储。
因此，在使用 Airflow 前要明确它的边界：它是一个调度和编排平台，不是一个实时计算引擎。
2. 安装部署前先了解部署方式和关键依赖
2.1 三种部署方式怎么选
Airflow 可以多种方式部署。常见的是本地 pip 安装、Docker Compose 和 Kubernetes 集群。在选择之前要确认几个问题：需要多高的并发，需要哪些 Executor，团队是否愿意维护元数据库和存储。
| 部署方式 | 适合场景 | 特点 |
|---|---|---|
| pip 安装 | 单机体验、开发调试 | 环境迁移成本高，进程管理需要自己处理 |
| Docker Compose | 本地复现、测试环境 | 组件隔离，一键启动，适合团队统一开发环境 |
| Kubernetes + Helm | 生产集群 | 组件可扩缩容，依赖集群运维能力 |
如果只是第一次学习 Airflow，完全可以在自己的电脑上通过 Docker 快速启动，先看到 DAG 运行效果，再深入理解参数调整。如果是在企业环境中交付，则需要将元数据库、执行器、存储和监控一并设计进去。
2.2 系统要求和 Python 环境
Airflow 对