企业官网建设流程全解析

Apache Airflow 3 保姆级实战指南：三步跑通工作流，完成调度与监控

【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow

Apache Airflow 是用代码定义工作流的调度平台，解决"数据任务多、依赖复杂、没人盯执行结果"的问题。读完本文，你能在本地三步把它跑起来，写出每天自动运行的统计 DAG，并在 UI 里查看执行状态与失败原因。

一句话说清它是什么

一句话：Airflow 把你写的 Python 文件变成一张"可调度、可重试、可审计"的任务依赖图。对比传统做法：

三步跑通最小可用环境：Apache Airflow 3 快速上手

下面 3 条命令完成安装与启动，standalone会初始化数据库、创建管理员用户，并把调度器等组件一起拉起。

python -m venv .venv && source .venv/bin/activate pip install apache-airflow airflow standalone

• 启动成功后浏览器打开http://localhost:8080。
• Airflow 3 的 admin 密码是自动生成的，写入$AIRFLOW_HOME/simple_auth_manager_passwords.json.generated，不是默认的 admin/admin。
• 系统自带example_bash_operator等示例 DAG，在首页开启后即可看到任务跑起来变绿，先感受"跑起来"的效果。

核心概念白话拆解

DAG：工作流的"地图"

• 它是什么：一个 Python 文件声明的一组任务，以及它们之间的先后依赖。
• 为什么必须有：没有它，调度器不知道先跑谁；有了它，UI 能画图，失败时能定位断在哪条边上。
• 在界面上长什么样：Graph 视图里每个节点是一个任务，连线表示执行顺序，节点颜色代表状态。

任务与它的状态生命周期

• 它是什么：DAG 上的一个节点，是调度和重试的最小单位。
• 为什么必须有：重试、并发、失败通知都作用在任务粒度上，出问题时"只重跑失败的那个"。
• 在界面上长什么样：状态从 scheduled 到 queued、running、success 流转；失败后，下游会被直接标记为 upstream_failed，不浪费执行资源。

三个核心组件：Dag Processor、Scheduler、Worker

• 它是什么：Dag Processor 负责把 DAG 文件解析成元数据，Scheduler 决定什么时间跑什么，Worker 真正执行代码。
• 为什么必须有：Airflow 3 把用户代码与元数据库隔离，组件可独立部署、独立扩容。
• 在界面上长什么样：首页顶部的 Health 横条逐项显示各组件运行状态，变红就对应到组件去排查。

用一个真实场景完整走一遍：每日营收统计 DAG

场景：电商业务要每天统计营收——拉取订单、聚合计算、低于阈值就告警。完整 DAG 如下：

from datetime import datetime from airflow import DAG from airflow.operators.python import PythonOperator def fetch_orders(): # 从业务库拉取当日订单 return {"orders": 128} def calc_revenue(data): # 按渠道聚合营收 print(f"total revenue: {data['orders'] * 99}") def alert_if_low(data): # 营收低于阈值时发通知 print("revenue below threshold, notify") with DAG(dag_id="daily_revenue", start_date=datetime(2024, 1, 1), schedule="@daily", catchup=False): fetch = PythonOperator(task_id="fetch_orders", python_callable=fetch_orders) calc = PythonOperator(task_id="calc_revenue", python_callable=calc_revenue) alert = PythonOperator(task_id="alert_if_low", python_callable=alert_if_low) fetch >> calc >> alert

为什么这么设计：

• 一个任务只做一件事：失败重试粒度小，不用整链重跑。
• >>声明依赖：不手动管理执行顺序，UI 直接渲染出依赖图。
• catchup=False：首次上线只跑当天，避免把历史日期一次性补跑爆炸。

DAG 被解析后，Overview 页会列出本次运行全部任务及其状态：

上线前必须知道的 3 件事

1. standalone 不适合生产：它是开发模式，生产环境把 API server、scheduler、dag-processor、worker 拆开独立部署并扩容，参考生产部署文档。
2. 盯住三个指标：失败 DAG 数、任务实例成功率、池剩余槽位（首页 Pool Slots 横条）；任务排队时长持续上涨就是资源不够的信号。
3. 两个高频坑：改 DAG 代码要等 Dag Processor 重新解析后才生效；凭据不要写死在代码里，用 Connections/Variables 管理，UI 会自动脱敏。

高频问题 FAQ

问：DAG 文件写好了，UI 里为什么看不到？答：文件要先被 Dag Processor 解析才可见，且必须放在 dags 目录（standalone 下为~/airflow/dags）。若终端报了语法错误，该文件会被整体跳过。

问：@daily能改成具体时间点吗？答：可以，schedule直接传 cron 表达式，如schedule="0 2 * * *"表示每天凌晨 2 点，"0 9 * * 1-5"表示仅工作日。

问：状态是 "upstream failed" 是什么意思？答：当前任务没执行，是它依赖的上游任务失败了。先修红色的上游任务，重试成功后再手动重跑下游。

Airflow 的核心思路只有一条：用代码描述工作流，把执行、重试、审计交给系统。挑一个你每天重复跑的数据任务，按上面的模式改写成 3 个任务的 DAG。更完整的步骤见官方快速上手文档。

【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow