首页  流程图  详情

20--Backpressure反压

2023-09-02 10:13:24   2  举报





Backpressure反压

大数据

Flink

作者其他创作

大纲/内容

Backpressure反压

原因生产数据的速率比Task消费速率快反压传播是从下游到上游传播

IG接收上游数据有对应的缓冲区

静态反压

idleTimeMsPerSecondsubtask 等待某类处理的时间

CPU瓶颈

反压监控面板Flink Task Metrics

一个或者一些线程造成CPU瓶颈 CPU不会过高只能使用代码分析工具来定位热点线程

瓶颈是数据倾斜造成的，可以尝试删除倾斜数据改变数据分区策略将造成数据的key值拆分也可以进行本地聚合/预聚合

动态反压

负载不均

通用反压策略

反压定位

2.TaskManager内反压过程

TCP 当中有一个 ZeroWindowProbe 的机制定期发送一个字节探测消息接收端就会返回窗口大小

不反压

可以控制上游速度

WebUI蓝色：闲置繁忙：红色黑色：被反压

RS往下游发送数据有对应的缓冲区

基于1.5改版每一次ResultSubPartition向InputChannel发送消息的时候会先发送一个Backion Size告诉提前告诉下游我发了多少条数据 InputChannel接收到消息就会提前准备Buffter空间来接收消息接收到消息还剩于多少空间如果空间不够就会返回credit=0效率比较高下游空间耗尽上游能感知到不需要通过其它层传递解决了Socket阻塞的问题

处理策略

busyTimeMsPerSecondsubtask 实际工作时间

OK: 0% <= 反压比例 <= 10%LOW: 10% < 反压比例 <= 50%HIGH: 50% < 反压比例 <= 100%

反压原因

公共缓冲区NetWorkBuffterPool

State大小为了保证准确一次多个管道就需要对齐接收到较快的管道数据后后面的数据就会缓存起来不处理放到state里面导致checkPoint变大

系统资源

调大还是会有压力

缺点：Socket复用：当一个反压阻塞之后其它任务也会堵塞依赖底层TCP做流控：导致反压传播路径太长导致延迟比较大

指标

反压监控面板注意点1.反压的根源节点并不一定会在反压监控面板体现出高反压2.反压监控的发送端某节点性能瓶颈不会高反压导致上游高反压3.如果找到第一个出现反压的节点，那么反压根源要么是就这个节点要么是它紧接着的下游节点

缓冲区剩余空间

Flink反压流控

跟上面CPU/线程瓶颈问题类似，一个子任务可能由于对共享资源的高线程争用成为瓶颈同样的，CPU分析工具对于探查这类问题也很有用

1.5以后 / Credit-based 反压机制

影响checkpoint 时长和 state 大小

backPressureTimeMsPerSecondsubtask 被反压的时间

1.跨TaskManager反压过程

CheckPoint因为CheckPoint barrier跟随普通数据一起流的不会越过普通数据导致端-端期间的时长边长

消费者动态告诉生产者处理能力

Task

1.NetWorkBP会去Off-heap 申请内存用来后面资源共享不需要依赖JVM GC2.生产者写消息进来 RerultSuPartiton最开始空的不能接收数据就会向LBP申请内存 LBP也没有就会向NWBP申请将申请到的Buffter返回给RSP3.RSP将Buffter拷贝到Netty Buffter 通过socket将消息发送出去4.接收端同样结构接收消息处理消息过一会因为数据的速度不匹配InChannel IC的Buffter就会满然后会向LBP申请Buffter继续使用5.当LBP满了就会向NWBP申请给定的空间防止一个LBP将NWBP缓冲耗尽6.当后面缓冲耗尽了生产者的Socket也会溢满 Netty检测到了就会停止写数据7.所有的都会堵在NettyBuffter 因为它是无界流可以通过水位机制控制当到达指定水位了就会置为不可写 RSP就会停止发送数据8.压力来到RSP 同理会不断的申请Buffter 直到把LBP和NWBP耗尽给定资源 RW停止写入

反压是流处理系统中用来保障应用可靠性的一个重要机制上游处理单元降低数据发送的速率，以缓解下游处理单元的压力

TCP包结构Sequence number机制：给每个数据包做一个编号ACK number机制：确保TCP数据是可靠的Window Size：消费者返回消息就返回缓冲区还有长度多少

反压处理阶段划分两个阶段

1.下游的反压导致上游的写入堵塞 NWBP资源耗尽导致RW堵塞住2.内部的接收上游的线程也会停止读数据但是上游又不断的发送数据导致内部的NWBP占满

TaskManager内部

线程争用

outputBuffter

处理的条数Spark

1.5以前 / TCP-based反压机制

inputBufftert

性能问题常常源自过长的GC时长可以通过打印日志或者使用分析GC的工具

通过三个值来判断 Task最近两秒内的反压忙闲的平均时长当你的工作负荷的不断变化需要尤其注意一个恒定50%负载工作的subtask 与满负载和空闲来回切换的工作时间值相同