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的内存大小导致背压

你可能感兴趣的:(Flink,flink,kafka,big,data)