我已经开始探索Spark结构化流，以在此之前编写一些使用DStreams的应用程序。
当我开始使用结构化流时，我试图理解结构化流的局限性，但是我想知道有什么缺点。
Q1。对于结构化流应用程序中的每个接收器，它将独立地从源(例如Kafka)读取。这意味着如果您从一个主题A中读取并写入3个地方(例如ES，Kafka，S3)，则实际上将设置3 source connections independent of each other。
这会降低性能吗？因为它将需要管理3个独立的连接，而不是一个(DStream方法)
Q2。我知道加入2个流数据集是unsupported。如何对2个流进行计算？
如果我有主题A的数据和主题B的其他数据，是否可以通过某种方式对这两者进行计算？
Q3。在Spark Streaming UI中，有一个Streaming选项卡，用于度量标准并查看应用程序的吞吐量。在结构化流中，此功能不再可用。
为什么是这样？是否打算以编程方式获取所有指标并推送到单独的监视服务？
最佳答案
对于结构化流应用程序中的每个接收器，它将独立
从来源(例如Kafka)读取。意思是，如果您从一个主题A阅读，
并写入3个地方(例如ES，Kafka，S3)，它将实际设置3
源连接彼此独立。
开箱即用，是的。每个接收器描述一个不同的执行流程。但是，您可以通过不使用内置接收器并创建自己的自定义接收器来解决此问题，该自定义接收器控制如何进行写入。
这会降低性能吗？因为这需要3
管理独立连接而不是一个(DStream方法)
大概。通常，您不希望一遍又一遍地读取和处理相同的内容，仅是因为您对于同一个来源有多个接收器。再次，您可以通过构建自己的接收器来解决此问题(这不应做太多工作)
Q2。我知道不支持加入2个流数据集。怎么能
我对2个流执行计算？
As of Spark 2.3, this is supported OOTB.
Q3。在Spark Streaming UI中，有一个Streaming标签用于指标和
查看应用程序的吞吐量。在结构化流中
不再可用。为什么是这样？是否打算以编程方式获取所有指标并推送到单独的监视服务？
你是对的。您在结构化流中拥有的精美UI在Spark中尚不存在。我曾问过迈克尔·阿姆伯斯特(Michael Armburst)这个问题，他的回答是“优先”，他们根本没有时间投入工作来创建像Spark Streaming一样花哨的东西，因为他们想在其中添加更多功能。 OSS是您随时可以根据需要自己贡献缺失的部分。
总而言之，结构化流媒体是Spark的 future 。 DStreams不再投入任何工作。对于高吞吐量的系统，我可以说加入结构化流媒体潮流有很大的好处。 2.1版发布后，我已经切换了，这绝对是性能的提升，尤其是在有状态流管道领域。