2014年Airbnb搞了个内部工具管数据流程，十年后它成了数据工程的事实标准。但奇怪的是——这个工具本身不处理数据，只负责"喊开始"。

新手学数据工程，常被ETL、管道、编排这些词吓到。其实大部分术语只是听起来复杂。数据工程的本质很简单：从网站、社交媒体、表格或支付系统提取数据，清洗后存进数据库或数据仓库。跑一次用Python脚本就行，但要每小时、每天、每周自动跑，就得有个管家。这就是Apache Airflow的切入点。

打开网易新闻 查看精彩图片

用烤蛋糕理解工作流

烤蛋糕不会把所有东西扔进烤箱完事。你得按步骤来：准备面团→烘烤→裱花。有些步骤有先后，不能颠倒。还要知道每步耗时，以及搞砸了怎么办。

这种分步骤的过程就叫工作流或管道，Airflow就是管这个的。

关键点：Airflow通常不做重活的数据处理，它只告诉其他工具"该你上了"。

工作流可以是数据管道、机器学习管道、报表流程，或任何多步骤流程。典型长这样：

extract_data >> clean_data >> load_data >> send_email

箭头表示依赖关系，数据从提取流向清洗，再流向加载，最后发邮件通知。

编排到底是什么

编排（Orchestration）就是安排一堆任务按正确顺序、在预定时间运行。它确保任务B等任务A跑完再启动，还记录每个任务成功还是失败。

没有编排，你会有一堆脚本靠手动或单独的定时任务（cron job）运行。项目大了根本管不过来。

普通Python脚本应付简单任务还行，但任务一多就要更精细的控制。数据工作的特点就是环节多、依赖复杂。

Airflow的四个硬技能

1. 调度

数据工作大多是重复劳动，调度让工作流按设定时间自动跑。Airflow原生处理复杂时区逻辑，保证全球管道在准确时间点启动。

它还能通过"回填"（backfilling）自动为历史日期跑管道。比如你今天搭了个新管道，需要补跑过去三个月的数据，Airflow能自动处理。

2. 任务编排

任务按依赖关系排列。上游任务失败，下游不会盲目启动。Airflow会记录状态，让你看清整条链哪里断了。

3. 监控

（原文未展开具体监控机制，此处不编）

4. 扩展性

（原文未展开具体扩展机制，此处不编）

为什么偏偏是Airflow

开源、有社区、Python写配置——这三点让它在2014年后快速扩散。但核心原因更务实：数据团队需要一个"不抢活只派活"的调度层。

数据处理本身有Spark、Flink、dbt各种专用工具。Airflow不跟它们竞争，只解决"什么时候跑、跑完了吗、失败了怎么办"的元问题。这种定位让它成了基础设施的基础设施。

十年过去，数据栈换了多少轮，调度层反而越来越厚。Airflow的遗产可能是证明了：在数据工程里，"指挥"比"演奏"更稀缺。

当然，现在也有新玩家挑战它——Prefect、Dagster都在喊"Airflow太老了"。但替换成本摆在那里：成千上万条管道迁移，不是技术问题，是会计问题。

给新手的实用建议

别被术语吓到。DAG就是有向无环图，说人话就是"画个流程图，箭头别绕圈"。Operator就是"具体干什么"的模板，比如用PythonOperator跑函数，用BashOperator跑命令。

先从本地跑通一个三步骤的管道：提取→转换→加载。体会一下"失败重试"和"依赖等待"是什么意思。这比读十篇架构文章都有用。

记住Airflow的边界：它不替你处理数据，只保证处理按顺序发生。搞清楚这点，你就比一半自称"精通Airflow"的人清醒。

最后，烤蛋糕的比喻有个漏洞：真实烘焙你不会让烤箱等面团等三小时还发邮件催。但数据管道会——而且经常等。这就是为什么要专门雇个"管家"。