Flink 作业如何进行性能瓶颈分析
Flink 作业如何进行性能瓶颈分析
本文主要介绍如何通过监控查看Flink 作业状态并且根据不同的场景进行优化
概念说明
延迟
source 端会周期性的发送带当前时间戳的LatencyMarker,下游算子接收到标记后,通过当前时间减去标记中带时间戳的方式,计算延迟指标。算子的时延可以通过监控中的时延图表来查看,监控?会取出最大时延算子做数据展示。一般情况下,算子的高时延和反压会成对出现。
数据滞留量
适用于Flink kafka consumer 此窗口中任何分区的记录数最大延迟。没有被消费的记录数。随着时间的推移,越来越大的延时,表明消费者没有跟上生产者的速度
输入QPS
此算子每秒接收的记录数
输出QPS
此算子每秒发送的记录数
parser解析的错误数据量
任务发生数据解析错误的记录条数
Failover次数
任务发生异常的次数
以上指标通过作业运维页面“监控”即可访问查看
监控?
反压状态
反压状态是通过周期性对taskManager线程的栈信息采样,计算被阻塞在请求输出Buffer的线程比率来确定,默认情况下,比率在0.1以下为OK,0.1到0.5为LOW,超过0.5则为HIGH。
反压状态通过作业运维页面“任务页面”进入flink Web UI 查看
WebUI 集合了所有子任务的反压和繁忙指标的最大值,并在 JobGraph 中将集合的值进行显示。除了显示原始的数值,tasks 也用颜色进行了标记,使检查更加容易。
闲置的 tasks 为蓝色,完全被反压的 tasks 为黑色,完全繁忙的 tasks 被标记为红色。 中间的所有值都表示为这三种颜色之间的过渡色。
作业的反压情况可以通过JobGraph展示的作业算子链查看,同时可以通过点击算子的”BackPressure”选项卡查看更多的细节指标
更多相关指标可通过点击具体算子的metrics 选择对应指标进行查看
更多作业监控指标
性能分析
由于Flink的反压机制,流作业在存在性能问题的情况下,会导致数据源消费速率跟不上生产速率,从而引起Kafka消费组的积压。在这种情况下,可以通过算子的反压和时延,确定算子的性能瓶颈点。
可能存在以下作业场景:
所有算子反压都正常(蓝色),但存在数据堆积
该场景说明性能瓶颈点在Source,主要是受数据读取速度影响,此时可以通过增加Kafka分区数并增加source并发解决。作业首个或非倒数第二个算子反压很高(红色)
该场景说明性能瓶颈点在Vertex2算子,可以通过查看该算子描述,确认该算子具体功能,以进行下一步优化。作业最后一个算子反压正常(蓝色),前面算子反压高(红色)
该场景说明性能瓶颈点在sink,可以通过调整sink.parallelism来优化.但还需要根据对应的具体数据源具体优化,比如对于JDBC数据源,可以通过调整写出批次及刷写时间(sink.buffer-flush.max-rows 、sink.buffer-flush.interval)等,可参考连接器属性参数。作业一个算子反压高(红色),而后后续多个并行算子反压正常(蓝色)
需要注意的是,Flink从1.10版本以后(包括1.10),自动优化了算子链,允许非shuffle算子共存于同一线程,避免了序列化和反序列化。所以有时看到的WebUI JobGraph中只有一个Vertex ,为了方便分析算子瓶颈,需要在作业开发页面“高级配置”选项卡配置
该场景说明性能瓶颈在Vertex2或者Vertex3,为了进一步确定具体瓶颈点算子,可以在FlinkUI页面开启inPoolUsage监控。如果某个算子并发对应的inPoolUsage长时间为100%,则该算子大概率为性能瓶颈点,需分析该算子以进行下一步优化。
inPoolUsage 监控pipeline.operator-chaining false
,重启任务后,可看到全部算子链。问题解决后,建议注释该参数,该参数设置为false 后在一定程度上会影响性能。
以上内容对您是否有帮助?