有关flink数据消费速度的问题

1、反压产生的场景

反压经常出现在促销、热门活动等场景。短时间内流量陡增造成数据的堆积或者消费速度变慢。

它们有一个共同的特点：数据的消费速度小于数据的生产速度。

2、反压危害

Flink会因为数据堆积和处理速度变慢导致checkpoint超时，而checkpoint是Flink保证数据一致性的关键所在，最终会导致数据的不一致发生。

3. 反压原因及定位

数据倾斜：可以在 Flink 的后台管理页面看到每个 Task 处理数据的大小。当数据倾斜出现时，通常是简单地使用类似 KeyBy 等分组聚合函数导致的，需要用户将热点 Key 进行预处理，降低或者消除热点 Key 的影

代码本身：开发者错误地使用 Flink 算子，没有深入了解算子的实现机制导致性能问题。我们可以通过查看运行机器节点的 CPU 和内存情况定位问题

GC：不合理的设置 TaskManager 的垃圾回收参数会导致严重的 GC 问题，我们可以通过** -XX:+PrintGCDetails** 参数查看 GC 的日志。

ask之间有一个网络共享池NetworkBufferPool，前面的算子从共享池中获取内存块MemorySegment向后面的算子发送数据，后面的算子接收数据也会从共享池中获取内存块，如果后面的算子处理速度慢，占用共享池中较多的内存块而没释放，那共享池中的内存块都被后面的算子占用，前面的算子无法从共享池中再获取内存块，也就没法发送数据，最终会导致数据源的数据消费速度下降，对吧，这个逻辑没问题吧。现在有可能就是共享池太大了，给它修改小点，不让它积压那么多数据，处理不了那么快就不要消费那么快

Flink反压问题:

https://www.jianshu.com/p/a8b42850a78e

ck失败:

Flink Checkpoint 问题排查使用指南

写文件时

Problem while truncating file: hdfs://beh001/user/hive/hdfs_sscj/VolteAnalyseFor5g/UFDR/DETAIL_UFDR_FTP/2022-10-24/05/.part-0-272.inprogress.d784f1de-b65e-470f-a75c-22913bbbd92b

flink StreamingFileLink由于截断hdfs文件失败而失败_大数据知识库 (saoniuhuo.com)

(160条消息) StreamingFileSink fails due to truncating HDFS file failure_AUB的博客-CSDN博客

(160条消息) Flink StreamingFileSink 文件到hdfs 文件一直处于inprogress状态无法生成正式文件_cullinans的博客-CSDN博客

优化总结:

下游算子的处理速度直接影响上游算子的推送速度;

ck失败的直接原因是下游开窗速度慢,导致数据积压,上游推送速率减缓,标记点流动缓慢导致ck超时;

TaskManager负载不均的主要原因是每个TaskSolt数据量差异大导致,尤其是获取数据源阶段,并行度需要与上游分区数量一致,或者为上游分区数的一半;如果并行度>分区数,就会导致某些TaskSolt没数据,导致有些TaskManager利用率高有些则很低;

消费线程数=kafka分区数
在这种情况下，通过第一部分我们知道，kafka分区和消费线程是一一对应的，每个消费线程只会去消费特定的kafka分区中的数据。kafka分区数：flink程序消费线程数=1:1，这样消费效率较高。但这样也可能会存在：kafka中的某个分区数据量较大，有数据倾斜的可能性，在消费线程中就会出现消费速率低下，甚至出现反压的情况。想要控制这种情况的出现，可以在将数据放入kafka中按照主键或者某个字段进行分区操作，这样尽可能的保证kafka中的数据不会存在倾斜的情况。
消费线程数>kafka分区数
这种情况就会出现，某几个线程会消费kafka分区中的数据，但是剩下的线程找不见分区中的数据，线程就会空转，浪费资源。这样也会导致一个问题，checkpoint做不了，可能会导致ck超时失败。ck失败，程序无法保存状态，程序就会失败宕机。这种情况应该禁止出现。
消费线程数<kafka分区数
这种情况下，某个线程可能会消费多个kafka分区中的数据。数据量较大时，出现数据倾斜的可能性会比较大，也可能因为消费速率导致出现反压进而影响程序的正常运行。这种情况也尽量避免。