当Spark结构化流中的查询执行没有关于触发器的设置时，
import org.apache.spark.sql.streaming.Trigger
// Default trigger (runs micro-batch as soon as it can)
df.writeStream
.format("console")
//.trigger(???) // <--- Trigger intentionally omitted ----
.start()
自Spark 2.4.3起（2019年8月）。 Structured Streaming Programming Guide - Triggers说
如果未明确指定触发器设置，则默认情况下，查询将以微批量模式执行，在该模式下，上一个微批量处理完成后，将立即生成微批量。
问题：：默认触发器在哪个基础上确定微批次的大小？
说。输入源是Kafka。由于中断，工作中断了一天。然后，重新启动相同的Spark作业。然后它将在中断的地方使用消息。这是否意味着第一个微批处理将是一个巨大的批处理，其中有1天的msg，在工作停止时会累积在Kafka主题中？假设该工作需要10个小时来处理该大批处理，那么下一个微批处理具有10h的消息价值？并逐步进行，直到进行X次迭代以赶上积压的订单，然后到达较小的微型批次。
答案 0 :(得分：1)
默认触发条件是在哪个基础上确定微批次的大小？
不是。每个触发器（无论多长时间）仅请求输入数据集的所有源，并且它们提供的任何内容都由运算符在下游进行处理。消息来源知道要提供什么，因为他们知道到目前为止已经消耗（处理）了什么。
就好像您在询问批处理结构化查询以及此单个“触发器”请求处理的数据大小（顺便说一句，有ProcessingTime.Once触发器）。
这是否意味着第一个微批处理将是一个巨大的批处理，其中有1天的味精在停止工作时会累积在Kafka主题中？
几乎（实际上与Spark结构化流无关）。
底层的Kafka使用者要处理的记录数由max.poll.records以及其他一些配置属性（请参见Increase the number of messages read by a Kafka consumer in a single poll）配置。
由于Spark结构化流使用的Kafka数据源只是Kafka Consumer API的包装，因此单个微批处理中发生的任何事情都等同于此Consumer.poll调用。
您可以使用带有kafka.前缀（例如kafka.bootstrap.servers）的选项来配置基础的Kafka使用者，这些选项在驱动程序和执行程序上被Kafka使用者考虑。