带你读《企业级云原生白皮书项目实战》——5.3.3 任务性能(4)

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: 带你读《企业级云原生白皮书项目实战》——5.3.3 任务性能(4)

《企业级云原生白皮书项目实战》——第五章 大数据——5.3 实时计算Flink版——5.3.3 任务性能(3) https://developer.aliyun.com/article/1228337


5.3.3.2.2 排查优化方案

数据倾斜是flflink任务中大家都会遇到的高频问题,一旦发生数据倾斜会带来哪些影响呢。

(1)单点问题

数据集中在某些分区上(Subtask),导致数据严重不平衡,单点资源处理耗时长。

(2)GC 频繁

过多的数据集中在某些 JVM(TaskManager),使得JVM 的内存资源短缺,导致频繁 GC情况。

(3)吞吐下降、延迟增大

数据单点和频繁 GC 导致吞吐下降上游消费慢,下游写入慢、任务整体延迟增大。

(4)系统崩溃

严重情况下,过长的 GC 导致 TaskManager 失联,任务异常终止。面对这种常见的flflink任务数据倾斜情况,一般有如下的定位排查方案。首先根据flflink任务清理在确定是否存在数据倾斜情况:

(1)根据flflink监控查看任务反压

Flink Web UI 自带的反压监控(直接方式)来确定任务出现反压,然后通过监控反压的信息,可以获取到数据处理瓶颈的 Subtask。

(2)查看对应Subtasks,多并发情况下,当 Subtasks 之间处理的数据量有较

大的差距,则该 Subtask 出现数据倾斜。如下图所示,红框内的 Subtask 出现数据热点。

image.png


对于出现数据清晰的flflink任务如何进行排查呢?常见的有付下的一些场景:

(1)数据源 source 消费不均匀

解决思路:通过调整并发度,解决数据源消费不均匀或者数据源反压的情况。例如kafka数据源,可以调整 KafkaSource 的并发度解决消费不均匀。调整并发度的原则:KafkaSource 并发度与 kafka 分区数是一样的,或者 kafka 分区数是KafkaSource 并发度的整数倍。

(2)key 分布不均匀的无统计场景

问题说明:key分布不均匀的无统计场景,例如上游数据分布不均匀,使用keyBy来打散数据。

解决思路:通过添加随机前缀,打散 key 的分布,使得数据不会集中在几个 Subtask。

(3)GroupBy + Aggregation 分组聚合热点问题

业务上通过 GroupBy 进行分组,然后紧跟一个 SUM、COUNT 等聚合操作是非常常见的。我们都知道 GroupBy 函数会根据 Key 进行分组,完全依赖 Key 的设计,如果 Key 出现热点,那么会导致巨大的 shufflfflffle,相同 key 的数据会被发往同一个处理节点;如果某个 key 的数据量过大则会直接导致该节点成为计算瓶颈,引起反压。

5.3.3.2.3 典型案例

flflink实时任务使用了窗口函数,但是发现下游的数据一直没有计算输出的异常。

根据上游kafka的监控查看,可以看到数据有严重的倾斜问题。如下图所示,10个分区中有三个分区数据量特别少,5号分区基本上没数据。

image.png


分析这个watermark的传递机制

当并行执行的情况下,如下图所示,每次接受的watermark发送的watermark都是最小的,木桶效应。但是,当某个分区始终无数据的时候,就不会更新该分区的watermark值,那么窗口就一直不会被触发计算。这种现象在某些hash极端导致数据倾斜很普遍。

解决方案:

把flflink任务的并行度改小,使得每个并行进程处理多个分区数据,同个并行的进程处理多分区数据就会使用最大的watermark,这里还有一点异常是来自上游kafka,从kafka的监控看数据写入kafka的分区的数据实际上就是不均衡的,如果是均衡的则一般不会出现flflink消费数据倾斜的情况,所以一般还是要保持flflink消费的上游数据源也是数据均衡的情况,也可以避免数据倾斜的发生,实际的做法就是写入的时候将数据打散,避免出现分区热点数据的情况。


《企业级云原生白皮书项目实战》——第五章 大数据——5.3 实时计算Flink版——5.3.3 任务性能(5) https://developer.aliyun.com/article/1228335

相关文章
|
4天前
|
分布式计算 大数据 Apache
ClickHouse与大数据生态集成:Spark & Flink 实战
【10月更文挑战第26天】在当今这个数据爆炸的时代,能够高效地处理和分析海量数据成为了企业和组织提升竞争力的关键。作为一款高性能的列式数据库系统,ClickHouse 在大数据分析领域展现出了卓越的能力。然而,为了充分利用ClickHouse的优势,将其与现有的大数据处理框架(如Apache Spark和Apache Flink)进行集成变得尤为重要。本文将从我个人的角度出发,探讨如何通过这些技术的结合,实现对大规模数据的实时处理和分析。
26 2
ClickHouse与大数据生态集成:Spark & Flink 实战
|
26天前
|
SQL 消息中间件 分布式计算
大数据-124 - Flink State 01篇 状态原理和原理剖析:状态类型 执行分析
大数据-124 - Flink State 01篇 状态原理和原理剖析:状态类型 执行分析
60 5
|
26天前
|
分布式计算 监控 大数据
大数据-131 - Flink CEP 案例:检测交易活跃用户、超时未交付
大数据-131 - Flink CEP 案例:检测交易活跃用户、超时未交付
60 0
|
26天前
|
消息中间件 分布式计算 大数据
大数据-123 - Flink 并行度 相关概念 全局、作业、算子、Slot并行度 Flink并行度设置与测试
大数据-123 - Flink 并行度 相关概念 全局、作业、算子、Slot并行度 Flink并行度设置与测试
84 0
|
26天前
|
消息中间件 分布式计算 大数据
大数据-121 - Flink Time Watermark 详解 附带示例详解
大数据-121 - Flink Time Watermark 详解 附带示例详解
49 0
|
26天前
|
SQL 消息中间件 分布式计算
大数据-120 - Flink Window 窗口机制-滑动时间窗口、会话窗口-基于时间驱动&基于事件驱动
大数据-120 - Flink Window 窗口机制-滑动时间窗口、会话窗口-基于时间驱动&基于事件驱动
67 0
|
26天前
|
SQL 分布式计算 大数据
大数据-119 - Flink Window总览 窗口机制-滚动时间窗口-基于时间驱动&基于事件驱动
大数据-119 - Flink Window总览 窗口机制-滚动时间窗口-基于时间驱动&基于事件驱动
45 0
|
5天前
|
分布式计算 大数据 OLAP
AnalyticDB与大数据生态集成:Spark & Flink
【10月更文挑战第25天】在大数据时代,实时数据处理和分析变得越来越重要。AnalyticDB(ADB)是阿里云推出的一款完全托管的实时数据仓库服务,支持PB级数据的实时分析。为了充分发挥AnalyticDB的潜力,将其与大数据处理工具如Apache Spark和Apache Flink集成是非常必要的。本文将从我个人的角度出发,分享如何将AnalyticDB与Spark和Flink集成,构建端到端的大数据处理流水线,实现数据的实时分析和处理。
32 1
|
26天前
|
分布式计算 监控 大数据
大数据-148 Apache Kudu 从 Flink 下沉数据到 Kudu
大数据-148 Apache Kudu 从 Flink 下沉数据到 Kudu
51 1
|
18天前
|
存储 运维 监控
实时计算Flink版在稳定性、性能、开发运维、安全能力等等跟其他引擎及自建Flink集群比较。
实时计算Flink版在稳定性、性能、开发运维和安全能力等方面表现出色。其自研的高性能状态存储引擎GeminiStateBackend显著提升了作业稳定性,状态管理优化使性能提升40%以上。核心性能较开源Flink提升2-3倍,资源利用率提高100%。提供一站式开发管理、自动化运维和丰富的监控告警功能,支持多语言开发和智能调优。安全方面,具备访问控制、高可用保障和全链路容错能力,确保企业级应用的安全与稳定。
28 0