这次来介绍一下fevernova的state功能,与flink的state功能很类似,

flink的state是保证恰好一次计算的核心点,当然至少一次也需要state。

fevernova的state用途

之前fevernova都是作为数据传输框架,对state的依赖并不高。

需要state用来存储kafka的offset,或者binlog的filename和position。

在实现kafka To HDFS模块的时候,也会将关闭的文件列表和commit保存在state里,

减少重复文件的产生,实现恰好一次。类似于flink的rollingfilesink。

state保存的位置

因为只保存少量的meta信息,所以state就简单的保存在文件系统里。

如果需要提高可用性,就通过类似Nas的方式进行目录挂载。这类方案都是非常成熟的。

计算状态

在无意中,发现了一个开源项目OpenHFT

其中的项目质量还是比较高的,利用其中的序列化、持久化的库进行state的保存非常方便。

让内存中保存状态的对象实现WriteBytesMarshallable和ReadBytesMarshallable接口,

根据需求自定义序列化和反序列化的方法,就可以完成state的读写操作。

简单测试了一下性能还是非常好的。fevernova中的exchange模块中有具体的使用。

去重

单纯依靠Chandy-Lamport算法实现的流计算框架并不能在实际需求中完全实现恰好一次计算。

比如写入kafka的数据有重复,通常就在计算逻辑中去重,这也意味着更多的cpu和内存开销。

fevernova在exchange模块中实现了一个基于Roaringbitmap的滑窗过滤器,通过统一的去重。

压缩的位图信息也会随着state进行保存,重启时可以完美衔接。