Flink 大状态存储 & 状态TTL

什么是Flink大状态存储？

举个栗子。现有用户访问流数据，需统计每个用户PV，用户量级为3亿。如何计算？

假定每个用户ID为50字节。那么3亿用户ID的存储需要：50 b * 3 亿 ≈ 13 G ，那么可以直接存在job内存中，如果担心job重启，内存数据丢失，可以放在redis中，或者Aerospike（一种用磁盘的kv存储）。

那如果状态再大一些呢？再举个栗子：某广告场景下，点击数据需要根据请求ID 到 请求日志中取相关维度信息。假设请求发生后，24小时之内，都有可能发生点击，那么就需要将请求日志保存24小时。

假定每条请求日志500字节，每天请求量20亿，那么请求日志保存24小时需要：500 b * 20亿 ≈ 931 G，那么此时如果hash之后存redis，代价就比较大了，怎么办呢？存磁盘吧！

 

RocksDB就是以磁盘为存储的KV存储引擎，Flink也支持以RocksDB作为状态存储。

 

那么Flink用RocksDB做状态存储需要注意什么问题那？

1、与RocksDB读写的延迟是否能满足？

众所周知（那你要是不知道就去问山聚聚，山聚聚啥都懂）RocksDB采用LSM的写入方式，因此顺序写磁盘的速度还是非常快的，随机读也能在毫秒级别，而且Flink是与本地磁盘做交互，少了一层网络传输的消耗，在读放大不严重的情况下，随机读的性能也还不错。

 

2、数据的清理方式？

众所周知（同上）RocksDB的数据删除是标记删除，已经落到磁盘中的数据会等待compaction时清除。

数据的清理分为两种方式：主动删除和过期清理。

上述场景使用哪种方式会比较好呢？

对于想要及时清理过期的key来说，可以通过TimerServer回调的方式去主动删除，但是不适用于大数据量的情况，为什么呢？因为频繁的回调很浪费cpu，24小时后相当于数据量翻倍（一遍处理新来的数据，一遍回调清理24小时之前的数据）。（PS：Flink 的 TimerServer也是保存在State中的）

主动调用指定Key的删除，需要保存24小时内所有的key，然后遍历顺序删除，可以挑选夜间一个时间，触发range清理操作。但这种做法显然也不太方便。

那么来看下TTL过期清理了。

Flink的TTL清理方式简单介绍下：