Flink Keyed State的优化与实践
Source :
mp.weixin.qq.com
Author :
张陈毅&张杨
Flink SQL在业务使用中有较多的双流join场景，当左右流的流量都较大，Join的等待时间即使为1小时，Flink Keyed State（Flink State分Operator State和Keyed State，后文所有State均代表后者）的存储大小也很容易达到TB级（内部默认使用的是RocksDBStateBackend）。 在State我们内部[1]之前就做了RT和长度的metric，当State的存储达到TB级别后，会发现State的scan/next/readNull请求RT会变得较高，另外双流Join不仅流量大，Join query的字段也较多，导致State的Value长度也较大，从而使得任务在流量高峰期CPU存在明显的周期性毛刺，根因是RocksDB的compaction引发。我们下面的内容主要是从业务场景跟进到RocksDB的读写行为，来优化RT耗时高的问题，并使用优化方案缓解compaction的压力。
