Spring Cloud Dataflow 与 Apache Beam/GCP 数据流说明

Posted 2023-02-26

【中文标题】Spring Cloud Dataflow 与 Apache Beam/GCP 数据流说明

【英文标题】：Spring Cloud Dataflow vs Apache Beam/GCP Dataflow Clarification

【发布时间】：2020-03-22 03:15:43

【问题描述】：

我很难理解 GCP Dataflow/Apache Beam 和 Spring Cloud Dataflow 之间的区别。我想做的是转向更云原生的流数据处理解决方案，这样我们的开发人员就可以更多地专注于开发核心逻辑，而不是管理基础设施。

我们有一个现有的流解决方案，其中包含我们可以迭代和独立部署的 spring 云数据流“模块”，就像微服务一样，效果很好，但我们希望迁移到 GCP 中由我们提供的现有平台需要我们使用 GCP Dataflow 的业务。概括地说，解决方案很简单：

流 1：

Kafka Source (S0) -> Module A1 (Ingest) -> Module B1 (Map) -> Module C1 (Enrich) -> Module D1 (Split) -> Module E1 (Send output to Sink S1)

流 2：

Kafka Source (S1) -> Module A2 (Ingest) -> Module B2 (Persist to DB) -> Module B3 (Send Notifications through various channels)

据我了解，我们想要迁移到的解决方案应该是相同的，但是模块将成为 GCP Dataflow 模块，源/接收器将成为 GCP Pub/Sub 而不是 kafka。

我遇到的大多数文档都没有将 SCDF 和 Apache Beam（GCP 数据流模块）作为类似的解决方案进行比较，所以我想知道如何/是否可以将我们现有的逻辑移植到这样的架构中。

任何澄清将不胜感激。提前致谢。

【参考方案1】：

我想在@guillaume-blaquiere 的回复中添加 +1：“重写代码”。让我也为这个主题添加更多颜色。

SCDF 概述：

Spring Cloud Data Flow (SCDF) 的核心只是一个 RESTful 服务，甚至是一个轻量级的 Spring Boot 应用程序。就这样。它不需要运行时即可运行； Boot App 可以在任何有 Java 的地方运行，包括在您的笔记本电脑或任何容器平台（k8s、cf、nomad 等）、任何云（aws、gcp、azure 等）上。

SCDF（引导应用程序/Über-jar）附带仪表板、Shell/CLI 和 API，因此开发人员和操作员可以使用它们来设计和部署流式传输或批处理数据管道。

SCDF 中的数据管道由Spring Cloud Stream 或Spring Cloud Task 应用程序组成。因为这些是独立和自治的微服务应用程序，用户可以单独修补或滚动升级单个应用程序，而不会影响数据管道中的上游或下游应用程序——有关架构的更多详细信息here。

SCDF 与 GCDF：

Spring Cloud Stream 和 Spring Cloud Task 与 Apache Beam 大致相当。这些是 SDK/库。

另一方面，SCDF 与 Google Cloud Dataflow (GCDF) 中的数据管道有一些相似之处，但 GCDF 中的模块预计将使用 Apache Beam 构建。换句话说，您不能将在 SCDF 中运行的 Spring Boot 流式/批处理微服务作为模块运行到 GCDF - 您必须使用 Apache Beam API 重写它们。 SCDF 和 GCDF 基金会都直接依赖于上述各自的框架及其功能。

另一个需要强调的重要区别是运行 Apache Beam 模块所需的运行时组件。在 GCDF 中，所有的运行时/运行器期望对用户都是隐藏的，因为它是由 GCP 管理的。而在 SCDF 中，要以高度可扩展的方式运行它，您需要选择您选择的平台。 SCDF 作为平台上的原生容器应用程序运行。

GKE/GCP 上的 SCDF：

您可以在 GCP 上配置 GKE 集群，并使用 SCDF 的 Helm Chart 在 Kubernetes 中作为 GCP 上的托管服务在本地运行 SCDF 和您当前的流式处理/批处理 (Spring Boot) 应用程序。

【讨论】：

对 SCDF 的高精度也 +1！

感谢您的回答！我现在了解这些差异。不幸的是，看起来我需要在 apache Beam 中重写我们现有的流，而且看起来已经是一个很大的转变。简单地从光束管道中的文本文件解析 JSON 需要一些时间来理解，并且对于这样一个微小的任务最终变得非常冗长。希望随着时间的推移，事情会变得更容易、更清晰！

【参考方案2】：

首先澄清：Spring Cloud Data Flow 与 GCP 数据流完全不同。

Spring Cloud Data Flow 可与 Apache Beam 相媲美。两者都有描述数据转换的框架，例如 ETL。

GCP Dataflow 是托管在 GCP 上的可自动扩展的托管平台。它接受使用 Apache Beam 框架描述的处理流程。 GCP Dataflow 负责运行流水线，根据流水线要求生成 VM 数量，将流分派给这些 VM，...

Apache Beam 是一个具有许多连接器的开源项目。很多关于 GCP（因为它最初是一个开源的谷歌产品），还有其他连接器，比如 kafka io connector。

Beam 还集成了不同的运行器：DirectRunner 用于在您当前的机器上启动管道，DataflowRunner 用于在 GCP Dataflow 上运行它，SparkRunner 用于在 Hadoop Spark 集群上运行它，...

这是一个很好的解决方案，但与 Spring Cloud Data Flow 没有任何直接关系、合规性和可移植性。您必须重写代码才能从一个传递到另一个。

希望这有助于您的理解

【讨论】：

感谢您的解释！这对我来说很清楚。