Flink 1.13.0 反压监控的优化

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: Flink 1.13.0 版本增加了很多新特征,具体可以参考前面一篇文章,在 Flink 1.13.0 版本之前,我们通常是通过 UI 上面的 BackPressure 或者 Metrics 里面的 inPoolUsage ,outPoolUsage 指标去分析反压出现的位置.在 Flink 1.13.0 版本中对反压监控新增了瓶颈检测,能够帮助我们快速定位反压的位置,因为性能分析的过程中第一个问题就是,哪个操作是瓶颈?为了帮助回答这个问题,Flink 公开了有关任务繁忙(正在执行工作)和反压(具有执行工作的能力,但不能执行任务的原因,因为其后继的算子无法接收更多数据)的度量标准。瓶颈的候选者

Flink 1.13.0 版本增加了很多新特征,具体可以参考前面一篇文章,在 Flink 1.13.0 版本之前,我们通常是通过 UI 上面的 BackPressure 或者 Metrics 里面的 inPoolUsage ,outPoolUsage 指标去分析反压出现的位置.在 Flink 1.13.0 版本中对反压监控新增了瓶颈检测,能够帮助我们快速定位反压的位置,因为性能分析的过程中第一个问题就是,哪个操作是瓶颈?为了帮助回答这个问题,Flink 公开了有关任务繁忙(正在执行工作)和反压(具有执行工作的能力,但不能执行任务的原因,因为其后继的算子无法接收更多数据)的度量标准。瓶颈的候选者是那些繁忙的算子,他们的上游承受了压力,这篇文章主要介绍一下新版本里面如何定位反压位置.


Task performance metrics

任务(subtask)的每个并行实例都公开一组三个指标.


backPressureTimeMsPerSecond,子任务花费的时间


idleTimeMsPerSecond,子任务等待处理数据所花费的时间


busyTimeMsPerSecond,子任务忙于执行一些实际工作的时间在任何时间点,这三个指标的总和大约为1000ms。


这些指标每两秒钟更新一次,上报的值表示在最后几秒钟内子任务受到反压力(或空闲或忙碌)的平均时间。如果您的工作有不同的工作量,请记住这一点。例如,一个恒定负载为 50% 的子任务以及另一个在完全加载和空转之间每秒切换的子任务都将具有相同的 busyTimeMsPerSecond 值:大约 500ms。


在内部,根据输出缓冲区的可用性来判断反压。如果任务没有可用的输出缓冲区,则该任务被视为反压。另一方面,空闲是由是否有可用输入来确定的。


Example

如果你打开新版本的 WEB UI 首先你会发现 DAG 图的蓝色变重了,并且每个 operator 下面多了一个 Backpressured 因为新版本增加了通过不同的颜色来表示 operator 的繁忙或空闲状态,从而更直观的展示出反压的算子,让我们一眼就能看出反压的算子.



为了让任务出现反压,我找了一个 任务,然后把 source 的并行度设置为 4,其余算子的并行度都设置为 1,并且打断了 operator chain,这样更容易观察每个算子的颜色和状态.

然后往上游 kafka 里面生产 500 万数据,因为后面算子的并行度只有 1 很快任务就出现了反压,可以发现 DAG 图中出现了好几种颜色,空闲状态为蓝色,完全反压状态为黑色,完全忙碌状态为红色。所有介于两者之间的值都用这三种颜色之间的阴影来表示。



从上图可以看出,颜色最重的是 Map 算子(倒数第二个),最后一个 window 算子显示红色,说明反压最严重的地方是 Map,所以真正出现反压的位置是 window 算子的 processfunction 方法(最后一个算子)因为 processfunction 处理数据比较慢从而导致了 map 反压,然后逐级向上反压,直到数据源 source 出现反压.这样根据 DAG 的颜色就能判断出反压的位置,不用在去看 BackPressure ,inPoolUsage ,outPoolUsage 指标,更加的简便直观.


SubTasks Back Pressure Status



对于状态为 OK 的 subtask,没有反压的迹象。另一方面,high 表示 subtask 受到反压力。状态通过以下方式定义:


OK: 0% <= back pressured <= 10%


LOW: 10% < back pressured <= 50%


HIGH: 50% < back pressured <= 100%


此外,还会显示每个 subtask 的 Backpressured / Idle / Busy 的时间百分比.


我的这个 Demo 可能还不是很明显,大家可以看一下官网的图




这张图会更明显,反压的位置是在滚动窗口和滑动窗口这两个算子上.

相关实践学习
基于Hologres轻松玩转一站式实时仓库
本场景介绍如何利用阿里云MaxCompute、实时计算Flink和交互式分析服务Hologres开发离线、实时数据融合分析的数据大屏应用。
Linux入门到精通
本套课程是从入门开始的Linux学习课程,适合初学者阅读。由浅入深案例丰富,通俗易懂。主要涉及基础的系统操作以及工作中常用的各种服务软件的应用、部署和优化。即使是零基础的学员,只要能够坚持把所有章节都学完,也一定会受益匪浅。
相关文章
|
2月前
|
Java 流计算
利用java8 的 CompletableFuture 优化 Flink 程序
本文探讨了Flink使用avatorscript脚本语言时遇到的性能瓶颈,并通过CompletableFuture优化代码,显著提升了Flink的QPS。文中详细介绍了avatorscript的使用方法,包括自定义函数、从Map中取值、使用Java工具类及AviatorScript函数等,帮助读者更好地理解和应用avatorscript。
利用java8 的 CompletableFuture 优化 Flink 程序
|
2月前
|
存储 缓存 监控
Flink如何优化?需要注意哪些方面?
【10月更文挑战第10天】Flink如何优化?需要注意哪些方面?
79 6
|
4月前
|
消息中间件 监控 关系型数据库
实时计算 Flink版产品使用问题之运行后,怎么进行监控和报警
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
4月前
|
机器学习/深度学习 监控 Serverless
Serverless 应用的监控与调试问题之Flink在内部使用的未来规划,以及接下来有什么打算贡献社区的创新技术
Serverless 应用的监控与调试问题之Flink在内部使用的未来规划,以及接下来有什么打算贡献社区的创新技术
|
4月前
|
机器学习/深度学习 监控 大数据
Serverless 应用的监控与调试问题之Flink在整个开源大数据生态中应该如何定位,差异化该如何保持
Serverless 应用的监控与调试问题之Flink在整个开源大数据生态中应该如何定位,差异化该如何保持
|
4月前
|
存储 监控 Serverless
Serverless 应用的监控与调试问题之Pravega和Flink实现端到端的auto-scaling要如何操作
Serverless 应用的监控与调试问题之Pravega和Flink实现端到端的auto-scaling要如何操作
|
4月前
|
SQL 监控 大数据
Serverless 应用的监控与调试问题之Flink流式数仓对于工商银行的数据链路要如何简化
Serverless 应用的监控与调试问题之Flink流式数仓对于工商银行的数据链路要如何简化
|
4月前
|
存储 监控 Cloud Native
Serverless 应用的监控与调试问题之Flink流批一体在架构层面有什么演进
Serverless 应用的监控与调试问题之Flink流批一体在架构层面有什么演进
|
4月前
|
存储 监控 Serverless
Serverless 应用的监控与调试问题之Flink对于Checkpoint Barrier流动缓慢的问题要如何解决
Serverless 应用的监控与调试问题之Flink对于Checkpoint Barrier流动缓慢的问题要如何解决
|
4月前
|
SQL 资源调度 流计算
慢sql治理问题之在 Flink 中, userjar 分发问题如何优化
慢sql治理问题之在 Flink 中, userjar 分发问题如何优化