深入了解 Airflow、Prefect 和 Dagster 以及三者之间的区别！
互操作性目前还是现代数据技术的棘手的问题：数据管道仍然涉及不完全适合 ETL 工作流的自定义脚本和逻辑。无论是自定义内部服务，还是像下载文件、解压缩文件和读取其内容这样简单的事情，仍然需要编排工具。跨堆栈编排工作流是一个问题。
Apache Airflow、Prefect 和 Dagster 等都属于编排工具。这些工具是数据工程团队的基础。Apache Airflow 是三者中最老的一个，是经过实战考验且可靠的解决方案，它诞生于 Airbnb，由 Maxime Beauchemin 创建。那时，数据工程是一个不同的世界，主要关注定期安排的批处理作业，这些作业通常涉及带有 Hive 和 Druid 之类的丑陋系统。今天你仍然可以在 Airflow 中看到很多这样的传统。
Prefect 和 Dagster 是较新的产品，均受其云产品 Prefect Cloud 和 Dagster Cloud 的支持。Prefect Cloud 可免费启动并托管调度程序，而混合架构允许您在本地或基础架构上运行任务。Dagster Cloud 刚刚发布，处于抢先体验阶段！
什么是 Airflow，它的最佳替代品是什么？
Airflow 是一种用于编排分布式应用程序的工作流编排工具。它通过使用 DAG（有向无环图）跨不同服务器或节点调度作业来工作。Apache Airflow 提供了丰富的用户界面，可以轻松可视化通过管道的数据流。您还可以监控每个任务的进度并查看日志。
如果您曾经对 Airflow 中日期的工作方式感到困惑，那么您会看到其中的一些传统。很少有人对 Airflow 的新手不会对执行日期以及为什么他们的 DAG 没有按预期运行感到困惑。
今天的 Airflow 现在是一个 Apache 项目，它被 Apache 基金会采用巩固了该项目作为现状开源编排和调度工具的地位。今天，成千上万的公司使用 Airflow 来管理他们的数据管道，你很难找到一家在他们的堆栈中没有一点 Airflow 的大公司。Astronomer 和 AWS 等公司甚至提供托管 Airflow 即服务，因此围绕部署和维护实例的基础设施不再是工程团队关心的问题。
话虽如此，随着数据环境的变化，Airflow 在测试、非计划工作流、参数化、数据传输和存储抽象方面经常会遇到一些障碍。
在我们深入探讨其中的一些陷阱之前，有必要提一下 Airflow 的一些好处：毫无疑问，这个项目已经存在了十多年，得到了 Apache 基金会的支持，完全开源，并且被数千家公司使用是一个值得考虑的项目。在许多方面，使用 Airflow 是最安全的选择，社区支持和经过验证的实用性使它成为一个如此安全的选择，你甚至可能会争辩说，没有人因为选择 Airflow（可能）而被解雇。
例如，有关 Airflow 的 Stack Overflow 上的问题比其他任何竞争对手都多 2 个数量级。很有可能，如果您遇到问题，您并不孤单，并且希望其他人找到了解决方案。几乎所有您能想到的工具都有 Airflow Providers，让您可以轻松地使用现有数据工具创建管道。
随着数据环境的不断发展，数据团队正在使用他们的工具做更多的事情。他们正在构建复杂的管道以支持数据科学和机器学习用例，从各种系统和端点获取数据以将它们收集到仓库和数据湖中，并为跨多个数据系统的最终用户工具编排工作流。有一段时间，Airflow 是唯一真正可用的编排工具，因此许多团队试图将他们日益复杂的需求压缩到 Airflow 中，但经常碰壁。
我们在 Airflow 部署中看到的主要问题属于以下几类之一：
- 本地开发、测试和存储抽象
- 一次性和不定期的任务
- 任务之间的数据移动
- 动态和参数化的工作流程
我们将通过探索 Dagster 和 Prefect 这两种替代工具如何解决这些问题来深入探讨这些问题。
看看 Dagster 和 Prefect
Dagster 是一个相对年轻的项目，由 Nick Schrock 于 2018 年 4 月开始，他之前是 Facebook GraphQL 的联合创始人。同样，Prefect 由 Jeremiah Lowin 于 2018 年创立，他在设计 Prefect 时作为 Apache Airflow 的 PMC 成员学习。
这两个项目都在解决一个共同的问题，但具有不同的驱动理念。Dagster 采用第一原则的方法进行数据工程。它在构建时考虑了整个开发生命周期，从开发到部署，再到监控和可观察性。另一方面，Prefect 坚持负向工程的哲学，建立在假设用户知道如何编码并尽可能简单地获取该代码并将其构建到分布式管道中，并得到其调度和支持的分布式管道中。编排引擎。
这两个项目都获得了很大的吸引力并迅速改善。让我们看看这两个项目如何处理 Airflow 所面临的一些挑战。
本地开发和测试
使用 Airflow，本地开发和测试可能是一场噩梦。如果您的生产 Airflow 实例使用 Kubernetes 作为执行引擎，那么您的本地开发也将需要本地 Kubernetes，因为使用 S3Operator 编写的任务需要连接到 AWS S3 才能运行：不适合本地开发。
使用 Dagster，计算和存储是两个不同的关注点，可以抽象出来。您的函数不是向您的 DAG 显式提供特定的 Kubernetes 实例，而是接受输入和输出及其在运行时配置的资源以持久保存数据，无论是用于开发的本地临时文件还是加密的对象存储在生产中的云中。
Prefect尽管通过 RunConfigs 还支持一定程度的存储抽象，然而，这并没有提供与 Dagster 相同的抽象级别，这会使本地开发更加棘手。对于 Prefect 来说，参数化是本地开发的重点。通过对流进行参数化，您可以为本地开发提供较小的数据集，为生产使用提供较大的数据集。
调度任务
在 Airflow 中，计划外的任务可能会导致很多意外问题，并且所有 DAG 都需要某种类型的计划，并且以相同的执行时间运行多个 DAG 是不可能的。
使用 Prefect，Flow 可以随时运行，因为工作流是独立的对象。虽然由于其调度程序的工作方式，我们经常等待 5-10 秒让 Airflow DAG 从预定时间运行，但 Prefect 允许利用 Dask 等工具对 DAG 和任务进行难以置信的快速调度。
同样，Dagster 为手动运行和计划的 DAG 提供了很大的灵活性。您甚至可以根据计划本身修改特定作业的行为，这非常强大。例如，如果您想在周末和工作日提供不同的运行时配置。
Airflow、Prefect 和 Dagster 中的数据流
Airflow 的最大痛点之一是相关任务之间的数据移动。传统上，每个任务都必须将数据存储在某个外部存储设备中，使用 XComs 传递有关其存储位置的信息（我们先不要谈论 XComs 之前的生活），并且以下任务必须解析该信息以检索数据并处理它。
在 Dagster 中，作业的输入和输出可以更加明确。
在 Prefect 中，输入和输出也清晰且易于连接在一起。
。。。。
动态工作流程
Airflow 相比Dagster 和 Prefect 中缺少的的另一个重要功能是创建动态工作流的简单界面。
在 Prefect 中，参数可以在 Cloud Interface 中指定或显式提供给 Flow runner。这使得扩展到大型复杂计算变得容易，同时允许在您处理管道时进行合理的初始开发。
在 Dagster 中，您可以定义一个图，然后对图进行参数化以允许动态配置，从而能够完全自定义资源、配置、挂钩和执行器。