ios软件资源网站,常州微信网站建设市场,wordpress是mvc架构吗,图片做网站我们在使用Flink程序进行流式数据处理时#xff0c;由于种种原因难免会遇到性能问题#xff0c;如我们在使用Flink程序消费kafka数据#xff0c;可能会遇到kafka数据有堆积的情况#xff0c;并且随着时间的推移#xff0c;数据堆积越来越多#xff0c;这就表名消费处理数…        我们在使用Flink程序进行流式数据处理时由于种种原因难免会遇到性能问题如我们在使用Flink程序消费kafka数据可能会遇到kafka数据有堆积的情况并且随着时间的推移数据堆积越来越多这就表名消费处理数据的速度没有跟上生产的速度。面对这种情况我们如何知道到底哪个环节造成性能瓶颈问题这就需要我们对flink作业链路进行分析排查找出存在瓶颈的算子。好在flink为我们提供了任务监控的Web UI我们可以可以通过监控的算子反压情况找出性能瓶颈的算子。 Flink 1.5 之前是基于 TCP 流控 bounded buffer 实现反压。 Flink 1.5 之后实现了自己托管的 credit – based 流控机制在应用层模拟 TCP 的流控机制。  反压如果不能得到正确的处理可能会影响到 checkpoint 时长和 state 大小甚至可能会导致资源耗尽甚至系统崩溃。 Flink的反压机制 Flink的反压BackPressure机制是通过周期性对taskManager线程的栈信息采样计算被阻塞在请求输出Buffer的线程比率来确定默认情况下比率在0.1以下为OK0.1到0.5为LOW超过0.5则为HIGH。算子链如果存在反压则意味着某个算子存在瓶颈即其处理速率跟不上上游发送数据的速率从而需要对上游进行限速影响任务整体处理性能。所以我们需要找出存在性能瓶颈的算子节点优化对应的算子才能解决整体的性能问题。算子是否存在反压可以通过Flink任务提供的Web UI的反压状态表现出来根据算子链的反压状态找出存在性能瓶颈的算子从而有针对性的进行优化。比如我们的流作业在存在性能问题的情况下会导致数据源消费速率跟不上生产速率从而引起Kafka消费组的积压。在这种情况下可以通过算子的反压和时延确定算子的性能瓶颈点。 反压场景进行分析及应对处理 下面对flink任务常见的反压场景进行分析及应对处理 kafka数据有堆积但所有算子反压都正常(蓝色) 该场景说明性能瓶颈点在Source主要是受数据读取速度影响此时可以通过增加Kafka分区数并增加source并发解决。 作业首个或非倒数第二个算子反压很高(红色) 该场景说明性能瓶颈点在Vertex2算子可以通过查看该算子描述确认该算子具体功能以进行下一步优化。 作业最后一个算子反压正常(蓝色)但前面的算子都高反压(红色) 该场景说明性能瓶颈点在sink算子Vertex3可以通过调整sink.parallelism来优化.但还需要根据对应的具体数据源具体优化比如对于JDBC数据源可以通过调整写出批次及刷写时间(sink.buffer-flush.max-rows 、sink.buffer-flush.interval)等。 反压算子下游有多个算子 如下作业一个算子反压高(红色)而后后续多个并行算子反压正常(蓝色) 该场景说明性能瓶颈在Vertex2或者Vertex3为了进一步确定具体瓶颈点算子可以在FlinkUI页面开启inPoolUsage监控。如果某个算子并发对应的inPoolUsage长时间为100%则该算子大概率为性能瓶颈点需分析该算子以进行下一步优化。 inPoolUsage 监控 总结 依次算子链从前往后找到最后一个反压算子节点则瓶颈一般为该节点的下游节点如果其下游有多个节点则通过查看其所有下游节点的Metrics监控的buffers.inPoolUsage如果某节点的buffers.inPoolUsage长期为1则该节点即为瓶颈节点。