从一例状态引发的性能问题谈Flink状态序列化

前言

好久不见（鞠躬最近处在转型期，每天忙到飞起，关注具体技术细节的精力自然就比较少了（上一篇许下的周更承诺也食言了 = =）。上周帮助他人快速解决了一个因误用Flink状态类型引发的性能问题，在这里做个quick notes，并简要介绍一下Flink状态序列化方面的基础知识。

问题及排查

上游部门同事反馈，一个计算逻辑并不复杂的多流join DataStream API作业频繁发生消费积压、checkpoint失败（现场截图已丢失）。作业拓扑如下图所示。

为了脱敏所以缩得很小 = =

按大状态作业的pattern对集群参数进行调优，未果。

通过Flink Web UI定位到问题点位于拓扑中倒数第二个算子，部分sub-task checkpoint总是过不去。观察Metrics面板，发现有少量数据倾斜，而上下游反压度量值全部为0。

经过持续观察，存在倾斜的sub-task数据量最多只比其他sub-task多出10%~15%，按照常理不应引起如此严重的性能问题。遂找到对应的TaskManager pod打印火焰图，结果如下。

可见RocksDB状态读写的耗时极长，大部分时间花在了Kryo序列化上，说明状态内存储了Flink序列化框架原生不支持的对象。直接让相关研发同学show me the code，真相大白：

private transient MapState<String, HashSet<String>> state1;
private transient MapState<String, HashSet<String>> state2;
private transient ValueState<Map<String, String>> state3;

Flink序列化框架内并没有针对HashSet的序列化器，自然会fallback到Kryo。即使这些Set并不算大，状态操作的开销也会急剧上升。当然，ValueState<Map<String, String>>用法也是错误的，应改成MapState<String, String>。

最快的临时解决方法很简单：把所有状态内用到的HashSet全部改成Map<String, Boolean>，同样可以去重。虽然并不优雅，但因为有了原生MapSerializer支持，效率大幅提升。下面简要介绍Flink的状态序列化。

TypeSerializer

在我们创建状态句柄所需的描述符StateDescriptor时，要指定状态数据的类型，如：

ValueStateDescriptor<Integer> stateDesc = new ValueStateDescriptor<>("myState", Integer.class);
ValueState<Integer> state = this.getRuntimeContext().getState(stateDesc);

与此同时，也就指定了对应数据类型的Serializer。我们知道，TypeSerializer是Flink Runtime序列化机制的底层抽象，状态数据的序列化也不例外。以处理Map类型的MapSerializer为例，代码如下，比较清晰。

@Internal
public final class MapSerializer<K, V> extends TypeSerializer<Map<K, V>> {

    private static final long serialVersionUID = -6885593032367050078L;

    /** The serializer for the keys in the map */
    private final TypeSerializer<K>