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 视图就是这块工单板绿框是成功的任务红框是失败的右侧面板记录本次运行的起止时间和耗时。跑通第一个任务安装、启动与最小 DAGAirflow 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_idhello_airflow, start_datedatetime(2025, 1, 1), scheduledaily) as dag: EmptyOperator(task_idcheck_source) EmptyOperator(task_idprepare)保存为dags/hello.py刷新界面这条 DAG 就会出现并带有每日一次的运行计划。搬进一个真实场景ML 训练流水线的定时编排以模型重训为例每晚同步当天数据、训练、评估全程无人值守失败会停下并标红。from datetime import datetime from airflow import DAG from airflow.operators.bash import BashOperator with DAG(dag_idmodel_retrain, start_datedatetime(2025, 1, 1), schedule0 2 * * *) as dag: sync BashOperator(task_idsync_data, bash_commandpython -m data.sync --date {{ ds }}) train BashOperator(task_idtrain, bash_commandpython -m model.train) evaluate BashOperator(task_idevaluate, bash_commandpython -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:airflowdb/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Apache Airflow 3 工作流调度完整指南：10 分钟跑通第一个 DAG
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 视图就是这块工单板绿框是成功的任务红框是失败的右侧面板记录本次运行的起止时间和耗时。跑通第一个任务安装、启动与最小 DAGAirflow 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_idhello_airflow, start_datedatetime(2025, 1, 1), scheduledaily) as dag: EmptyOperator(task_idcheck_source) EmptyOperator(task_idprepare)保存为dags/hello.py刷新界面这条 DAG 就会出现并带有每日一次的运行计划。搬进一个真实场景ML 训练流水线的定时编排以模型重训为例每晚同步当天数据、训练、评估全程无人值守失败会停下并标红。from datetime import datetime from airflow import DAG from airflow.operators.bash import BashOperator with DAG(dag_idmodel_retrain, start_datedatetime(2025, 1, 1), schedule0 2 * * *) as dag: sync BashOperator(task_idsync_data, bash_commandpython -m data.sync --date {{ ds }}) train BashOperator(task_idtrain, bash_commandpython -m model.train) evaluate BashOperator(task_idevaluate, bash_commandpython -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:airflowdb/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考