Spark 结构化流 - 限制？ （来源性能、不受支持的操作、Spark UI）
Spark Structured Streaming - Limitations? (Source Performance, Unsupported Operations, Spark UI)
我已经开始探索 Spark Structured Streaming 来编写一些在此之前一直在使用 DStreams 的应用程序。
我正在尝试了解结构化流式传输的局限性，因为我已经开始使用它，但想知道它的缺点。
Q1。对于结构化流应用程序中的每个接收器，它将独立地从源（例如 Kafka）读取。这意味着如果你从一个主题 A 读取，并写入 3 个地方（例如 ES、Kafka、S3），它实际上会设置 。
这会导致性能下降吗？因为它将需要管理 3 个独立连接而不是一个（DStream 方法）
Q2。我知道加入2个流数据集是unsupported。如何对 2 个流执行计算？
如果我有主题 A 的数据和主题 B 的其他数据，是否可以以某种方式对这两个数据进行计算？
Q3。在 Spark Streaming UI 中，有一个 Streaming 选项卡用于度量和查看应用程序的吞吐量。在结构化流中，这不再可用。
这是为什么？是否打算以编程方式获取所有指标并推送到单独的监控服务？
TL;DR; Structured streaming 的设计考虑了不同的目标，虽然我们倾向于调用 DStream "legacy"，但并没有 drop - 更换。比较它们有些意义不大，因为随着它们的演进，它们与最初的 Spark 模型的差异越来越大。
DStreams 可用于实现许多结构化流功能（只需检查 Apache Beam），但它远非微不足道。
与此同时，差异重申了我们从 讨论中了解到的内容 - 您可以获得高度表达、优化和简洁 API，但要以通用性和自由度为代价（并非每个问题都可以装裱在 SQL - 就像 API).
此外，它还很新，主要是实验性的，因此某些功能可能尚未实现 。
Will this be a performance degradation? As it will require 3 independent connections managed instead of one (DStream approach)
在正常情况下它会提高性能，并且排除基于遗留接收器的源，它与 Kafka 没有区别DStreams。
I know that joining 2 streaming data sets is unsupported
支持的流连接范围很广。见 Support matrix for joins in streaming queries.
n Structured Streaming this is not available anymore.
Spark UI 通过 UI 提供了广泛的数据集。只检查 Monitoring Structured Streaming Applications Using Web UI by Jacek Laskowski
For each sink in the structured streaming app, it will independently
read from a source (eg. Kafka). Meaning if you read from one topic A,
and write to 3 places (e.g. ES, Kafka, S3) it will actually set up 3
source connections independent of each other.
开箱即用，是的。每个 Sink 描述了不同的执行流程。但是，您可以通过不使用内置接收器并创建您自己的自定义接收器来解决此问题，该接收器控制您进行写入的方式。
Will this be a performance degradation? As it will require 3
independent connections managed instead of one (DStream approach)
可能吧。您通常不想一遍又一遍地读取和处理相同的内容，只是因为您对同一源有多个 Sink。同样，您可以通过构建自己的 Sink 来适应这一点（这应该不会太多工作）
Q2. I know that joining 2 streaming data sets is unsupported. How can
I perform calculations on 2 streams?
As of Spark 2.3, this is supported OOTB.
Q3. In Spark Streaming UI, there is a Streaming tab for metrics and to
view the throughput of the application. In Structured Streaming this
is not available anymore. Why is this? Is the intention to obtain all metrics programmatically and push to a separate monitoring service?
你是对的。您在结构化流中拥有的奇特 UI 在 Spark 中不存在（目前）。我已经问过 Michael Armburst 这个问题，他的回答是 "priorities"，他们只是没有时间投入工作来创建像 Spark Streaming 那样花哨的东西，因为他们想挤进更多的功能。好的关于 OSS 的事情是，如果你需要，你可以随时自己贡献缺失的部分。
总而言之，Structured Streaming 是 Spark 的未来。没有更多的工作被投入到 DStreams 中。对于高吞吐量系统，我可以说加入结构化流的潮流有很大的好处。我已经在 2.1 发布后进行了切换，这绝对是性能提升，尤其是在有状态流媒体管道领域。
我已经开始探索 Spark Structured Streaming 来编写一些在此之前一直在使用 DStreams 的应用程序。
我正在尝试了解结构化流式传输的局限性，因为我已经开始使用它，但想知道它的缺点。
Q1。对于结构化流应用程序中的每个接收器，它将独立地从源（例如 Kafka）读取。这意味着如果你从一个主题 A 读取，并写入 3 个地方（例如 ES、Kafka、S3），它实际上会设置
这会导致性能下降吗？因为它将需要管理 3 个独立连接而不是一个（DStream 方法）
Q2。我知道加入2个流数据集是unsupported。如何对 2 个流执行计算？
如果我有主题 A 的数据和主题 B 的其他数据，是否可以以某种方式对这两个数据进行计算？
Q3。在 Spark Streaming UI 中，有一个 Streaming 选项卡用于度量和查看应用程序的吞吐量。在结构化流中，这不再可用。
这是为什么？是否打算以编程方式获取所有指标并推送到单独的监控服务？
TL;DR; Structured streaming 的设计考虑了不同的目标，虽然我们倾向于调用 DStream "legacy"，但并没有 drop - 更换。比较它们有些意义不大，因为随着它们的演进，它们与最初的 Spark 模型的差异越来越大。
DStreams 可用于实现许多结构化流功能（只需检查 Apache Beam），但它远非微不足道。
与此同时，差异重申了我们从
此外，它还很新，主要是实验性的，因此某些功能可能尚未实现 。
Will this be a performance degradation? As it will require 3 independent connections managed instead of one (DStream approach)
在正常情况下它会提高性能，并且排除基于遗留接收器的源，它与 Kafka 没有区别
DStreams。I know that joining 2 streaming data sets is unsupported
支持的流连接范围很广。见 Support matrix for joins in streaming queries.
n Structured Streaming this is not available anymore.
Spark UI 通过 UI 提供了广泛的数据集。只检查 Monitoring Structured Streaming Applications Using Web UI by Jacek Laskowski
For each sink in the structured streaming app, it will independently read from a source (eg. Kafka). Meaning if you read from one topic A, and write to 3 places (e.g. ES, Kafka, S3) it will actually set up 3 source connections independent of each other.
开箱即用，是的。每个 Sink 描述了不同的执行流程。但是，您可以通过不使用内置接收器并创建您自己的自定义接收器来解决此问题，该接收器控制您进行写入的方式。
Will this be a performance degradation? As it will require 3 independent connections managed instead of one (DStream approach)
可能吧。您通常不想一遍又一遍地读取和处理相同的内容，只是因为您对同一源有多个 Sink。同样，您可以通过构建自己的 Sink 来适应这一点（这应该不会太多工作）
Q2. I know that joining 2 streaming data sets is unsupported. How can I perform calculations on 2 streams?
As of Spark 2.3, this is supported OOTB.
Q3. In Spark Streaming UI, there is a Streaming tab for metrics and to view the throughput of the application. In Structured Streaming this is not available anymore. Why is this? Is the intention to obtain all metrics programmatically and push to a separate monitoring service?
你是对的。您在结构化流中拥有的奇特 UI 在 Spark 中不存在（目前）。我已经问过 Michael Armburst 这个问题，他的回答是 "priorities"，他们只是没有时间投入工作来创建像 Spark Streaming 那样花哨的东西，因为他们想挤进更多的功能。好的关于 OSS 的事情是，如果你需要，你可以随时自己贡献缺失的部分。
总而言之，Structured Streaming 是 Spark 的未来。没有更多的工作被投入到 DStreams 中。对于高吞吐量系统，我可以说加入结构化流的潮流有很大的好处。我已经在 2.1 发布后进行了切换，这绝对是性能提升，尤其是在有状态流媒体管道领域。