调度任务这件事很多团队都经历过从“能用”到“好用”再到“可用”的过程。最开始用 crontab简单直接后来任务变多出现依赖关系、需要重试、要追溯失败原因还要让不同的人都能看懂整体流程这时候就会发现单纯的定时工具根本撑不住。Apache Airflow 就是在这样的背景下进入视野的。它不是又一个“定时执行脚本”的小工具而是一个生产级的工作流调度平台。更值得留意的是它的标题里写了“built with Colors”——这不是在说界面好看而是 Airflow 在设计上把工作流的运行状态用颜色清晰地呈现出来。可以说Airflow 真正解决的不是“到点触发”而是让复杂工作流的状态变得可见、可追踪、可协作。这个判断是理解 Airflow 一切设计的前提。我在早期接触 Airflow 时也有一个误区以为它只是 crontab 的加强版。后来把几个真实的数据任务放进去跑才发现核心差异在“编排”和“可观测性”。Airflow 把你关注的任务定义成 DAG调度器负责按时触发执行器负责真正运行元数据库记录一切状态变化Web 界面则把每个 task 实例的运行结果用颜色、标签、日志完整地暴露出来。这样一套机制下来调度器才真正具备“生产可用”的底气。围绕这个理念我从安装部署、DAG 开发、生产落地和适用边界几个角度把 Airflow 的使用经验拆开讲一讲。1. 先搞清楚 Airflow 解决的不是“定时”而是“工作流编排”Airflow 经常被拿来和 crontab、APScheduler、Celery Beat 之类的东西对比。如果只讨论“能不能定时”这些工具都能做到。但生产场景里的任务往往不是孤立的。一个典型的数据管道可能包含抽数、清洗、特征计算、模型推理、结果入库每个步骤之间有先后依赖某些步骤失败后需要自动重试重试仍失败时还要发告警。任务一多这种依赖关系就会变成一团乱麻。1.1 从 crontab 到 DAG依赖关系才是重点crontab 只能表达“在某个时刻运行某条命令”它本身不关心你上一道任务有没有成功。你自然可以用 shell 脚本拼接来实现串行但一旦遇到分支、并行、超时、重试次数、失败通知脚本就会变得越来越难维护。Airflow 用 DAG有向无环图来建模工作流。DAG 的每一个节点是一个 Task节点之间的连线表示依赖。你写的不再是“跑完 A 再跑 B 再跑 C”的命令串而是一份结构化的流程定义。Airflow 调度器会依据 DAG 结构、任务依赖、调度时间自动决定哪些任务可以并行、哪些必须等上游完成后才能启动。这种表达方式带来的长期价值非常直接流程是代码可以版本控制依赖是显式的可以审查任务状态是可查的出问题了能知道卡在哪个环节。1.2 Airflow 的核心组件Scheduler、Executor、Worker、Web Server、Metadata DB要理解 Airflow 的生产能力得先知道它由哪些关键部分组成。Scheduler负责根据 DAG 的定义和调度周期生成 DagRun 和 TaskInstance并判断哪些任务该执行。Executor决定任务用什么方式执行。默认的 SequentialExecutor 只能逐个执行适合本机调试LocalExecutor 可以并行跑多个任务CeleryExecutor 则把任务分发到多个 Worker 上适合分布式部署。Worker实际执行任务实例的进程。Web Server提供界面可以查看 DAG 结构、任务状态、日志手动触发或暂停任务。Metadata DB存储 DAG、任务实例、执行记录、变量、连接信息等。生产环境一般使用 PostgreSQL 或 MySQL而不是默认的 SQLite。这五个角色共同构成了一个完整的调度系统。换句话说Airflow 不只是“跑起来就行”它需要你把元数据库、执行器、时区、日志存储这些生产组件都规划好。很多初学者只在单机用 SequentialExecutor SQLite跑 Demo 没问题但一旦任务多并发高就会频繁踩到资源锁和性能瓶颈。2. 为什么生产级调度器需要 Colors任务状态可视化设计回到项目的标题“built with Colors”。Airflow 的 Web UI 里每个 task 的实例都用颜色标识状态。这不是装饰性的设计而是一套高效的状态沟通语言。在运维和协作场景中“看到绿色就知道成功看到红色就知道失败看到黄色就知道在重试”这件事比任何一行日志都快。2.1 颜色背后的状态机TaskInstance 的状态转换Airflow 中每个 TaskInstance 都有明确状态常见的包括running正在执行。success成功结束。failed执行失败。upstream_failed上游任务失败当前任务没有被执行。skipped遇到分支条件不满足被跳过。up_for_retry失败后正在等待重试。queued已经排队等 Executor 分配资源。这些状态在界面里对应不同颜色比如绿色表示成功红色表示失败灰色表示跳过橙色或黄色表示等待重试。你打开一个 DAG 的运行视图一眼就能看出整个流程当前是通畅的还是堵在哪一步。更重要的是这样的状态设计让“发现问题”从“看日志找原因”变成了“先看颜色定位节点再进日志查细节”。生产调度中时间就是成本。一个依靠颜色缩小的排查范围可以直接决定故障恢复速度。2.2 可观测性是生产调度的底层能力调度工具如果只能按时启动任务那和高级 crontab 没有本质区别。Airflow 把调度变成了一整套可观测的流程DAG 结构、任务状态、运行时长、日志、执行时间记录全部落库并且暴露在界面上。这种可观测性在运维层面产生了一个重要后果任务执行不再是一个黑盒。你可以明确回答这几个问题上次完整跑成功是什么时候某一次运行整体花了多久失败的 task 是在哪个环节、因为什么报错有没有任务重试过重试结果如何这些信息在数据任务、批量计算、周期性报告这些场景里是团队协作的基础。Colors 正是这套可观测性设计最表层的表达。在没有颜色可视化之前你只能通过命令查数据库有了颜色和图形化展示整个流程的状态可以被一眼读取。3. 从零安装部署 Apache Airflow最小可用环境搭建看了不少概念还是先落地跑起来。安装 Airflow 并不复杂但要分清“跑通”和“生产可用”两种状态。下面这套流程适合在本机或一台 Linux 服务器上搭建一个最小可用环境用于学习和验证。3.1 环境准备与依赖安装建议使用 Python 3.8 或更高版本独立虚拟环境。原因很简单Airflow 依赖众多直接装到系统 Python 里容易和已有包冲突。mkdir airflow-project cd airflow-project python3 -m venv venv source venv/bin/activate然后安装 Apache Airflow。需要注意Airflow 的安装包名称是apache-airflow不是airflow。不同版本对 Python 版本要求不同安装前先确认你选择的版本和 Python 版本兼容。以 Airflow 2.x 为例常见安装命令是pip install apache-airflow2.9.1如果使用国内网络环境可以加上镜像源参数。安装完成后检查版本airflow version3.2 初始化元数据库和创建管理员账号Airflow 默认使用 SQLite 作为元数据库适合初次体验。执行export AIRFLOW_HOME$PWD/airflow_home airflow db initAIRFLOW_HOME是 Airflow 的配置和文件目录之后看到的airflow.cfg、dags文件夹都从这里开始。初始化完成后创建管理员账号用于登录 Web UIairflow users create \ --username admin \ --firstname Admin \ --lastname User \ --role Admin \ --email adminexample.com命令执行过程中会提示设置密码。你可以按自己的规则设置一个临时密码之后登录 Web UI 用。3.3 启动 Web Server 和 SchedulerAirflow 是“Web Server Scheduler”两个进程协作。开发环境要开两个终端airflow webserver --port 8080另一个终端启动调度器airflow scheduler启动后访问http://localhost:8080用刚才创建的 admin 用户登录。此时 Airflow 已经能运行但默认的 Executor 是 SequentialExecutor元数据库是 SQLite只适合本地验证。如果你要跑并行任务需要切到 LocalExecutor 并改用 PostgreSQL 或 MySQL。实际生产环境一般还会用 CeleryExecutor 加多 Worker这个后面再展开。4. 写出第一个可观测的 DAG结构、调度器和执行器的协作Airflow 最核心的代码资产就是 DAG 文件。DAG 文件放在AIRFLOW_HOME/dags目录下Airflow 的 Scheduler 会周期性扫描这个目录把 DAG 读入元数据库并展示在 Web UI 上。4.1 一个最小 DAG 的结构下面是一个常见的最小 DAG 示例。它定义了两个 tasktask_a 执行完后执行 task_bfrom datetime import datetime, timedelta from airflow import DAG from airflow.operators.python import PythonOperator def print_hello(): print(hello from airflow) def print_done(): print(task done) with DAG( dag_idmy_first_dag, start_datedatetime(2024, 1, 1), scheduledaily, catchupFalse, tags[example], ) as dag: task_a PythonOperator( task_idprint_hello, python_callableprint_hello, ) task_b PythonOperator( task_idprint_done, python_callableprint_done, ) task_a task_b这个 DAG 有很多值得解读的地方。start_date调度起始时间Airflow 会从指定时间开始生成执行计划。schedule调度频率daily表示每天执行一次也可以写成0 8 * * *这样的 cron 表达式。catchupFalse关闭补跑。如果不关Airflow 默认会从start_date到现在区间内所有未执行的计划全部补跑一遍。这往往是新人最容易踩的坑。一旦你设置了一个较早的start_date且没有关闭catchup一启动调度器就可能触发几十上百个任务实例。task_a task_b用位移符定义依赖关系表示 task_b 必须等 task_a 成功后才能执行。把这个文件保存到 dags 目录等待几个调度周期Web UI 上就会出现my_first_dag。4.2 Scheduler、Executor 和 TaskInstance 的协作过程当你看到 DAG 出现在界面里并不代表任务已经被执行。真正决定“什么时候跑、怎么跑”的是 Scheduler 和 Executor。整个流程大致是Scheduler 扫描 DAG 文件检查当前时间是否满足 DAG 的调度条件。如果满足生成一个新的 DagRun。根据依赖关系Scheduler 找到所有可以运行且还没有运行的任务为它们创建 TaskInstance。Executor 接收这些 TaskInstance决定在本地线程、进程池还是远程 Worker 上执行。任务执行完成后状态写回 Metadata DB。Web UI 从 Metadata DB 中读取状态用颜色展示给用户。所以你会碰到一种情况DAG 已经出现在界面上但是所有任务都是空白没有变成运行状态颜色。这通常是因为 Scheduler 认为还没到调度时间或者start_date在很久以前且catchupFalse导致当前没有需要执行的实例。此时可以点击 DAG 右上角的“触发运行”按钮手动生成一次运行观察任务状态颜色变化。4.3 快速验证任务是否正常的判断方式跑一个任务后判断是否正常不能只看界面上的颜色是绿色还是红色。更可靠的顺序是看 DAG 界面的 Run 记录确认 DagRun 是否创建。看 TaskInstance 列表确认每个 task 是否成功。点进单个任务查看日志确认最终输出是否是预期结果。如果失败先看失败节点的日志再看输入数据、依赖包、环境变量。这里尤其强调看日志。Airflow 界面上的颜色只是结果提示真正排查问题要依赖日志。颜色告诉我们“哪里坏了”日志告诉我们“为什么坏”。5. 从 Demo 到生产日志、权限、重试、告警和资源边界很多团队用 Airflow 跑通了一个 Demo 后就直接把一批任务搬上去。结果跑了一周就发现各种问题一个任务失败后没有自动重试日志分散在不同机器上找不到调度器内存暴涨某个人误触发了一个任务导致数据重复写入。这些问题不是 Airflow 的 bug而是缺少生产化的配置与运维意识。5.1 先改这几个关键配置在airflow.cfg里有大量可调参数。从生产经验看这些配置往往先优化优先级最高executor从SequentialExecutor切换为LocalExecutor或CeleryExecutor否则无法并发。sql_alchemy_conn把元数据库切换成 PostgreSQL替换 SQLite。parallelism控制 Airflow 全局同时运行的任务数初始值不要开太大。dag_concurrency每个 DAG 内可以同时运行的任务数。max_active_runs_per_dag同一个 DAG 允许同时存在的运行次数数据任务一般设 1 或 2避免重复写入。default_timezone设置时区建议统一为业务所在时区。这些参数不是越大越好。实际落地时先小规模跑几天观察任务耗时、资源占用再逐步调大。直接把并发拉满很可能把数据库或 Worker 打挂。5.2 失败重试、告警和日志收集生产调度必须接受“任务会失败”这个事实。失败不可怕可怕的是失败后没有被发现或者重试策略不对导致下游在错误数据上继续计算。Airflow 为每个任务提供retries和retry_delay参数。以 PythonOperator 为例task PythonOperator( task_idhandle_data, python_callablerun_handle_data, retries3, retry_delaytimedelta(minutes5), )这样可以做到一次失败后自动重试。但要注意重试不应该是无限次。重试次数越多任务堆积的风险越高。比较稳妥的是先设 2 到 3 次重试间隔逐步拉长如果仍然失败通过on_failure_callback发送告警到钉钉、企业微信、Slack 或邮件。日志方面Airflow 默认把日志写到本地文件。生产环境一般把日志存储配置到remote_logging可以接入 S3 或云对象存储这样才能在多 Worker 场景下统一查看日志。Airflow 提供了[logging]配置项但不建议自己在代码里拼路径直接用task_instance.log_url或 Web UI 上的日志入口即可。5.3 权限控制和团队协作Airflow 自带基于角色和用户的权限控制。生产环境应该遵循最小权限原则管理员角色负责 DAG 部署、配置修改、用户管理。运维角色可以触发、暂停、重跑 DAG看日志。开发角色只能查看自己负责的 DAG。访客角色只能只读查看。不要每个人都发 Admin 权限。Airflow 的 UI 上很容易触发“手动运行”和“清除任务状态”如果不小心误操作可能造成数据重复写入或任务重跑。这类问题在生产事故排查中很常见。5.4 常见问题的排查链路如果发现 Airflow 表现异常建议按以下链路排查而不是直接重启进程先看现象是调度不触发、任务失败、Web UI 打不开还是任务一直被排队再看输入DAG 文件是否有语法错误start_date、schedule是否符合预期上游数据是否就绪再看环境Scheduler 是否在运行元数据库连接是否正常Worker 是否启动磁盘和内存是否充足再看参数并发数、重试次数、超时时间是否配置不合理catchup是否误开启最后查日志Scheduler 日志、Web Server 日志、任务日志、元数据库日志一层层看。Airflow 有一个特点Scheduler 是常驻进程它启动时会对 DAG 文件做解析和导入。如果你改了 DAG 文件但 Scheduler 没有重启有时会出现 DAG 未更新的现象。这时候需要看 Scheduler 日志里的 DAG 解析情况而不是急着重启 Web Server。6. 最终判断Airflow 适合谁不适合谁Airflow 是一个优秀的调度器但它不是银弹。一个工具的价值只有放在合适的场景里才能充分体现。6.1 适合的场景Airflow 最适合的是有明确依赖关系、按时间周期运行的批处理工作流。典型例子包括ETL 数据管道需要从多个数据源抽取、转换、加载。机器学习训练流程依赖数据准备、特征工程、模型训练、评估、部署多个环节。报表任务每天凌晨生成前一天的数据报表失败后需要重试和告警。多系统之间的业务数据同步既要保证顺序又要能够看到每一步的执行状态。在这些场景里Airflow 提供的 DAG 表达、状态可视化、重试机制、日志收集和权限控制能够显著降低团队协作成本。6.2 不适合的场景Airflow 不适合对延迟要求极高的实时任务。DAG 的调度周期最小粒度主要受 cron 控制虽然可以做到分钟级但秒级、毫秒级的事件处理不是它的设计目标。实时流处理应该交给 Flink、Spark Streaming 或 Kafka Streams 这类流式计算引擎。Airflow 也不适合单纯“每隔几秒跑一次”的高频短任务。每次调度都要经过 Scheduler 生成实例、元数据库记录状态、Executor 分配资源的过程高频调度会产生大量元数据开销。另外如果只是几十个固定任务、没有依赖关系、也不需要可视化和告警那么 crontab 或写一个脚本调用统一入口也能解决。Airflow 的价值需要一定规模才能体现。不要因为它功能丰富就直接上先想清楚团队当前的痛点是“没定时”还是“工作流不可控”。6.3 如果决定引入 Airflow建议按什么节奏推进从一个实际项目经验看我建议分三步走先把最小流程跑通单机 LocalExecutor一个 DAG三个任务验证调度、依赖、日志和颜色状态。再补齐生产配置切换 PostgreSQL、设置时区、配置重试和告警、调整并发参数。最后逐步迁移真实任务先把低风险、非核心的报表任务迁移进去跑熟之后再接入核心数据管道。在第二步到第三步之间最好先做一次全流程演练人为制造一个任务失败观察重试、告警、日志定位和恢复流程是否顺畅。这套演练往往比长时间稳定运行更能发现生产环境的问题。说到底Airflow 的 Colors 只是它的“表达层”。颜色能让你一眼知道哪里有问题但真正让一个调度系统支撑生产的是它背后的可观测性、健壮性和工程配置能力。以后你再看到 Airflow 界面上各种颜色的任务状态不要只把它当作视觉设计而要把它们看作一套完整的运维语言。先理解状态再理解机制然后根据自己的场景把配置一项项调对这样一个“生产调度器”才算真正被用起来。 
长河君 · 2026/8/28 4:35:55 · 阅读 1.2k Apache Airflow 生产级工作流调度：从 DAG 到可观测性实践
调度任务这件事很多团队都经历过从“能用”到“好用”再到“可用”的过程。最开始用 crontab简单直接后来任务变多出现依赖关系、需要重试、要追溯失败原因还要让不同的人都能看懂整体流程这时候就会发现单纯的定时工具根本撑不住。Apache Airflow 就是在这样的背景下进入视野的。它不是又一个“定时执行脚本”的小工具而是一个生产级的工作流调度平台。更值得留意的是它的标题里写了“built with Colors”——这不是在说界面好看而是 Airflow 在设计上把工作流的运行状态用颜色清晰地呈现出来。可以说Airflow 真正解决的不是“到点触发”而是让复杂工作流的状态变得可见、可追踪、可协作。这个判断是理解 Airflow 一切设计的前提。我在早期接触 Airflow 时也有一个误区以为它只是 crontab 的加强版。后来把几个真实的数据任务放进去跑才发现核心差异在“编排”和“可观测性”。Airflow 把你关注的任务定义成 DAG调度器负责按时触发执行器负责真正运行元数据库记录一切状态变化Web 界面则把每个 task 实例的运行结果用颜色、标签、日志完整地暴露出来。这样一套机制下来调度器才真正具备“生产可用”的底气。围绕这个理念我从安装部署、DAG 开发、生产落地和适用边界几个角度把 Airflow 的使用经验拆开讲一讲。1. 先搞清楚 Airflow 解决的不是“定时”而是“工作流编排”Airflow 经常被拿来和 crontab、APScheduler、Celery Beat 之类的东西对比。如果只讨论“能不能定时”这些工具都能做到。但生产场景里的任务往往不是孤立的。一个典型的数据管道可能包含抽数、清洗、特征计算、模型推理、结果入库每个步骤之间有先后依赖某些步骤失败后需要自动重试重试仍失败时还要发告警。任务一多这种依赖关系就会变成一团乱麻。1.1 从 crontab 到 DAG依赖关系才是重点crontab 只能表达“在某个时刻运行某条命令”它本身不关心你上一道任务有没有成功。你自然可以用 shell 脚本拼接来实现串行但一旦遇到分支、并行、超时、重试次数、失败通知脚本就会变得越来越难维护。Airflow 用 DAG有向无环图来建模工作流。DAG 的每一个节点是一个 Task节点之间的连线表示依赖。你写的不再是“跑完 A 再跑 B 再跑 C”的命令串而是一份结构化的流程定义。Airflow 调度器会依据 DAG 结构、任务依赖、调度时间自动决定哪些任务可以并行、哪些必须等上游完成后才能启动。这种表达方式带来的长期价值非常直接流程是代码可以版本控制依赖是显式的可以审查任务状态是可查的出问题了能知道卡在哪个环节。1.2 Airflow 的核心组件Scheduler、Executor、Worker、Web Server、Metadata DB要理解 Airflow 的生产能力得先知道它由哪些关键部分组成。Scheduler负责根据 DAG 的定义和调度周期生成 DagRun 和 TaskInstance并判断哪些任务该执行。Executor决定任务用什么方式执行。默认的 SequentialExecutor 只能逐个执行适合本机调试LocalExecutor 可以并行跑多个任务CeleryExecutor 则把任务分发到多个 Worker 上适合分布式部署。Worker实际执行任务实例的进程。Web Server提供界面可以查看 DAG 结构、任务状态、日志手动触发或暂停任务。Metadata DB存储 DAG、任务实例、执行记录、变量、连接信息等。生产环境一般使用 PostgreSQL 或 MySQL而不是默认的 SQLite。这五个角色共同构成了一个完整的调度系统。换句话说Airflow 不只是“跑起来就行”它需要你把元数据库、执行器、时区、日志存储这些生产组件都规划好。很多初学者只在单机用 SequentialExecutor SQLite跑 Demo 没问题但一旦任务多并发高就会频繁踩到资源锁和性能瓶颈。2. 为什么生产级调度器需要 Colors任务状态可视化设计回到项目的标题“built with Colors”。Airflow 的 Web UI 里每个 task 的实例都用颜色标识状态。这不是装饰性的设计而是一套高效的状态沟通语言。在运维和协作场景中“看到绿色就知道成功看到红色就知道失败看到黄色就知道在重试”这件事比任何一行日志都快。2.1 颜色背后的状态机TaskInstance 的状态转换Airflow 中每个 TaskInstance 都有明确状态常见的包括running正在执行。success成功结束。failed执行失败。upstream_failed上游任务失败当前任务没有被执行。skipped遇到分支条件不满足被跳过。up_for_retry失败后正在等待重试。queued已经排队等 Executor 分配资源。这些状态在界面里对应不同颜色比如绿色表示成功红色表示失败灰色表示跳过橙色或黄色表示等待重试。你打开一个 DAG 的运行视图一眼就能看出整个流程当前是通畅的还是堵在哪一步。更重要的是这样的状态设计让“发现问题”从“看日志找原因”变成了“先看颜色定位节点再进日志查细节”。生产调度中时间就是成本。一个依靠颜色缩小的排查范围可以直接决定故障恢复速度。2.2 可观测性是生产调度的底层能力调度工具如果只能按时启动任务那和高级 crontab 没有本质区别。Airflow 把调度变成了一整套可观测的流程DAG 结构、任务状态、运行时长、日志、执行时间记录全部落库并且暴露在界面上。这种可观测性在运维层面产生了一个重要后果任务执行不再是一个黑盒。你可以明确回答这几个问题上次完整跑成功是什么时候某一次运行整体花了多久失败的 task 是在哪个环节、因为什么报错有没有任务重试过重试结果如何这些信息在数据任务、批量计算、周期性报告这些场景里是团队协作的基础。Colors 正是这套可观测性设计最表层的表达。在没有颜色可视化之前你只能通过命令查数据库有了颜色和图形化展示整个流程的状态可以被一眼读取。3. 从零安装部署 Apache Airflow最小可用环境搭建看了不少概念还是先落地跑起来。安装 Airflow 并不复杂但要分清“跑通”和“生产可用”两种状态。下面这套流程适合在本机或一台 Linux 服务器上搭建一个最小可用环境用于学习和验证。3.1 环境准备与依赖安装建议使用 Python 3.8 或更高版本独立虚拟环境。原因很简单Airflow 依赖众多直接装到系统 Python 里容易和已有包冲突。mkdir airflow-project cd airflow-project python3 -m venv venv source venv/bin/activate然后安装 Apache Airflow。需要注意Airflow 的安装包名称是apache-airflow不是airflow。不同版本对 Python 版本要求不同安装前先确认你选择的版本和 Python 版本兼容。以 Airflow 2.x 为例常见安装命令是pip install apache-airflow2.9.1如果使用国内网络环境可以加上镜像源参数。安装完成后检查版本airflow version3.2 初始化元数据库和创建管理员账号Airflow 默认使用 SQLite 作为元数据库适合初次体验。执行export AIRFLOW_HOME$PWD/airflow_home airflow db initAIRFLOW_HOME是 Airflow 的配置和文件目录之后看到的airflow.cfg、dags文件夹都从这里开始。初始化完成后创建管理员账号用于登录 Web UIairflow users create \ --username admin \ --firstname Admin \ --lastname User \ --role Admin \ --email adminexample.com命令执行过程中会提示设置密码。你可以按自己的规则设置一个临时密码之后登录 Web UI 用。3.3 启动 Web Server 和 SchedulerAirflow 是“Web Server Scheduler”两个进程协作。开发环境要开两个终端airflow webserver --port 8080另一个终端启动调度器airflow scheduler启动后访问http://localhost:8080用刚才创建的 admin 用户登录。此时 Airflow 已经能运行但默认的 Executor 是 SequentialExecutor元数据库是 SQLite只适合本地验证。如果你要跑并行任务需要切到 LocalExecutor 并改用 PostgreSQL 或 MySQL。实际生产环境一般还会用 CeleryExecutor 加多 Worker这个后面再展开。4. 写出第一个可观测的 DAG结构、调度器和执行器的协作Airflow 最核心的代码资产就是 DAG 文件。DAG 文件放在AIRFLOW_HOME/dags目录下Airflow 的 Scheduler 会周期性扫描这个目录把 DAG 读入元数据库并展示在 Web UI 上。4.1 一个最小 DAG 的结构下面是一个常见的最小 DAG 示例。它定义了两个 tasktask_a 执行完后执行 task_bfrom datetime import datetime, timedelta from airflow import DAG from airflow.operators.python import PythonOperator def print_hello(): print(hello from airflow) def print_done(): print(task done) with DAG( dag_idmy_first_dag, start_datedatetime(2024, 1, 1), scheduledaily, catchupFalse, tags[example], ) as dag: task_a PythonOperator( task_idprint_hello, python_callableprint_hello, ) task_b PythonOperator( task_idprint_done, python_callableprint_done, ) task_a task_b这个 DAG 有很多值得解读的地方。start_date调度起始时间Airflow 会从指定时间开始生成执行计划。schedule调度频率daily表示每天执行一次也可以写成0 8 * * *这样的 cron 表达式。catchupFalse关闭补跑。如果不关Airflow 默认会从start_date到现在区间内所有未执行的计划全部补跑一遍。这往往是新人最容易踩的坑。一旦你设置了一个较早的start_date且没有关闭catchup一启动调度器就可能触发几十上百个任务实例。task_a task_b用位移符定义依赖关系表示 task_b 必须等 task_a 成功后才能执行。把这个文件保存到 dags 目录等待几个调度周期Web UI 上就会出现my_first_dag。4.2 Scheduler、Executor 和 TaskInstance 的协作过程当你看到 DAG 出现在界面里并不代表任务已经被执行。真正决定“什么时候跑、怎么跑”的是 Scheduler 和 Executor。整个流程大致是Scheduler 扫描 DAG 文件检查当前时间是否满足 DAG 的调度条件。如果满足生成一个新的 DagRun。根据依赖关系Scheduler 找到所有可以运行且还没有运行的任务为它们创建 TaskInstance。Executor 接收这些 TaskInstance决定在本地线程、进程池还是远程 Worker 上执行。任务执行完成后状态写回 Metadata DB。Web UI 从 Metadata DB 中读取状态用颜色展示给用户。所以你会碰到一种情况DAG 已经出现在界面上但是所有任务都是空白没有变成运行状态颜色。这通常是因为 Scheduler 认为还没到调度时间或者start_date在很久以前且catchupFalse导致当前没有需要执行的实例。此时可以点击 DAG 右上角的“触发运行”按钮手动生成一次运行观察任务状态颜色变化。4.3 快速验证任务是否正常的判断方式跑一个任务后判断是否正常不能只看界面上的颜色是绿色还是红色。更可靠的顺序是看 DAG 界面的 Run 记录确认 DagRun 是否创建。看 TaskInstance 列表确认每个 task 是否成功。点进单个任务查看日志确认最终输出是否是预期结果。如果失败先看失败节点的日志再看输入数据、依赖包、环境变量。这里尤其强调看日志。Airflow 界面上的颜色只是结果提示真正排查问题要依赖日志。颜色告诉我们“哪里坏了”日志告诉我们“为什么坏”。5. 从 Demo 到生产日志、权限、重试、告警和资源边界很多团队用 Airflow 跑通了一个 Demo 后就直接把一批任务搬上去。结果跑了一周就发现各种问题一个任务失败后没有自动重试日志分散在不同机器上找不到调度器内存暴涨某个人误触发了一个任务导致数据重复写入。这些问题不是 Airflow 的 bug而是缺少生产化的配置与运维意识。5.1 先改这几个关键配置在airflow.cfg里有大量可调参数。从生产经验看这些配置往往先优化优先级最高executor从SequentialExecutor切换为LocalExecutor或CeleryExecutor否则无法并发。sql_alchemy_conn把元数据库切换成 PostgreSQL替换 SQLite。parallelism控制 Airflow 全局同时运行的任务数初始值不要开太大。dag_concurrency每个 DAG 内可以同时运行的任务数。max_active_runs_per_dag同一个 DAG 允许同时存在的运行次数数据任务一般设 1 或 2避免重复写入。default_timezone设置时区建议统一为业务所在时区。这些参数不是越大越好。实际落地时先小规模跑几天观察任务耗时、资源占用再逐步调大。直接把并发拉满很可能把数据库或 Worker 打挂。5.2 失败重试、告警和日志收集生产调度必须接受“任务会失败”这个事实。失败不可怕可怕的是失败后没有被发现或者重试策略不对导致下游在错误数据上继续计算。Airflow 为每个任务提供retries和retry_delay参数。以 PythonOperator 为例task PythonOperator( task_idhandle_data, python_callablerun_handle_data, retries3, retry_delaytimedelta(minutes5), )这样可以做到一次失败后自动重试。但要注意重试不应该是无限次。重试次数越多任务堆积的风险越高。比较稳妥的是先设 2 到 3 次重试间隔逐步拉长如果仍然失败通过on_failure_callback发送告警到钉钉、企业微信、Slack 或邮件。日志方面Airflow 默认把日志写到本地文件。生产环境一般把日志存储配置到remote_logging可以接入 S3 或云对象存储这样才能在多 Worker 场景下统一查看日志。Airflow 提供了[logging]配置项但不建议自己在代码里拼路径直接用task_instance.log_url或 Web UI 上的日志入口即可。5.3 权限控制和团队协作Airflow 自带基于角色和用户的权限控制。生产环境应该遵循最小权限原则管理员角色负责 DAG 部署、配置修改、用户管理。运维角色可以触发、暂停、重跑 DAG看日志。开发角色只能查看自己负责的 DAG。访客角色只能只读查看。不要每个人都发 Admin 权限。Airflow 的 UI 上很容易触发“手动运行”和“清除任务状态”如果不小心误操作可能造成数据重复写入或任务重跑。这类问题在生产事故排查中很常见。5.4 常见问题的排查链路如果发现 Airflow 表现异常建议按以下链路排查而不是直接重启进程先看现象是调度不触发、任务失败、Web UI 打不开还是任务一直被排队再看输入DAG 文件是否有语法错误start_date、schedule是否符合预期上游数据是否就绪再看环境Scheduler 是否在运行元数据库连接是否正常Worker 是否启动磁盘和内存是否充足再看参数并发数、重试次数、超时时间是否配置不合理catchup是否误开启最后查日志Scheduler 日志、Web Server 日志、任务日志、元数据库日志一层层看。Airflow 有一个特点Scheduler 是常驻进程它启动时会对 DAG 文件做解析和导入。如果你改了 DAG 文件但 Scheduler 没有重启有时会出现 DAG 未更新的现象。这时候需要看 Scheduler 日志里的 DAG 解析情况而不是急着重启 Web Server。6. 最终判断Airflow 适合谁不适合谁Airflow 是一个优秀的调度器但它不是银弹。一个工具的价值只有放在合适的场景里才能充分体现。6.1 适合的场景Airflow 最适合的是有明确依赖关系、按时间周期运行的批处理工作流。典型例子包括ETL 数据管道需要从多个数据源抽取、转换、加载。机器学习训练流程依赖数据准备、特征工程、模型训练、评估、部署多个环节。报表任务每天凌晨生成前一天的数据报表失败后需要重试和告警。多系统之间的业务数据同步既要保证顺序又要能够看到每一步的执行状态。在这些场景里Airflow 提供的 DAG 表达、状态可视化、重试机制、日志收集和权限控制能够显著降低团队协作成本。6.2 不适合的场景Airflow 不适合对延迟要求极高的实时任务。DAG 的调度周期最小粒度主要受 cron 控制虽然可以做到分钟级但秒级、毫秒级的事件处理不是它的设计目标。实时流处理应该交给 Flink、Spark Streaming 或 Kafka Streams 这类流式计算引擎。Airflow 也不适合单纯“每隔几秒跑一次”的高频短任务。每次调度都要经过 Scheduler 生成实例、元数据库记录状态、Executor 分配资源的过程高频调度会产生大量元数据开销。另外如果只是几十个固定任务、没有依赖关系、也不需要可视化和告警那么 crontab 或写一个脚本调用统一入口也能解决。Airflow 的价值需要一定规模才能体现。不要因为它功能丰富就直接上先想清楚团队当前的痛点是“没定时”还是“工作流不可控”。6.3 如果决定引入 Airflow建议按什么节奏推进从一个实际项目经验看我建议分三步走先把最小流程跑通单机 LocalExecutor一个 DAG三个任务验证调度、依赖、日志和颜色状态。再补齐生产配置切换 PostgreSQL、设置时区、配置重试和告警、调整并发参数。最后逐步迁移真实任务先把低风险、非核心的报表任务迁移进去跑熟之后再接入核心数据管道。在第二步到第三步之间最好先做一次全流程演练人为制造一个任务失败观察重试、告警、日志定位和恢复流程是否顺畅。这套演练往往比长时间稳定运行更能发现生产环境的问题。说到底Airflow 的 Colors 只是它的“表达层”。颜色能让你一眼知道哪里有问题但真正让一个调度系统支撑生产的是它背后的可观测性、健壮性和工程配置能力。以后你再看到 Airflow 界面上各种颜色的任务状态不要只把它当作视觉设计而要把它们看作一套完整的运维语言。先理解状态再理解机制然后根据自己的场景把配置一项项调对这样一个“生产调度器”才算真正被用起来。