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中引入的，还是实验性的

@转载原创文章 请标明出处