micro-batches Processing & Continuous Processing
Structured Streaming 在Apache Spark 2.0引入,计算模式就是小批量计算,从高层次上看起来和小批量处理没有什么关系的,主要有两个原因。第一:开发者编程更简单,接口调用不需要关注小批量。第二:允许开发者可以把源源不断的数据流看做一张无界的表,在发起查询的时候就是静态的表了。
spark 2.3中引入一种能够达到毫秒级低延迟的计算模式:持续计算。
两种计算模式如下:默认(micro-batches)
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上流程图如下:
图片.pngContinuous 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中引入的,还是实验性的
@转载原创文章 请标明出处
网友评论