第一种、计算量大，CPU密集性，导致TM内线程一直在processElement，而没有时间做CP【过滤掉部分数据；增大并行度】
代表性作业为算法指标-用户偏好的计算，需要对用户在商城的曝光、点击、订单、出价、上下滑等所有事件进行比例计算，并且对各个偏好值进行比例计算，事件时间范围为近24小时。等于说每来一条数据，都需要对用户近24小时内所有的行为事件进行分类汇总，求比例，再汇总，再求比例，而QPS是1500，24小时1.5亿的累积数据，逻辑处理的算子根本无法将接收到的数据在合适的时间内计算完毕，这里还有个有趣的现象，为了提高处理性能，我将并行度翻倍，结果checkpoint的时间反而更长了，原因是Source的并行度也增加后，读取源数据的速度更快了～
从图片中可以看到source、sink的cp时间都很快，只有处理节点的'End to End Duration'时间特别长，其他的'Checkpoint Duration (Sync)'、'Checkpoint Duration (Async)'时间都很短，都为几百毫秒。
那么怎么办呢？这里我也反思了自己的实现逻辑，实时计算中，flink是流引擎，正确的使用姿势应该是对每一条数据进行实时处理，而不应该对较长历史时间范围内的历史数据进行批处理，如果每条数据来还需要对历史数据重新计算计算，那么就不符合flink的定位。所以和算法同学商议后，将实现逻辑进行修改，进行批流分开计算，比如离线数据每半个小时进行一次计算，而实时计算只需要计算最近半小时内的数据即可。总之两个方法，一、减少源数据量，过滤黑名单或者非法ID；window聚合； 二、简化处理逻辑，特别是减少遍历。
第二种、数据倾斜 解决方法
代表性作业对手机的uuid(设备编号)进行keyby，结果导致subtask的state大小差异一倍，两种方法，第一，两阶段聚合；第二，重新设置并行度，改变KeyGroup的分布
第三种 频繁FULL GC【减少key数量；增大TM内存】
当StateSize达到200M以上，Async的时间会超过1min。
这种情况特别少见，因为RocksDb State的异步阶段做的事情主要是将本地KV数据库里的增量State写到HDFS上，如果flink配置了增量chekcPoint是不太可能出现单个作业异步处理特别慢的现象。因此猜测是由于TM出现频繁FGC，导致线程根本没有足够的时间片去处理。
结果也确实如此，jstat -gcutil pid 1s，发现每4秒一个fgc。
dump分析
jmap -dump:format=b,file=jconsole.dump PID
./ParseHeapDump.sh jconsole.dump org.eclipse.mat.api:suspects
org.eclipse.mat.api:overview org.eclipse.mat.api:top_components
还有个有趣的现象是出现FGC时，反压机制会无法生效，在'BackPressure'界面会一片空白～
通过Dump分析，CopyOnWriteStateTable/CopyOnWriteStateMap占用绝大多数堆内存，也就是flink内部用于存储keyedState，CopyOnWriteStateTable 中保存多个 KeyGroup 的状态，每个 KeyGroup 对应一个 CopyOnWriteStateMap。
解决方法，keyby的key过多，要么减少key的数量，要么加大TM的内存。
如上，key的Selector定义中有日期，那么就导致key的数量会按天暴涨，也解释了为什么CopyOnWriteMapState对象会这么多了，因为即使KeyedProcessFunction中设置了StateTtl，State会过期，但是Key不会过期。
第四种 出现反压
还有一种情况是当一个作业出现反压时，也会导致超时，表现的形式就是 AcknowledgeTime 都无法拿到，或者 E2E 时间很长，等反压降才去就好了