micro-batches Processing & Continuous Processing
Structured Streaming 在Apache Spark 2.0引入，计算模式就是小批量计算，从高层次上看起来和小批量处理没有什么关系的，主要有两个原因。第一：开发者编程更简单，接口调用不需要关注小批量。第二：允许开发者可以把源源不断的数据流看做一张无界的表，在发起查询的时候就是静态的表了。
spark 2.3中引入一种能够达到毫秒级低延迟的计算模式：持续计算。
两种计算模式如下：默认（micro-batches）
图片.png
micro-batches Processing：
使用：
.filter("isPaymentFlagged(paymentId)")
.writeStream
{...}
.trigger(processingTime = "0 seconds")
.start()
延迟性：
最低100 ms
图片.png
原理：
在小批量处理模式下，spark streaming 计算引擎阶段性地检查数据流，然后批量处理数据，high-level 上的流程图
图片.png
在处理一批数据之前，先把这一批数据记录的偏移量写到whl日志中（write head log）（用于下一批数据查询）, 等到把偏移量保存完成后开始计算，这样就产生了延迟，从数据记录的level上流程图如下：
图片.png
Continuous Processing：
使用：
.filter("isPaymentFlagged(paymentId)")
.writeStream \
{...}
.trigger(continuous = "5 seconds")
.start
延迟分析：
最低1 ms以下
图片.png
原理：
在持续计算模式下：不是阶段性的发起task，而是spark发起一个长期运行的long-running task，持续地读、计算、写。high-level流程图如下：而对于保存数据记录的偏移量，则是相当于在数据流流入spark的时候上打标记，两个标记之间叫 epoch，跟阶段的意思差不多，task在遇到一个标记的时候会异步的保存这个偏移量，对于持续计算是没有影响的。
图片.png
图片.png
后记：
- 如果你对延迟性要求比较高的话可以用Continuous Processing 模式，而 micro-batches Processing 模式的吞吐量会更高。
- 持续计算在2.3中引入的，还是实验性的
@转载原创文章 请标明出处
