flink和spark Streaming中的Back Pressure

Spark Streaming的back pressure

在讲flink的back pressure之前，我们先讲讲Spark Streaming的back pressure。Spark Streaming的back pressure出现的原因呢，我想大家应该都知道，是为了应对短期数据尖峰。Spark Streaming的back pressure是从spark 1.5以后引入的，在之前呢，只能通过限制最大消费速度（这个要人为压测预估），对于基于Receiver 形式，我们可以通过配置 spark.streaming.receiver.maxRate 参数来限制每个 receiver 每秒最大可以接收的记录的数据；对于 Direct Approach 的数据接收，我们可以通过配置 spark.streaming.kafka.maxRatePerPartition 参数来限制每次作业中每个 Kafka 分区最多读取的记录条数。

这种限速的弊端很明显，比如假如我们后端处理能力超过了这个最大的限制，会导致资源浪费。需要对每个spark Streaming任务进行压测预估。成本比较高。由此，从1.5开始引入了back pressure，这种机制呢实际上是基于自动控制理论的pid这个概念。我们就简单讲一下其中思路：为了实现自动调节数据的传输速率，在原有的架构上新增了一个名为 RateController 的组件，这个组件继承自 StreamingListener，其监听所有作业的 onBatchCompleted 事件，并且基于 processingDelay 、schedulingDelay 、当前 Batch 处理的记录条数以及处理完成事件来估算出一个速率；这个速率主要用于更新流每秒能够处理的最大记录的条数。这样就可以实现处理能力好的话就会有一个较大的最大值，处理能力下降了就会生成一个较小的最大值。来保证Spark Streaming流畅运行。

pid速率计算源码

配置Spark Streaming的back pressure

spark.streaming.backpressure.pid.derived：对错误趋势的响应权重。 这可能会引起 batch size 的波动，可以帮助快速增加/减少容量。默认值为0，只能设置成非负值。weight for the response to the trend in error. This can cause arbitrary/noise-induced fluctuations in batch size, but can also help react quickly to increased/reduced capacity.

Flink的BackPressure

如果你看到一个task的back pressure告警（比如，high），这意味着生产数据比下游操作算子消费的速度快。Record的在你工作流的传输方向是向下游，比如从source到sink，而back pressure正好是沿着反方向，往上游传播。

举个简单的例子，一个工作流，只有source到sink两个步骤。假如你看到source端有个告警，这意味着sink消费数据速率慢于生产者的生产数据速率。Sink正在向上游进行back pressure。

采样线程

Back Pressure（后面翻译成背压）是通过重复采样正在运行的tasks的tack trace样本数据来监控任务的。JobManager会针对你的job的tasks重复触发调用Thread.getStackTrace()。

如果样本数据显示任务线程卡在某个内部方法调用中（从网络堆栈请求缓冲区），则表示该任务存在背压。

默认情况，为了判断是否进行背压，jobmanager会每50ms触发100次stack traces。Web界面中显示的比率，告诉你在这些stack traces中，阻塞在内部方法调用的stack traces占所有的百分比，例如，0.01，代表着100次中有一次阻塞在内部调用。

•OK: 0

•LOW: 0.10

•HIGH: 0.5

为例避免stack trace采样导致task managers压力过大，web 界面仅仅在60s刷新一次。

配置

可以通过下面的属性进行配置

栗子

在flink的webui 的job界面中可以看到背压。

正在进行的采样

这意味着JobManager对正在运行的tasks触发stack trace采样。默认配置，这将会花费五秒钟完成。

点击之后，就触发了该操作算子所有task的采样。

背压状态

如果您看到任务的状态ok，则表示没有背压指示。另一方面，HIGH意味着任务被加压。

对比

Spark Streaming的背压比较简单，主要是根据后端task的执行情况，调度时间等，来使用pid控制器计算一个最大offset，进而来调整Spark Streaming从kafka拉去数据的速度。

Flink的背压就不仅限于从kafka拉去数据这块，而且背压方式不相同，他是通过一定时间内stack traces采样，阻塞的比率来确定背压的。