kafka 的structured stream 总结

比较重要的几个概念：
1.trigger触发时间，这个触发时间是指每次触发从kafka读取数据的时间间隔，如果不设置，就是尽可能快的意思，上一批处理完马上下一批，如果偶尔停机，而kafka中积累了大量的offset待消费，为了使得比如重启或者修复故障后重新消费kafka消息时单批次的消息不至于把spark内存弄挂掉，可以设置maxOffsetPerTrigger操作，这样可以控制单trigger处理的消息量
2.checkpoint点的含义：checkpoint点是保存kafka消费偏移量，spark的stream id（目的是跨重启后依然认为是同一个流）-- query.id() # get the unique identifier of the running query that persists across restarts from checkpoint data，所以不同的流操作需要设置不同的checkout目录，如果新建了一个spark集群，想要把流程序迁移到新集群去继续之前旧stream的消费，只需要写新的stream程序时服用旧stream的checkpoint目录即可,此外checkpoint点还保持这State表也就是Result Table表的信息，为跨批次状态操作提供之前的state信息.
3.watermark水印的含义：
a.Append模式下，为了维持该模式的语义，每个窗口操作的信息需要等到wartermark到达时才会输出到kafka sink中，题外话，spark的Append模式下最后几条消息有可能会一直在等待watermark的到达而一直不会输出，暂未知原因
b.Update模式下，每次trigger中有变的窗口信息都会输出到kafka sink中，这可能会造成输出的key重复，但是所有输出的消息在trigger之后肯定会输出，不会类似Append那样最后的几条消息会在一直等待wartermark到达

4.无论是Append还是update模式，对于迟到的超过了wartermark的消息都是直接进行丢弃处理（这里也没有记录日志，完全不知道有消息丢失）这种处理方式过于草率，相比来说flink的流处理可以有处理延迟消息的机制.

参考文章:
https://blog.csdn.net/asd136912/article/details/82913264?spm=1001.2101.3001.6650.3&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-3.pc_relevant_antiscanv2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-3.pc_relevant_antiscanv2&utm_relevant_index=6

https://blog.csdn.net/asd136912/article/details/82147657

https://blog.csdn.net/lovechendongxing/article/details/81748237

https://blog.csdn.net/lovechendongxing/article/details/81748553