对于结构化流应用程序中的每个接收器，它将独立地从一个源读取数据（如kafka）。也就是说，如果你从一个主题a开始读，然后写到3个地方（例如es、kafka、s3），它实际上会建立3个相互独立的源连接。
是的，开箱即用。每个接收器描述不同的执行流。但是，您可以通过不使用内置接收器和创建自己的自定义接收器来解决这个问题，自定义接收器控制您如何进行写入。
这会导致性能下降吗？因为它需要管理3个独立的连接，而不是一个（数据流方法）
可能。您通常不想一遍又一遍地读取和处理同一件事情，因为同一个源有多个接收器。同样，你可以通过建造你自己的Flume来适应这一点（这不应该是太多的工作）
问题2。我知道加入2个流数据集是不受支持的。如何对两个流执行计算？
从spark 2.3开始，ootb就支持这一点。
问题3。在spark流式处理ui中，有一个用于度量和查看应用程序吞吐量的流式处理选项卡。在结构化流媒体中，这不再可用。为什么会这样？是否打算以编程方式获取所有度量并推送到一个单独的监视服务？
你说得对。你在结构化流媒体中拥有的奇特ui在spark中还不存在。我问过michaelarmburst这个问题，他的回答是“优先权”，他们根本没有时间去创造像spark streaming那样的东西，因为他们想挤出更多的功能。oss的好处是，如果你需要的话，你可以自己贡献缺失的部分。
总之，结构化流媒体是spark的未来。没有更多的工作投入到数据流中。对于高吞吐量系统，我可以说加入结构化流媒体潮流有很大的好处。我在2.1发布后就切换了，这无疑是一个性能提升，特别是在有状态流媒体管道领域。

热释光；博士；结构化流媒体的设计有不同的目标，尽管我们倾向于 DStream “遗风”，没有落井下石的替代品。比较它们有些毫无意义，因为随着它们的发展，它们与最初的spark模型的差异越来越大。 DStreams 可以用来实现许多结构化流特性（只需检查apachebeam），但它远不是微不足道的。
同时，差异重申了我们从rdd和dataframe讨论中所知道的——您得到了高度表达、优化和简洁的api，而代价是通用性和自由性（不是每个问题都可以用类似sql的api来构建）。
而且，它仍然是相当新的，而且大部分是实验性的，所以一些特性可能还没有实现。
这会导致性能下降吗？因为它需要管理3个独立的连接，而不是一个（数据流方法）
在正常情况下，它将提高性能，并且排除传统的基于接收器的源，它与kafka没有区别 DStreams .
我知道加入2个流数据集是不受支持的
有多种支持的流连接。有关流查询中的联接，请参见支持矩阵。
n结构化流媒体不再提供。
spark ui通过ui提供了广泛的数据集。请看jaceklaskowski使用webui监视结构化流媒体应用程序