《企业级云原生白皮书项目实战》——第五章 大数据——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 出现数据热点。
对于出现数据清晰的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号分区基本上没数据。
分析这个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
