"为什么不只是使用克龙工作?"是每当有人看到一个气流DAG,我得到的第一个问题.
问得好 克龙作品.
相去数十由旬.
很简单 真正的答案不是说克龙是坏的——就是克龙解决了一个与气流不同的问题.
Cron是个工作日程安排员 它在一个固定的时间运行一个命令.
就是这样。
它不知道命令是否成功,它的依赖性是否满足,或者它是否今天甚至应该运行.
它只是发射命令然后继续前进。
Airflow是一个工作流程管弦乐手.
它不只是计划任务——它把它们模拟成一个依赖性的图表,跟踪它们的状态,重复失败的状态,并给你一个UI,看看什么运行,什么失败,为什么.
这就是区别的本质所在。
问题 cron无法解决 想象一下简单的 ETL 管道: 从 API 验证器中提取原始数据并将其清理到仓库中 运行一个转换 发送一个 Slack 提醒 如果任何故障 与 cron 连接,你会写出五个独立的 cron 条目, 每一步一个, 并希望计时成功。
如果第2步失败了,但第3步不管怎样运行,你现在的仓库里有坏的数据.
如果第四步一天需要两倍长,你已经悄悄地打破了你的解放军.
除非您手动在每个脚本中添加提醒逻辑,否则没有人被通知.
有了Airflow,你把这个模型作为DAG:Airflow保证了订单.
如果失败,就永远不要跑.
你得到自动重试,故障警报, 和一个网络UI, 确切显示管道的故障地点和原因。
气流如何实际安排一个DAG 这就是它变得有趣的地方。
气流不只是像克龙那样"在固定时间运行你的Python脚本".
当定义一个带有(或旧版本)的DAG时,Airflow不会直接将克龙表达式传递给OS调度器.
相反,它将其转换成一个时间表——一个决定DAG运行何时应创建的内部对象.
调度程序持续运行,每隔几秒钟检查是否有DAG根据自己的时间表准备运行.
当 DAG 到期时, 调度器为该执行日期创建 DagRun 对象并排队任务 。
实际执行发生在工人过程(通过你所配置的执行器——本地,Celery,或Kubernetes),而不是直接从调度器本身.
这有两个原因很重要:1.
根据数据间隔,而不是墙上小时的空气流量表。
使用DAG(每天早上6点)的DAG不会在早上6点运行来处理当时的数据.
它运行在6: 00处理上一个间隔的数据——通常是昨天,如果你在每天的日程上。
Airflow是数据间隔的开始,而不是任务实际运行的时间.
这就是为什么(更古老的Airflow版本的默认)可以让你惊讶:如果你在1月10日部署一个新的DAG,开始日期是1月1日,Airflow会立即为从1–9起每天创建DagRuns,并尝试全部回填,因为它认为你在处理这些间隔时落后了.
2.
调度器是状态和集中的。
与独立运行于每台机器上的克龙不同,Airflow的排程器是一个单一的过程(或HA设置中的一个小集群),它保持了对所有DAG,其排程,以及当前状态的全球视野.
它知道哪些任务正在运行,哪些是排队的,哪些是失败的,哪些是被上游的依赖性所阻挡.
这使得自动重试,SLA监控等功能得以实现,并且能够不触摸服务器而暂停或不暂停来自UI的DAG.
生产中真正重要的部分 真正的区别不是特征——事情出错时会发生什么.
Cron工作无声地失败.
日志分散在服务器之间.
回填缺失的运行意味着按正确的顺序手动重跑脚本.
放大到50+管道意味着管理数百个Crontab的条目,跨越多台机器,对运行或被破坏的东西没有中央可见度.
气流追踪一切——任务状态,执行历史,重试计数,解放军.
你可以回填一个