背压

Back Pressure是流处理系统中,非常经典常见的问题,它是让流系统能对压力变化能够呈现良好抗压性的关键所在
各个开源实时处理系统,在中后期,都开始有对背压机制有完善的考虑和设计,基本原理一致。实现方式各有千秋。
举例Spark Streaming

这句话怎么理解???
首先,服务中心的服务能力是有限的,要处理的事件时多时少,资源浪费?资源不够?
在系统架构设计中,要思考2个问题:
1、服务中心要抗住峰值事件(max问题)
2、这些事件如何有效被服务中心分配消费(match问题)

常用经典的排队理论,可以解决max问题,服务中心不会被压垮,
为了服务中心能正常服务,就需要多维护一个队列

  • 原来只维护一个东西,就是服务中心
  • 现在维护两东西,一个服务中心,一个队列

体现这种设计理念的经典设计模式之一(理论=> 模式),生产者-消费者模式

但match问题没解决,根本目的:
你事件多,我给资源多,处理能力够
你事件少,我给资源少,处理能力够
总结一句话就是 合适最重要

为了解决match问题,业界提出Reactive Stream的设计模式,生产者-消费者模式 + 迭代器
消费者告诉生产者消费数量,服务中心每个机器能吃多少饭,都是已知的,如果量大,吃不下,Spark就会动态调节(动态Executor模型),但怎么个调法?这个时候背压的概念和设计就出来了

背压就是背能背的起压力,从input到output,上游总给下游可承受的量,难点就是上游要知道下游能背多少???

SparkStreaming

基于SparkCore提供micro-batch处理的实时流式处理框架,就是批处理的批是很小的一批,
这个小批叫DStream(数据流 -> 转成DStream -> RDD机制处理)

SparkCore = Driver + Executor

image.png

上图是SparkStreaming的系统核心模块,和背压特性相关的,主要是模块3:数据的产生和导入。

image.png

基于前面的排队理论,Spark Streaming每一批次的处理时长(batch_process_time)需要小于批次间隔batch_interval,否则batch_process_time > batch_interval,程序的处理能力不足,积累的数据越来越多,最终会造成Executor的OOM。

Spark Steaming从1.5版本开始,开始引入背压机制,第一个相关问题是经典的SPARK-7398。其大体的思路是:

通过在Driver端进行速率估算,并将速率更新到Executor端的各个Receiver,从而实现背压
1、速率控制
2、速率估算
3、速率更新

  • 速率控制

整个背压机制的核心,就是Drvier端的RateContoller,它作为控制核心,继承自StreamingListener,监听Batch的完成情况,记录下它们的关键延迟,然后传递给computeAndPublish方法,遍历Executor并进行估算和更新

  • 速率估算

PIDRateEstimator是目前RateEstimator的唯一官方实现,基本上也没谁去重新实现一个,因为确实好用。PID(Proportional Integral Derivative,比例积分差分控制算法)是工控领域中,经过多次的验证是一种非常有效的工业控制器算法。Spark Streaming将它引入,作为根据最新的Rate,以及比例(Proportional) 积分(Integral)微分(Derivative)这3个变量,来确定最新的Rate,实现简洁明了,也非常好理解。

  • 速率更新

计算完新Rate,就该把它发布出去了。RateController通过ReceiverTracker,利用RPC消息,发布Rate到Receiver所在的节点上,该节点上的ReceiverSupervisorImpl会接收消息,并把速率更新到BlockGenerator上,从而以控制每个批次的数据生成。

仔细阅读这两个类的代码,可以发现它们充分利用了Scala的特性和高性能网络通信库,非常的简洁,一点都不拖泥带水。无论是发送端的UpdateRateLimit的case class消息类构建,还是接收端的receive的偏函数特性,都充分的体现了Scala的代码之美。

参考资料
xxx