企业官网建设流程全解析

Apache Airflow 3 工作流调度完整指南：10 分钟跑通第一个 DAG

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

凌晨两点，上游数据还没同步完，下游评估任务只能空转，你盯着终端日志刷新。Apache Airflow 是一个用于工作流调度和任务编排的平台：流程用代码定义，按依赖自动执行，每一步状态都留痕。

它解决的是什么问题

• 流程散落在十几个 shell 脚本里，改一处顺序要翻半天。把依赖写成代码后，改动可 diff、可回滚，DAG 结构一目了然。
• 夜里任务挂了没人知道，第二天用户先于你发现问题。调度器自动重试并记录每一次状态，失败留痕而不是口头交接。
• 任务跑到哪、卡在哪说不清。UI 把每个任务的前置依赖和当前状态画出来，问题定位从"翻日志"变成"看红框"。
• 每天重复的准备、运行、核对动作占掉大量工时。定时调度接管后，人只在失败和变更时介入。

30 秒看懂核心机制：DAG 与任务依赖

把 DAG 想成餐厅的出单流程：每个任务是后厨的一张工单，工单上有前置条件——配菜没好，主菜工单不会递到灶台。厨师长（调度器）盯工单板，把已就绪的工单分给不同灶位（Worker）并行做，做完在板上打勾。你只定义工单和顺序，谁先做、何时重试、结果如何，都由板上状态决定，任务之间靠依赖连接而不是靠人传话。

界面里的 Graph 视图就是这块"工单板"：绿框是成功的任务，红框是失败的，右侧面板记录本次运行的起止时间和耗时。

跑通第一个任务：安装、启动与最小 DAG

Airflow 3 的 standalone 模式用一个命令同时拉起调度器、API 服务和 Web 界面，适合先跑通再谈部署。没有 uv 的话也可以用pipx run "apache-airflow" standalone，详见安装指南。

# 一个命令拉起调度器、API 服务和 Web 界面 uvx apache-airflow standalone

启动后浏览器打开 http://localhost:8080（默认账号和密码均为 admin）。把 DAG 放进~/airflow/dags/目录，Airflow 会定期自动发现，无需重启。

最小示例只有两个任务，用>>声明依赖：

from datetime import datetime from airflow import DAG from airflow.operators.python import EmptyOperator with DAG(dag_id="hello_airflow", start_date=datetime(2025, 1, 1), schedule="@daily") as dag: EmptyOperator(task_id="check_source") >> EmptyOperator(task_id="prepare")

保存为dags/hello.py，刷新界面，这条 DAG 就会出现，并带有每日一次的运行计划。

搬进一个真实场景：ML 训练流水线的定时编排

以模型重训为例：每晚同步当天数据、训练、评估，全程无人值守，失败会停下并标红。

from datetime import datetime from airflow import DAG from airflow.operators.bash import BashOperator with DAG(dag_id="model_retrain", start_date=datetime(2025, 1, 1), schedule="0 2 * * *") as dag: sync = BashOperator(task_id="sync_data", bash_command="python -m data.sync --date {{ ds }}") train = BashOperator(task_id="train", bash_command="python -m model.train") evaluate = BashOperator(task_id="evaluate", bash_command="python -m model.eval") sync >> train >> evaluate

它每晚 2 点自动完成"拉数据→训练→评估"三步，{{ ds }}是 Airflow 内置模板变量，自动替换为本次运行的日期。

稳定运行：看哪里、怎么排障

• 先看 Graph 视图的颜色：红框任务点进去，右侧有日志、参数和 XCom 结果，多数失败原因在日志最后几行。
• 再看排队与执行的间隔：Queued At 到 Start Date 间隔变长，说明并发池（Pool）被占满，是排队问题不是脚本问题；Duration 变长才是执行变慢。
• 任务长期停在 Scheduling 状态：通常调度器没在跑或池已满，先查调度器进程和池配置，而不是怀疑任务本身。

走向生产：单机还是容器化部署

判断标准很简单：团队小、DAG 在几十条以内、一台机器扛得住，standalone 直接当生产用；DAG 上百条、峰值并发高、需要给调度器和 Worker 分开扩缩容，就切容器化（Docker Compose，或 Kubernetes 加官方 Helm Chart）。SQLite 只适合本地，生产用 PostgreSQL：

# docker-compose.yml（示意） services: airflow: image: apache/airflow:3.3.0 command: standalone environment: AIRFLOW__DATABASE__SQL_ALCHEMY_CONN: postgresql://airflow:airflow@db/airflow depends_on: [db] volumes: ["./dags:/opt/airflow/dags"] db: image: postgres:16

图里每个组件都可以独立扩展：Dag 处理器负责解析你的代码，调度器和执行器按依赖派发任务，Worker 只做执行，所有状态统一落在元数据库。扩哪一块，就看瓶颈在解析、调度还是执行。部署细节参考生产部署指南。

进阶与避坑：三个最常见的坑

• 别用 XCom 传大数据：XCom 存的是元数据，数据上量后先写对象存储或数据库，任务间只传路径。
• 任务必须幂等：Airflow 会重试，重跑不能产生重复数据，写库、发消息这类副作用要做成可重入。
• SQLite 只用于本地：官方明确生产不要用 SQLite，上线前切到 PostgreSQL，避免元数据库成为单点。

把开头两个 DAG 各跑一遍，"代码即流程"就不再是口号。接着看 DAG 编写教程，照着官方文档搭出你的第一个生产级工作流调度流水线。

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