flink和sparkStreaming中BackPressure的示例分析

这篇文章将为大家详细讲解有关flink和spark Streaming中Back Pressure的示例分析,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。

成都创新互联公司专注为客户提供全方位的互联网综合服务,包含不限于网站设计、成都网站建设、竞秀网络推广、微信小程序开发、竞秀网络营销、竞秀企业策划、竞秀品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等,从售前售中售后,我们都将竭诚为您服务,您的肯定,是我们最大的嘉奖;成都创新互联公司为所有大学生创业者提供竞秀建站搭建服务,24小时服务热线:028-86922220,官方网址:www.cdcxhl.com

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速率计算源码

flink和spark Streaming中Back Pressure的示例分析

配置Spark Streaming的back pressure

spark.streaming.backpressure.initialRate: 启用反压机制时每个接收器接收第一批数据的初始最大速率。默认值没有设置。

spark.streaming.backpressure.rateEstimator:速率估算器类,默认值为 pid ,目前 Spark 只支持这个,大家可以根据自己的需要实现。

spark.streaming.backpressure.pid.proportional:用于响应错误的权重(最后批次和当前批次之间的更改)。默认值为1,只能设置成非负值。weight for response to "error" (change between last batch and this batch)

spark.streaming.backpressure.pid.integral:错误积累的响应权重,具有抑制作用(有效阻尼)。默认值为 0.2 ,只能设置成非负值。weight for the response to the accumulation of error. This has a dampening effect.

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.

spark.streaming.backpressure.pid.minRate:可以估算的最低费率是多少。默认值为 100,只能设置成非负值。

更多Spark教程,关注浪尖公众号:Spark学习技巧

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()。

flink和spark Streaming中Back Pressure的示例分析

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

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

• OK: 0 <= Ratio <= 0.10

• LOW: 0.10 < Ratio <= 0.5

• HIGH: 0.5 < Ratio <= 1

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

配置

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

1, jobmanager.web.backpressure.refresh-interval:在这个时间之后,统计数据将会废弃,需要重新刷新。默认是60000,也即是1min。

2, jobmanager.web.backpressure.num-samples:判断背压需要进行stack trace采样的个数,默认是100

3, jobmanager.web.backpressure.delay-between-samples:两次stack trace个采用间隔。

栗子

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

正在进行的采样

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

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

flink和spark Streaming中Back Pressure的示例分析

背压状态

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

flink和spark Streaming中Back Pressure的示例分析

flink和spark Streaming中Back Pressure的示例分析

对比

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

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

关于“flink和spark Streaming中Back Pressure的示例分析”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,使各位可以学到更多知识,如果觉得文章不错,请把它分享出去让更多的人看到。


当前名称:flink和sparkStreaming中BackPressure的示例分析
当前链接:http://myzitong.com/article/ppeegs.html