Spark结构化流-局限性？（源性能，不支持的操作，Spark UI）

我已经开始探索Spark结构化流，以在此之前编写一些使用DStream的应用程序。

当我开始使用结构化流时，我试图理解它的局限性，但是我想知道其缺点。

Q1。对于结构化流应用程序中的每个接收器，它将独立地从源（例如Kafka）读取。意思是，如果您从一个主题A阅读并写入3个地方（例如ES，Kafka，S3），则实际上将建立3个彼此独立的源连接。

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

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

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

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

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

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

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

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

大概。通常，您不希望一遍又一遍地读取和处理相同的内容，仅是因为您对于同一个来源有多个接收器。再次，您可以通过构建自己的接收器来解决这个问题（这应该不是很多工作）

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

从Spark 2.3开始，此功能受OOTB支持。

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

你是对的。您在结构化流中拥有的精美UI在Spark中尚不存在。我问过迈克尔·阿姆伯斯特（Michael Armburst）这个问题，他的回答是“优先”，他们根本没有时间投入工作来创建一些像Spark Streaming一样花哨的东西，因为他们想挤入更多功能。 OSS是您随时可以根据需要自己贡献缺失的部分。

总而言之，结构化流媒体是Spark的未来。DStreams不再投入任何工作。对于高吞吐量系统，我可以说加入“结构化流媒体”潮流有很大的好处。2.1版发布后，我已经进行了切换，这绝对是性能的提升，尤其是在有状态流管道领域。