数据管道是任何公司数据基础架构中的关键组件。
许多公司用来管理其数据提取和转换的一种框架是 Airflow。无论是 100% 使用 Airflow 及其各种运算符，还是使用 Airflow 编排其他组件，例如 Airbyte 和dbt。
Airflow 是 2014 年在 Airbnb 开发的，作为一种帮助管理他们对复杂数据管道日益增长的需求的方法，它在 Airbnb 之外迅速普及，因为它是开源的并且满足了数据工程师的许多需求.
现在，近十年后，我们中的许多人已经开始看到它盔甲上的裂缝。我们已经看到了它的 Airflow-isms（Sarah Krasnik）。
反过来，这导致了 Python 数据管道空间中的许多新框架，例如 Prefect 和 Dagster。
我们中的许多人仍然依赖 Airflow。但 Airflow 也有相当多的怪癖和局限性。在团队尝试在要求更高的数据文化中生产和管理 Airflow 之前，其中的许多内容并不明显。
所以这次我想谈谈为什么数据工程师喜欢/讨厌Airflow。当然，我不只是想发表我的看法。相反，我采访了其他几位数据工程师，看看他们喜欢 Airflow 的哪些方面，以及他们觉得缺少哪些方面。
为什么我们喜欢Airflow
为什么 Airflow 在数据工程领域获得了如此强大的地位？引用 Airflow 的创建者在 2015 年写的一篇文章：
使用 Airflow 后，Airbnb 员工处理数据的工作效率和热情成倍增加。—马克西姆·博克明
Airflow 被证明是一种解决方案，可以在数据工程不断陷入一次性请求（等待这并没有改变）和不断迁移的情况下提高生产力。
当然，那是 Airbnb，他们必须采用自己的解决方案。那么为什么有这么多其他数据工程师选择它呢？
易于上手
Airflow 的一大优点是构建您的第一个玩具 DAG 非常容易。
首先，您需要做的就是编写一些参数化运算符。
之后，您可以运行：
airflow standalone
突然间，您正在运行 Airflow。在本地或可能在 EC2 实例上。
从那里开始，你就完成了。当然，我们没有考虑过扩展或日志会炸毁存储的事实，但在最初的几个月里，这会正常工作。
调度
Airflow 提供了一个易于理解的调度程序。使用基于 cron 的调度，开发人员可以轻松地将他们的 DAG 设置为每天、每小时、每周或其他任何时间运行。
从那里，Airflow 将负责运行这些作业。无需进入 cron 来更新何时运行脚本。相反，您可以将计划保存为代码的一部分。这在确保您不必搜索调度代理的位置以及使其成为代码的一部分方面都是有益的。
如此轻松地安排作业的能力对我来说是一大优势，因为我在之前的工作中花了很多时间试图弄清楚为什么 SQL Server 代理由于配置问题而无法在我的 SQL Server 实例上工作。
好吧，现在我的调度程序被捆绑到一个解决方案中。
依赖管理
点击见视频演示
在自定义数据管道解决方案中实现的一项棘手要求是创建依赖管理功能。在以前的生活中，数据工程师可能会简单地通过设置不同的任务以在其间手动设置的间隔运行来做到这一点。当然，这不是依赖管理。如果上一个任务失败，下一个任务仍然会运行。
就个人而言，这是我采用 Airflow 的主要原因。它允许我描述任务应该如何运行，并且如果前一个任务失败，则不允许相关任务运行。
这通常在 Airflows DAG 范例中表示，它创建了一个图表，您可以在其中轻松概述哪些任务依赖于什么。再加上在 UI 中跟踪所述任务并在故障点重新运行它们（而不是必须运行整个管道）的能力，我相信 Airflow 如此迅速地获得如此多的牵引力是有道理的。
我听说的其他原因
当然，开发人员采用 Airflow 的原因还有很多。以下是其他一些被提出来的。
- SQL 模板
- 强大的 OSS 社区
- 预定义组件和编写自己代码的灵活性之间的良好平衡
缺点
尽管 Airflow 很受欢迎，但它也有很多缺点。尤其是在尝试自己生产时。
缩放很难
大多数受访者可能同意的一点是，扩展 Airflow 很难。对于许多使用 Airflow 的公司来说，实际基础设施的管理会转移到 DevOps 或数据基础设施，因为它不可避免地最终成为一个人的工作，只是确保 Airflow 正在运行。
这是因为，就像过去的 Hadoop 一样，Airflow 需要大量额外的服务才能成功运行它。尤其是在规模上。如果您真的想了解更多关于如何在您的公司扩展 Airflow。查看下面的架构及其相应的文章。
在 Airflow 中轻松创建基本 DAG 可以吸引用户。但是如果您的团队不考虑这样一个事实，即随着越来越多的工作被创建，他们需要在生产中扩展整体架构，您最终会遇到很多问题。
在任务之间传递数据很笨重
当我问 Sarah Krasnik 她觉得 Airflow 有哪些限制时，她的回答是：
在任务之间传递信息。我相信这在 2.2+ 中得到了显着改进，尽管我没有使用特定的改进。XComs 的概念实在是太笨重了，而且很难搞定。— 莎拉·克拉斯尼克
和 Sarah 一样，我通过 Airflow 的表弟了解到 Airflow 在任务之间传递数据的困难。数据群。
Dataswarm 是 Airflow 的初始版本，反过来也有很多限制。其中之一是在任务之间传递数据非常困难。例如，每当我需要在任务之间传递数据时，我都必须将数据写入文本文件，然后在下一个任务中读取它。
很笨重
Airflow 确实提供 XComs 来传递数据。然而，即使在这里，它也会感觉有点笨拙，正如莎拉指出的那样，“很难做到正确”。
在某种程度上这是设计使然，但我会说我确实遇到了偶尔传递数据的需要，这总是令人沮丧的一点。
总而言之，Airflow 远非完美，我们中的许多人只是学会了处理它的局限性。
其他选项
当我采访所有不同的数据工程师时，他们中的许多人提到了Prefect和Dagster。这两种选择都旨在改善Airflow不足的地方。正如 Sarah 所说，Airflow 具有 Airflow-isms。Dagster 和 Prefect 改进了这些“-isms”。
因此，如果您正在寻找可能的替代方案，这两个可能是一个不错的选择。
Airflow2.X
对于许多试图扩展其数据管道基础设施的公司来说，Airflow 仍然是一个流行的框架。因为它很容易上手并且拥有强大的社区，我预计它将继续在数据工程领域发挥重要作用。尤其是通过托管解决方案和改进的最佳实践，Airflow 可能很难被取代。
Airflow 适合您吗？嗯，这个答案总是取决于你的团队规模、技能和预算。
你的经历是什么？您使用过 Airflow 还是更喜欢其他解决方案？