Flink反压与背压

Flink用什么监控，监控什么？如何有效处理数据积压？

监Flink的任务是否停止，Kafka的LAG(消息堆积)，

1. Flink Web UI
   比如反压：通过Thread.getStackTrace()采集在TakManager上正在运行的所有线程，收集在缓冲区请求中阻塞的线程数(意味着下游阻塞)，并计算缓冲区阻塞线程数与总线程数的比值rate，rate < 0.1为OK,0.1<=rate<=0.5为LOW,rate>0.5为HIGH
2. Prometheus&Grafana监控
   作业的可用性，如uptime(作业持续运行的时间),fullRestarts（作业重启的次数）
   作业的流量，可以通过numRecordsIn，numBytesInLocal等相关指标来关注作业每天处理的消息数目及高峰时间段的流量，通过关注这些指标可以观察作业的流量表现是否正常
   2.1 CPU (CPU.Load)
   2.2 内存 (Heap.Used)
   2.3 GC (GarbageCollector.Count ，GarbageCollector.Time )
   2.4 网络（inputQueueLength，outputQueueLength）

checkpoint相关信息：
lastCheckpointDuration： 最近完成checkpoint的时长
lastCheckpointSize: 最近完成checkpoint的大小
lastCheckpointRestoreTimestamp： 作业失败后恢复的能力
numberOfCompletedCheckpoints，numberOfFailedCheckpoints： 成功和失败的checkpoint数目
checkpointAlignmentTime： Exactly once模式下barrier对齐时间
connector 的指标，例如常用的 Kafka connector ，Kafka 自身提供了 一些指标，可以帮助我们了解到作业最新消费的消息的状况、 作业是 否有延迟等
**其他自定义指标:**超时丢弃的数据量， filter 过滤的数据量/占比 处理 失败的数据，等等

背压

背压产生的原因：

下游消费的速度跟不上上游产生数据的速度，可能原因如下

1. 节点有性能瓶颈，可能是该节点所在的机器有网络，磁盘等等故障，机器的网络延迟和磁盘不足，频繁GC，数据热点等原因
2. 数据源生产的数据过快，计算框架处理不及时。
3. flink算子间并行度不同，下游算子相比上游算子过小

背压导致的影响

背压不会导致系统崩盘，只是处在一个不健康的运行状态

1. 背压会导致流处理作业数据延迟的增加
2. 影响到Checkpoint，导致失败，导致状态数据保存不了，如果上游是Kafka数据源，在一致性的要求下，可能会导致offset的提交不上
   原因： 由于Flink的Checkpoing机制需要进行Barrier对齐，如果此时某个Task出现了背压，Barrier流动的速度就会变慢，导致Checkpoing整体时间变长，如果背压很严重，还有可能导致Checkpoing超时失败
3. 影响state的大小，还是因为checkpoing barrier对齐要求。导致state变大
   原理： 接受到较快的输入管道的barrier后，他后面数据会被缓存起来但不处理，直到较慢的输入管道的barrier也到达，这些被缓存的数据会被放到state里面，导致state变大。

Flink 不需要 一个特殊的机制来处理背压，Flink中的数据传输相当于已经提供了应对背压的机制，所以只有从代码上与资源上去做一些调整

1. 背压部分因为可能是由于数据倾斜造成的，我们可以通过Web UI 各个SubTask的指标值来确认，Checkpoint detail 里不同的SubTask 的State size也是一个分析数据倾斜的有用指标，解决方式把数据分组的key预聚合来消除数据倾斜
2. 代码的执行效率问题，阻塞或者性能问题
3. TaskManager的内存大小导致背压