Flink Keyed State的优化与实践
💡
原文中文，约4600字，阅读约需11分钟。
📝
内容提要
Flink SQL在双流join场景中，当State的存储达到TB级别后，会发现State的scan/next/readNull请求RT会变得较高。通过使用RocksDB的BlobDB方案，可以大大降低IO和CPU毛刺。经过适配并在大State中开启KV分离后，观察RocksDB日志发现SST的文件大小急剧下降，State Key也全聚集在了L0和L1这两层中。最后的效果是ReadNull耗时全降到了百微妙左右，scan和next的RT 99线也降到了1毫秒左右。
🎯
关键要点
- Flink SQL在双流join场景中，State存储达到TB级别后，scan/next/readNull请求RT变高。
- 使用RocksDB的BlobDB方案可以降低IO和CPU毛刺。
- 双流Join分为Regular Join和Interval Join，后者的State Key较小但Value较大。
- 双流Join Operator使用MapState结构，Key为时间戳，Value为RowData记录，导致写入RocksDB的List序列化结果较长。
- RocksDB的compaction导致读RT高，特别是ReadNull请求。
- State中的Value过大导致SST层级增多，影响读性能。
- RocksDB的BlobDB方案通过KV分离降低SST文件大小和层级。
- 开启KV分离后，ReadNull耗时降至百微秒，scan和next的RT降至1毫秒。
- 开启KV分离的任务CPU毛刺降低50%，但仍存在少量高峰现象。
- 未来优化方向包括升级RocksDB版本、降低compaction速率和默认开启KV分离。
➡️
