我已经开始探索Spark Structured Streaming来编写一些在此之前使用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选项卡，用于指标和查看应用程序的吞吐量。在结构化流中，此功能不再可用。
这是为什么？是否打算以编程方式获取所有指标并推送到单独的监控服务？
答案 0 :(得分：4)
对于结构化流媒体应用中的每个接收器，它将独立 从来源（例如Kafka）读取。这意味着如果你从一个主题A中读到， 写入3个地方（例如ES，Kafka，S3）它实际上会设置3个 源连接彼此独立。
开箱即用，是的。每个Sink描述不同的执行流程。但是，您可以通过不使用内置接收器并创建自己的自定义接收器来解决这个问题，它可以控制您执行写操作的方式。
这会导致性能下降吗？因为它需要3 托管的独立连接而不是一个（DStream方法）
可能。您通常不希望一遍又一遍地阅读和处理相同的事情，因为您有相同来源的多个接收器。同样，您可以通过构建自己的接收器来实现这一点（这不应该是太多的工作）
Q2。我知道加入2个流数据集是不受支持的。怎么能 我对2个流进行计算？
As of Spark 2.3, this is supported OOTB.
你是对的。您在结构化流中拥有的花哨UI在Spark中尚不存在。我问Michael Armburst这个问题并且他的回答是“优先级”，他们根本没有时间投入工作来创建像Spark Streaming那样花哨的东西，因为他们想要挤出更多的功能。如果您需要，OSS可以随时自行提供缺失的部分。Q3。在Spark Streaming UI中，有一个Streaming选项卡，用于指标和 查看应用程序的吞吐量。在Structured Streaming中 目前不再可用。为什么是这样？是否打算以编程方式获取所有指标并推送到单独的监控服务？
总而言之，结构化流媒体是Spark的未来。没有更多的工作投入DStreams。对于高吞吐量系统，我可以说加入结构化流媒体的潮流有很大的好处。我已经在2.1发布后切换，这绝对是一个性能提升，特别是在有状态流管道领域。
答案 1 :(得分：1)
TL; DR; 结构化流媒体的设计考虑了不同的目标，虽然我们倾向于调用%d＆＃34; legacy＆＃34;但是没有插件替换。比较它们有点毫无意义，因为随着它们的发展，它们与原始Spark模型的差异越来越大。
DStream可以用来实现很多结构化流媒体功能（只需检查Apache Beam），但这远非琐碎。
同时，差异重申我们从RDD vs. DataFrame讨论中得到的知识 - 您会以通用性和自由为代价获得高度表达，优化和简洁的API（并非每个问题都可以在SQL中构建 - 就像API一样）。
此外，它仍然相当新，主要是实验性的，因此某些功能可能无法实现尚未。
这会导致性能下降吗？因为它需要3个独立的连接而不是一个（DStream方法）
在正常情况下，它会提高性能，并排除基于传统接收器的来源，与Kafka DStreams没有区别。
我知道加入2个流数据集是不受支持的
支持的流连接有很多种。请参阅Support matrix for joins in streaming queries。
n结构化流式传输不再可用。
Spark UI通过UI提供大量数据。通过Monitoring Structured Streaming Applications Using Web UI