22、Flink 解决数据倾斜问题

文章讲述了如何通过FlinkWebUI和Checkpointdetail判断数据倾斜,针对keyBy后的聚合、keyBy之前和窗口聚合操作中的倾斜分别提出了解决方案,包括LocalKeyBy、shuffle/rebalance/rescale和两阶段聚合策略。
Flink 解决数据倾斜问题
一、判断是否存在数据倾斜

相同 Task 的多个 SubTask 中,个别 SubTask 接收到的数据量明显大于其他 SubTask 接收到的数据量,通过 Flink Web UI 可以精确地看到每个 Subtask 处理了多少数据,即可判断出 Flink 任务是否存在数据倾斜。

通常,数据倾斜也会引起反压。

在这里插入图片描述

另外, Checkpoint detail 里不同 SubTask 的 State size 也是一个分析数据倾斜的有用指标。
二、数据倾斜解决方案
1)keyBy 后的聚合操作存在数据倾斜
1.不能直接用二次聚合来处理

如果 keyby 之后的聚合操作存在数据倾斜,且没有开窗口(没攒批)的情况下,使用两阶段聚合,是不能解决问题的。

因为 Flink 是来一条处理一条,向下游发送一条结果,对于原来 keyby 的维度(第二阶段聚合)来讲,数据量并没有减少,且结果重复计算(非 FlinkSQL,未使用回撤流)。

2.使用 LocalKeyBy 的思想

在 keyBy 上游算子数据发送之前,首先在上游算子的本地对数据进行聚合后,再发送到下游,使下游接收到的数据量大大减少,从而使得 keyBy 之后的聚合操作不再是任务的瓶颈。

类似 MapReduce 中 Combiner 的思想,但是这要求聚合操作必须是多条数据或者一批数据才能聚合,单条数据没有办法通过聚合来减少数据量。

从 LocalKeyBy 实现原理来讲,必然会存在一个积攒批次的过程,在上游算子中攒够一定的数据量,对这些数据聚合后再发送到下游。

3.实现方式

DataStream API :在 keyBy 之前开窗口做预聚合聚合;

FlinkSQL API:开启 miniBatch 和 LocalGlobal 功能

2)keyBy 之前发生数据倾斜

如果 keyBy 之前就存在数据倾斜,上游算子的某些实例可能处理的数据较多,某些实例可能处理的数据较少,产生该情况可能是因为数据源的数据本身就不均匀,例如由于某些原因 Kafka 的 topic 中某些 partition 的数据量较大,某些 partition 的数据量较少。

对于不存在 keyBy 的 Flink 任务也会出现该情况。

方案:使用 shuffle、rebalance 或 rescale 算子即可将数据均匀分配,从而解决数据倾斜的问题。

3)keyBy 后的窗口聚合操作存在数据倾斜

因为使用了窗口,变成了有界数据(攒批)的处理,窗口默认是触发时才会输出结果发往下游,可以使用两阶段聚合的方式。

方案

第一阶段聚合:key 拼接随机数前缀或后缀,进行 keyby、开窗、聚合

注意:聚合完不再是 WindowedStream,要获取 WindowEnd 作为窗口标记作为第二阶段分组依据,避免不同窗口的结果聚合到一起

第二阶段聚合:按照原来的 key 及 windowEnd 作 keyby、聚合

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

猫猫爱吃小鱼粮

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值