Flink优化——数据倾斜（二）

目录

数据倾斜

判断是否存在数据倾斜

数据倾斜的解决

KeyBy之前发生数据倾斜

KeyBy之后发生的数据倾斜

聚合操作存在数据倾斜

窗口聚合操作存在数据倾斜

---

数据倾斜

判断是否存在数据倾斜

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

数据倾斜的解决

KeyBy之前发生数据倾斜

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

这种情况，需要让 Flink 任务强制进行 shuffle，使用 shuffle、rebalance 或 rescale 算子即可将数据均匀分配，从而解决数据倾斜的问题。

KeyBy之后发生的数据倾斜

聚合操作存在数据倾斜

使用 LocalKeyBy 的思想：在 keyBy 上游算子数据发送之前，首先在上游算子的本地对数据进行聚合后再发送到下游，使下游接收到的数据量大大减少，从而使得 keyBy 之后的聚合操作不再是任务的瓶颈。类似 MapReduce 中 Combiner 的思想，但是这要求聚合操作必须是多条数据或者一批数据才能聚合，单条数据没有办法通过聚合来减少数据量。从 Flink LocalKeyBy 实现原理来讲，必然会存在一个积攒的批次的过程，在上游算子中必须攒够一定的数据量，对这些数据聚合后再发送到下游，即（状态 + ttl）。

注意： Flink 是实时流处理，如果 keyby 之后的聚合操作存在数据倾斜，且没有开窗口的情况下，简单的任务使用两阶段聚合，是不能解决问题的。因为这个时候Flink 是来一条处理一条，且向下游发送一条结果，对于原来 keyby 的维度（第二阶段聚合）来讲，数据量并没有减少，且结果重复就算（非 Flink SQL，未使用回撤流）。

窗口聚合操作存在数据倾斜

因为使用了窗口，变成了有界数据的处理，窗口默认是触发时才会输出一条结果发往下游，所以可以使用两阶段聚合的方式：

实现思路：

• 第一阶段聚合：key 拼接随机数前缀或后缀，进行 keyby、开窗、聚合。注意：聚合完不再是 WindowedStream，要获取 WindowEnd 作为窗口标记作为第二阶段分组依据，避免不同窗口的结果聚合到一起。
• 第二阶段聚合：去掉随机数前缀或后缀，按照原来的 key 及 windowEnd 作 keyby聚合

参考：

180-Flink优化-数据倾斜-KeyBy后开窗聚合_哔哩哔哩_bilibili