合肥做网站的网络公司白云做网站的公
目录
数据倾斜
判断是否存在数据倾斜
数据倾斜的解决
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