我在笔记本电脑上进行了以下测试：
我用一个1000条消息创建了一个Kafka主题，其中每条消息包含几行，每行约100列。
在List [Column]中创建300个非常复杂的Spark列。没有聚合。
在设置来自Kafka的流时，我设置了.option（“ maxOffsetsPerTrigger”，1），因此每个迷你批处理中仅处理一条消息。
然后我将这些列应用于仅包含一条消息的迷你批处理。
val testStream = myStream
.select(manyTestCols :_*)
.writeStream
.format("console")
.outputMode("append")
.start()
.awaitTermination()
火花大约需要10秒钟来处理每条消息。
然后我将maxOffsetsPerTrigger更改为.option（“ maxOffsetsPerTrigger”，1000），以便在每个迷你批处理中处理1000条消息。
火花需要大约11秒的时间来处理每个微型批处理中的所有1000条消息。
因此，似乎Spark会执行某种“设置工作”，然后一旦开始处理每个小批处理就相当快。
此“设置工作”是否是针对每个微型批处理从查询计划一直到物理计划？
如果是这样，Spark在每个微型批处理中都这样做是否有意义？
还是其他事情正在完全发生？我正在查看Spark源代码，但希望获得已经通过本练习的人的反馈。
Tx以获取任何见解。
答案 0 :(得分：1)
此“设置工作”是否是针对每个微型批处理从查询计划一直到物理计划？
对于在运行时按如下方式填写的流查询的查询计划的执行特定部分，部分为是（带有指向相应代码部分的链接）：
如果是这样，Spark在每个微型批处理中都这样做是否有意义？
绝对。结构化流中没有其他方法可以短路无数据源，跟踪当前时间和水印。
这也是extra no-data micro-batch for stateful operators（例如，水印更改）的原因。
我正在查看Spark源代码，但希望已经通过此练习的人提供反馈。