apache-spark - Spark 结构化流 - 限制？（源性能、不支持的操作、Spark UI）

Question

我已经开始探索 Spark Structured Streaming 来编写一些在此之前一直使用DStreams的应用程序。

我正在尝试了解结构化流式传输的局限性，因为我已经开始使用它，但如果有的话，我想知道它的缺点。

Q1。对于结构化流应用程序中的每个接收器，它将独立地从源（例如 Kafka）读取。这意味着如果你从一个主题 A 中读取，并写入 3 个位置（例如 ES、Kafka、S3），它实际上会建立3 个彼此独立的源连接。

这会导致性能下降吗？因为它将需要管理 3 个独立的连接而不是一个（DStream 方法）

Q2。我知道不支持加入 2 个流数据集。如何对 2 个流执行计算？

如果我有来自主题 A 的数据和来自主题 B 的其他数据，是否可以以某种方式对这两者进行计算？

Q3。在 Spark Streaming UI 中，有一个 Streaming 选项卡用于度量和查看应用程序的吞吐量。在结构化流中，这不再可用。

为什么是这样？是否打算以编程方式获取所有指标并推送到单独的监控服务？

标签： apache-sparkapache-kafkaspark-structured-streaming

Answer 1

对于结构化流应用程序中的每个接收器，它将独立地从源（例如 Kafka）读取。这意味着如果你从一个主题 A 中读取，并写入 3 个位置（例如 ES、Kafka、S3），它实际上会建立 3 个彼此独立的源连接。

开箱即用，是的。每个 Sink 描述不同的执行流程。但是，您可以通过不使用内置接收器并创建自己的自定义接收器来解决此问题，该接收器控制您执行写入的方式。

这会导致性能下降吗？因为它将需要管理 3 个独立的连接而不是一个（DStream 方法）

大概。您通常不想一遍又一遍地阅读和处理相同的内容，因为您有多个 Sink 用于相同的源。同样，您可以通过构建自己的 Sink 来适应这一点（这不应该是太多的工作）

Q2。我知道不支持加入 2 个流数据集。如何对 2 个流执行计算？

从 Spark 2.3 开始，OOTB 受支持。

Q3。在 Spark Streaming UI 中，有一个 Streaming 选项卡用于度量和查看应用程序的吞吐量。在结构化流中，这不再可用。为什么是这样？是否打算以编程方式获取所有指标并推送到单独的监控服务？

你是对的。Spark 中（还）不存在结构化流式处理中的精美 UI。我问过 Michael Armburst 这个问题，他的回答是“优先级”，他们根本没有时间投入工作来创建像 Spark Streaming 那样花哨的东西，因为他们想挤进更多的功能。 OSS 是如果您需要，您可以随时自己贡献缺失的部分。

总而言之，结构化流是 Spark 的未来。没有更多的工作投入到 DStreams 上。对于高吞吐量系统，我可以说加入结构化流的潮流有一个显着的好处。一旦 2.1 发布，我就切换了，这绝对是性能的提升，尤其是在有状态的流管道领域。