flink常用的几种调优手段的优缺点

背景:

不管是基于减少反压还是基于减少端到端的延迟的目的，我们有时候都需要对flink进行调优，本文就整理下几种常见的调优手段以及他们的优缺点

flink调优手段

1.使用事件时间EventTime模式时，可以设置水位线发送的时间间隔，比如从200毫秒缩小到100毫秒,缩短两倍
正作用：减少事件端到端处理延迟
反作用：对于下游的算子来说，由于其会接收多个上游算子任务的水位记录，所以他们接收到的水印的速度可能远远小于100ms，处理更多的水位线记录会对系统性能造成影响，需要谨慎评估

2.使用setBufferTimeout命令减少网络发送缓冲区的超时时长,这个超时时间表示当上游任务发送网络数据到下游任务时，缓冲区满或者达到超时时间就会发送出去，比如网络缓冲超时时间从100ms变成50ms

正作用：减少端到端的处理延迟
反作用：由于网络缓冲区有可能没有满就被发送到下游算子，导致吞吐量下降

3.使用hashmap状态后端代替rockdb状态后端，基于hashmap的状态后端每次访问状态时都是通过内存直接访问的，速度很快，而访问rockdb的状态后端时，需要经历序列化和反序列化以及可能的磁盘IO，速度很慢

正作用：状态访问速度变快，减少端到端的延迟
反作用：状态很大时不支持，此外，状态放在内存中会导致更频繁的gc，导致消息的处理时延有尖峰波动

4.使用聚合窗口函数而不是全量窗口函数，通过timer触发的方法ontimer尽量减少耗时，此外如果非要使用长时间的全量窗口，那么尽可能的在全量窗口的前面加上预聚合的窗口算子，目的是尽量把长的时间窗口分解成一个个小的时间窗口

正作用: 提高吞吐量和数据处理时延
副作用: 可能会提高代码的复杂度

5.使用异步函数代替同步函数

正作用：提供吞吐量和减少消息处理延迟
反作用： 无

6.对事件流的事件进行字段补充时，每次查找配置表会导致性能很低，可以把配置表转换成配置流，事件流和配置流进行连接，然后在状态中维护配置表即可(可以是广播状态也可以是键值分区状态,ps:由于流连接时,两个流的事件顺序不定，为了保证都能找到配置值，可以在open函数中初始化一个配置表的实例变量)

正作用：减少端到端的时延，并且使用flink的状态来存放配置信息，提高了吞吐量
反作用： 无