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有向无环图描述一组任务及其执行顺序。TaskDAG 中的一个最小执行单元。Task Instance某个 Task 在某次运行中的具体实例包含调度时间、状态、开始和结束时间。DAG RunDAG 在某次调度时间点的运行记录。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 对 Airflow生产调度器核心机制、颜色状态信号与部署实践解析
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有向无环图描述一组任务及其执行顺序。TaskDAG 中的一个最小执行单元。Task Instance某个 Task 在某次运行中的具体实例包含调度时间、状态、开始和结束时间。DAG RunDAG 在某次调度时间点的运行记录。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 对