用于数据处理和作业调度的选择:Apache Airflow还是Apache Beam?

86

我试图提供有用的信息,但我离数据工程师还很远。

我目前正在使用Python库pandas对我的数据执行一系列长时间的转换,其中有许多输入(目前是CSV和Excel文件)。输出是几个Excel文件。我希望能够执行定期监控的批处理作业,并进行并行计算(我指的是不像我使用pandas那样顺序执行),每月一次。

我不太了解Beam或Airflow,我快速浏览了文档,似乎两者都可以实现这一点。我应该使用哪一个?

4个回答

148

其他答案比较技术化,难以理解。我曾经也处于你的位置,所以我会用简单易懂的话来解释。

Airflow 可以做任何事情。它有 BashOperatorPythonOperator,意味着它可以运行任何 bash 脚本或任何 Python 脚本。
它是一种组织(设置复杂数据管道 DAGs)、调度、监视、触发数据管道重新运行的方法,并在易于查看和使用的 UI 中提供这些功能。
此外,它易于设置,而且所有内容都在熟悉的 Python 代码中。
以有组织的方式进行管道操作(即使用 Airflow)意味着您不必浪费时间调试到处都是的数据处理 (cron) 脚本。
现在(大约从 2020 年开始),我们称它为一个 小提琴 工具。

Apache Beam 是许多数据处理框架(例如 Spark、Flink 等)的包装器。
其目的是让您只学习 Beam 并在多个后端(Beam runners)上运行。
如果您熟悉 Keras 和 TensorFlow/Theano/Torch,则 Keras 与其后端之间的关系类似于 Beam 与其数据处理后端之间的关系。

Google Cloud Platform 的 Cloud Dataflow 是运行 Beam 的一个后端。
他们将其称为 Dataflow runner

GCP的服务产品, Cloud Composer, 是一个托管的Airflow实现,作为一个服务运行在Google Kubernetes Engine (GKE)中的Kubernetes集群。

因此,您可以采用以下任一方式:

  • 手动Airflow实现,对于数据较小(或实例足够强大)的情况下,在运行Airflow的机器上处理数据。这就是为什么很多人会困惑Airflow是否可以处理数据的原因。
  • 手动Airflow实现调用Beam作业。
  • 使用Cloud Composer(托管的Airflow服务)调用Cloud Dataflow中的作业。
  • 在Composer的Kubernetes集群环境自身中运行数据处理容器,使用Airflow的KubernetesPodOperator (KPO)
  • 在Composer的Kubernetes集群环境中使用Airflow的KPO运行数据处理容器,但这次通过创建新节点池并指定KPO pod在新节点池中运行以更好地进行隔离

我的个人经验:
Airflow轻量化且易于学习(易于实现),在可能的情况下应该用它来建立数据流水线。
此外,由于许多公司正在寻找使用Airflow的经验,如果您想成为一名数据工程师,您应该学习它。

此外,使用托管的Airflow(我目前只使用过GCP的Composer),比自己运行Airflow并管理webserverscheduler进程更加方便。

2
关于第一个选项,Airflow会“调用”Beam,然后呢?管道实际上在哪里运行?我是否还需要设置Spark集群或类似的东西并将其连接到Airflow? - tomer.z
4
是的,它调用了Beam中的一个作业,您的Beam作业可以在Spark、Flink等中运行,或者使用Beam中的Dataflow runner在Cloud Dataflow中运行。管道是一个模糊的术语,我尽量避免使用它。调度发生在Airflow中,数据处理发生在一个单独的集群中。您可能需要一个Airflow任务来启动一个数据处理集群(Spark/Flink),一个Airflow任务来调用使用Beam编写的作业,然后再有另一个Airflow任务来关闭集群。是的,您需要将您的数据处理集群与Airflow连接起来。 - cryanbhu

80

在表面上,Apache Airflow和Apache Beam看起来非常相似。它们都允许你组织一组处理数据的步骤,并确保这些步骤按正确的顺序运行并满足其依赖项。两者都允许你在GUI中将这些步骤和依赖项可视化为有向无环图(DAG)。

但是当你深入挖掘时,它们在所做的事情和所支持的编程模型方面存在很大的差异。

Airflow是一个任务管理系统。DAG的节点是任务,Airflow确保按照正确的顺序运行它们,确保一个任务只在其依赖任务完成后才开始。依赖任务不同时运行,而是一个接着一个地运行。独立任务可以并发运行。

Beam是一个数据流引擎。DAG的节点形成一个(可能分支)的管道。DAG中的所有节点同时处于活动状态,它们将数据元素从一个节点传递到下一个节点,每个节点对其进行一些处理。

这两个工具有一些重叠的使用案例,但有很多只有其中一个工具能够很好地处理的任务。

Airflow 管理依赖于彼此的任务。虽然这种依赖关系可以包括一个任务向下一个任务传递数据,但并非必须如此。实际上 Airflow 不关心任务所做的事情,只需要启动它们并查看它们是否完成或失败。如果任务需要相互传递数据,您需要自己协调它,告诉每个任务在哪里读取和写入其数据,例如本地文件路径或某个 Web 服务。任务可以由 Python 代码组成,但也可以是任何外部程序或 Web 服务调用。

在 Beam 中,步骤定义与引擎紧密集成。您使用支持的编程语言定义步骤,并在 Beam 进程内运行它们。如果可能的话,在外部进程中处理计算会很困难,并且肯定不是 Beam 所设计使用的方式。您的步骤只需要担心它们正在执行的计算,而不用担心存储或传输数据。在不同步骤之间传输数据完全由框架处理。

在Airflow中,如果你的任务处理数据,则单个任务调用通常会对整个数据集执行一些转换。在Beam中,数据处理是核心接口的一部分,因此它不能真正做任何其他事情。 Beam步骤的调用通常处理单个或几个数据元素,而不是整个数据集。由于这一点,Beam还支持无界长数据集,这是Airflow本地无法处理的。
另一个区别是,Airflow本身是一个框架,但Beam实际上是一个抽象层。 Beam管道可以在Apache Spark、Apache Flink、Google Cloud Dataflow等上运行。所有这些都支持更多或少相似的编程模型。顺便说一下,Google也将Airflow云化为Google Cloud Compose服务。
*Apache Spark对Python的支持实际上是通过在子进程中运行完整的Python解释器来实现的,但这是在框架级别实现的。

1
只有在其依赖任务完成后才开始运行,因此它不适用于流式处理? - Kermit
5
@HashRocketSyntax 当然。在Airflow的编程模型中,流式处理甚至不太合理。引用Airflow文档首页的话:“Airflow 不是数据流解决方案。” https://airflow.apache.org/ - JanKanis
真正的区别是什么,看起来你提到的所有关于Airflow的特性在数据流模型中也可以实现。如果Beam不能做到这一点,那只是因为他们还没有实现这个功能。 - BAKE ZQ

22

Apache Airflow 不是一个数据处理引擎。

Airflow 是一个平台,可以通过编程方式创作、调度和监控工作流程。

Cloud Dataflow 是 Google Cloud 上的全托管服务,可用于数据处理。您可以编写 Dataflow 代码,然后使用 Airflow 进行 Dataflow 作业的调度和监控。Airflow 还允许您在作业失败时重试(重试次数可配置)。您还可以在 Airflow 中进行配置,以便在 Dataflow 管道失败时发送 Slack 或电子邮件警报。


0

我正在使用Airflow做和你一样的事情,而且效果非常好。但是我不太确定以下内容:Beam是面向机器学习的,而Airflow则可以用于任何你想要的东西。 最后,你可以使用Kubernetes + Airflow创建一个Hive。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接