从udaf谈flink的state

1.前言

  本文主要基于实践过程中遇到的一系列问题,来详细说明Flink的状态后端是什么样的执行机制,以理解自定义函数应该怎么写比较合理,避免踩坑。

  内容是基于Flink SQL的使用,主要说明自定义聚合函数的一些性能问题,状态后端是rocksdb。

2.Flink State

  https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/stream/state/state.html

  上面是官方文档,这里按照个人思路快速理解一下重要内容:

    在Flink中,最底层的接口是Function, 往上就是Stateful Function。函数的具体实现可以理解为operator,分为Keyed Operator和一般的Operator,简单理解就是实时流数据需不需要分组处理。

    正是因为有了两大类算子,所以状态也分成了Keyed State和Operator State。State是什么?个人理解就是一个临时存储的数据集,至于为什么需要临时存储很好理解:通常我们都需要实时统计一些结果,但是数据流是一条条处理的,必须保存中间状态。比如sum函数,要从state中get之前的结果,加上本次的结果,再put到state中。又比如join操作,需要尝试获取join对象存不存在,保存自己的本次对象,便于其他数据进行join。

    通过上面描述,可以看出一般聚合等涉及到多条数据的操作,都是需要保存状态的,否则一条条记录处理(比如提取某个字段的值),前后没有关联,自然不需要状态了,前者就是Keyed State。那Operator State为什么存在?实际使用中,该状态主要是用于保存source的消费位点,以便failover重新启动的时候能够找到正确的消费位置,这是Flink的一致性很重要的地方。

    临时的数据集临时的原因在于:流是没有边界的,数据会不断增大,不说内存,哪怕是磁盘容量,以及checkpoint操作性能问题,也无法做到无限状态。所以每个state都需要设置ttl时间,判断这个临时的数据需要保存多久。比如你要统计每天的数据,那可能要保存24个小时以上,A数据0点出现一次,24点出现一次,保存的时间小于ttl,第一次的数据就会被清除,导致最后结果错误,24小时以上需要考虑数据延迟到达的问题。

    被管理的状态有以下几种:ValueState,ListState,ReducingState,AggregatingState,FoldingState(废弃),MapState。

    Flink目前提供了3种状态后端:Memory, Fs,Rocksdb。这些状态后端必须实现上面所管理的状态,所以新增状态后端的时候一样需要。

3.udaf与Flink序列化

  Flink允许用户编写UDAF自定义聚合函数来满足特殊的计算需求,这里就会存在一个令人疑惑的问题:用户的代码是无法控制的,那异常重启的时候怎么恢复用户代码的数据呢?其实很简单,将用户的代码生成对象,在checkpoint的时候一并序列化保存就好了。等到异常重启的时候,反序列化就可以了。下面谈谈flink是如何序列化对象的。

3.1 Flink的类型与序列化

  https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/types_serialization.html

  你可以在flink-core包中org.apache.flink.api.java.typeutils, org.apache.flink.api.common.typeutils中找到大量与之相关的内容

  Flink实现了:

    1.所有的java基础类型,包括封装类型,以及Void,String,Date,BigDecimal,BigInteger, org.apache.flink.api.common.typeutils

    2.基本类型数组,及对象数组 org.apache.flink.api.common.typeutils

    3.组合类型:Tuple, Row, Pojo, Scala。实现都在org.apache.flink.api.java.typeutils

    4.辅助类型:List, Map等

    5.一般类型:这些不会被Flink序列化,而是被Kryo。 所以不被flink识别的Class,以及没有自定义序列化器可以匹配的时候,都会使用Kryo进行序列化。但是牢记,Kryo不是万能的,所以最好自己定义。

  如果你不想用kryo序列化,希望程序抛出异常,以便确定自定义序列化是否缺失,可以禁用kryo:  env.getConfig().disableGenericTypes();

3.2 用户自定义状态序列化

  https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/stream/state/custom_serialization.html

  导读中也说明了,如果使用的是Flink自己的序列化器,本节可以忽略掉,故不作更多说明。

4. rocksdb状态后端问题

  通过上面的介绍,可以明白自定义的函数对象都是需要序列化和反序列化的,这样确保了异常重启后状态可以恢复。但是实际上不同的状态后端处理方式是不一样的,这也是本文想说明的内容。

  上面提到flink提供了三种状态后端,分别是基于内存,文件和rocksdb,但只有rocksdb支持增量式存储。这其中是有什么不同之处呢?本文不讨论rocksdb如何实现增量的,主要集中在rocksdb状态后端相比于FsStateBackend有什么区别,会引发什么问题。

  FsStateBackend是基于文件、全量存储的,简单猜测一下就可以知道其所有数据都在内存中,等到checkpoint的时候全量序列化写入文件。实际上也确实如此:createKeyedStateBackend创建的是HeapKeyedStateBackend,对应的都是HeapListState, HeapValueState等等内容,和MemoryStateBackend没什么区别。以HeapValueState为例,其value和update方法没有进行多余的操作,只是简单的从statTable中获取和放回。

  RocksDBStateBackend可以用相同的逻辑查看,其用的是完全不同的体系:RocksDBKeyedStateBackend,RocksDBValueState,RocksDBListState等。以RocksDBValueState为例,它用来存储的并不是stateTable,而是rocksdb对象,每次获取都需要从rocksdb读取,然后反序列化成相应的对象,更新都需要序列化,然后更新rocksdb里面的内容。

  通过上面的描述就会发现问题,rocksdb的状态每次使用都需要序列化和反序列化,如果对象状态太大,必然会带来性能问题。

4.1 udaf运行过程

  我们都知道udaf都有一个accumulator,这个肯定是需要被Flink管理的,那么具体是如何做到的呢?通过程序断点可以看见执行过程:

    1.自定义的聚合函数都被封装成了:GroupAggProcessFunction,执行processElement。

      可以看见里面的调用逻辑,首先注册状态清除定时器,然后state.value()获取当前的accumulator,没有就会调用function的createAccumulators方法初始化。

      然后调用accumulate方法计算,获取计算结果,后面就是更新accumulator和其他数据,输出本次计算结果了。

    2.state.value()执行的是ValueState,这个取决于所使用的状态后端,这里探讨的就是RocksDBValueState。

      其从rocksdb中获取序列化后的字符串,然后将其反序列化。这个就是问题所在。

  通过上述过程我们发现,使用rocksdb状态后端的时候,执行每一条数据,其对象都是需要序列化和反序列化的,而FsStateBackend使用的是内存,不会做额外操作。

  如果聚合函数状态对象过大,这个地方就可能成为性能瓶颈。

4.2 distinct

  按照上述描述distinct去重函数也应该会是一个大对象,需要收集所有数据才对,实际使用过程中并没有感知到很慢,这是怎么做到的呢?

  这里要介绍一个重点内容:MapView。Flink操作distinct是通过类DistinctAccumulator完成的,其内部使用的是MapView。

  可以发现,MapView会被翻译成RocksDBMapState,accumulator序列化的时候会忽略掉这个字段,使用的时候都是操作的RocksDBMapState,对单条数据进行操作。

  所以聚合函数对象不要使用大对象,尽量拆分成小对象,充分利用前面提到的ListState,MapState操作,否则在rocksdb做状态后端时会引发性能问题。

  AggregationCodeGenerator这个就是用来包装聚合相关代码的了,其中有个函数addAccumulatorDataViews()会将MapView替换成StateMapView。

    // create DataViews
      val descFieldTerm = s"${dataViewFieldTerm}_desc"
      val descClassQualifier = classOf[StateDescriptor[_, _]].getCanonicalName
      val descDeserializeCode =
        s"""
           |    $descClassQualifier $descFieldTerm = ($descClassQualifier)
           |      ${classOf[EncodingUtils].getCanonicalName}.decodeStringToObject(
           |        "$serializedData",
           |        $descClassQualifier.class,
           |        $contextTerm.getUserCodeClassLoader());
           |""".stripMargin
      val createDataView = if (dataViewField.getType == classOf[MapView[_, _]]) {
        s"""
           |    $descDeserializeCode
           |    $dataViewFieldTerm = new ${classOf[StateMapView[_, _]].getCanonicalName}(
           |      $contextTerm.getMapState(
           |        (${classOf[MapStateDescriptor[_, _]].getCanonicalName}) $descFieldTerm));
           |""".stripMargin
      } else if (dataViewField.getType == classOf[ListView[_]]) {
        s"""
           |    $descDeserializeCode
           |    $dataViewFieldTerm = new ${classOf[StateListView[_]].getCanonicalName}(
           |      $contextTerm.getListState(
           |        (${classOf[ListStateDescriptor[_]].getCanonicalName}) $descFieldTerm));
           |""".stripMargin
      } else {
        throw new CodeGenException(s"Unsupported dataview type: $dataViewTypeTerm")
      }
      reusableOpenStatements.add(createDataView)

  这就是一个基本过程。

5. 尴尬的选择 BloomFilter

  这是本人所遇到的一个问题:

    面对大量数据的去重操作,有时候我们并不需要过于精准,如果去重内容是整型,可以使用bitmap进行精确去重

    但是很多时候数据都是字符串,比如设备号,如果像Kylin一样存在类似Global dictionary,可以为设备号生成一一映射的整型id,使用精确去重,但大多数情况下,我们只能选择bloomFilter或者hyperloglog。

    这里仅对bloomFilter进行讨论,因为hyperloglog的使用的内存太少了,状态后端FsStateBackend足够了。

  BloomFilter不一样,单个BloomFilter也可能达到500MB,如果有几千个组的group by计算不同页面,坑位的数据,如果使用FsStateBackend是无法接受的。

  我看到网上大部分使用BloomFilter都是使用ValueState,像我所说的,如果只有十几个组的,内存消耗也不过几个G,FsStateBackend足够胜任,但是几千个就不太适合了。

  此处说明一些坑点,以及尴尬之处:

    1.Guava提供的BloomFilter使用rocksdb时有严重的性能问题,可能需要自定义序列化方式,没有测试过,改为Stream-lib提供的

    2.像上述描述的,BloomFilter其实是一个大状态,每次序列化全量是无法接受的。bloom filter本质上是一个Long[],由于ListState不能通过下标来获取对应的对象,所以使用MapState,键是index,值是对应的Long。

    3.根据bloom原理,需要多次hash,导致读写放大了N倍,任务运行到后面越来越慢

    4.改成FsStateBackend性能暴增,问题是checkpoint慢,内存消耗大,原本目的就是解决内存消耗问题,采取rocksdb的增量保存,使用FsStateBackend返回回到了起点。

  通过上述描述:可以明白如果使用FsStateBackend,性能确实没问题,但是是全量内存使用,还是那个问题,几千个group,内存消耗还是过大。如果使用Rocksdb,会发现读写放大,memTable命中率不高,性能越往后越差。

  上述已经尝试将大对象改成Map,减少全量序列化,性能比未改之前提升几十倍以上,但是还是很慢。直接原因就是多次hash对比DistinctAccumulator造成读写放大,实际上性能也是其的1/5不到。如果使用BloomFilter的FsStateBackend比Rocksdb下distinct耗费的内存更多(前提是distinct满足性能要求),那得不偿失,这就是目前我面临的问题。最后,如果存在混合使用的场景(部分字段需要精确去重),使用FsStateBackend就更尴尬了,这导致distinct的也是全量在内存之中,这也是我没有使用hyperloglog的原因之一,其在rocksdb状态下性能也很差(也许我应该自己开发hyperloglog的flink实现 -。-  暂未尝试,先解决bloomFilter的问题)。

  后续优化测试中的内容:

    1.stream-lib的bloom过滤器是可以merge的,只要hashcount相同。实验可以发现,初始化元素个数10w-3000w错误率0.01得到的hashCount都是5,但是表现不同。10w个使用了更少的容量,数据标记位更集中。

      考虑到数据分布的不均衡,可以对其做动态的扩容,而不是每个group都使用最大值的那个,这样可以再提升一波性能。但是存在的问题是由于容量发生了改变,旧有的数据位置出现了变动,更容易发生误判,需要权衡。

    2.对rocksdb的参数调优

    https://issues.apache.org/jira/browse/FLINK-10993 社区也讨论过,不知道为什么后面就凉了。

  另外,针对上面的这种场景,是否有更好的解决方法,请留言给我。

6.总结

  如何写好一个udaf?

    1.定义的accumulator尽量小,否则在rocksdb情况下每次序列化会消耗大量时间

    2.需要明确自定义的accumulator使用的序列化规则,否则默认会使用kryo,而kryo不是万能的,在某些情况性能极差,当然大部分情况还是可以的。所以观察到性能瓶颈的时候,考虑这个地方。

    3.accumulator无法变小,考虑使用MapView最终生成的MapState尽量减少序列化的内容

    4.FsStateBackend和RocksdbBackend在某些情况下很尴尬,互有不足,需要权衡,或者自己开发一个适应场景的高效工具

    5.上面内容都是基于1.8版本的,之前之后的版本有什么坑不在讨论范畴,本文仅提供思路,需要具体问题具体分析  

你可能感兴趣的:(从udaf谈flink的state)