背景
flink的状态序列化器不仅仅用于检查点的数据传输序列化,而且还用于TaskManager进程间的网络传输,最主要是flink的状态序列化器非常容易引起混淆,我们经常区分不出所谓的自定义状态序列化器是给一个全新类型定义一个完全的序列化程序还是在kryo序列化支持的基础上,新增能让kryo序列化器识别的某种类型的序列化实现
flink自定义状态序列化器TypeSerializer
1.int/long等基础类型的序列化器,比如IntSerializer/LongSerializer等,他们不仅仅包含了如何序列化和反序列化基础的数据类型,还包括了IntSerializerSnapshot、LongSerializerSnapshot等表明如何从旧的检查点恢复数据的实现类
2.MapSerializer/ListSerializer等集合结构的序列化器类,同理,他们同样包含了MapSerializerSnapshot、ListSerializerSnapshot等表明是否支持从旧的检查点恢复数据的实现类
3.Tuple{1-25}支持可变长度字段的元祖类型TupleSerializer
4.PojoSerializer这是一个支持Java Bean的序列化需求的类,这个类性能上比前一个TupleSerializer低,因为POJO需要用到反射,而Tuple直接通过字段名称即可访问
5.Generic types: 注意这种类型flink是没有提供序列化器的实现的,比如RoaringBitmap类,这些类型flink是不认识的,所以flink会把他统一交由kryo去处理
总结:
实现自己的序列化器需要如下所示实现TypeSerializer接口:
public class CustomTypeSerializer extends TypeSerializer<Tuple2<String, Integer>> {...};
ListStateDescriptor<Tuple2<String, Integer>> descriptor =
new ListStateDescriptor<>(
"state-name",
new CustomTypeSerializer());
checkpointedState = getRuntimeContext().getListState(descriptor);
实现这个接口不仅仅只是实现Serializer/DeSerializer方法,他还要实现对应的SerializerSnapShot类,SerializerSnapShot类的实现是为了表明是否兼容旧的检查点,如果支持,如何从旧的检查点恢复数据等.