Flink 内核原理与实现-状态原理

可以关注下公众号,专注数据开发、数据架构之路,热衷于分享技术干货。 

前言

        状态在Flink中叫作State,用来保存中间计算结果或者缓存数据。根据是否需要保存中间结果,分为无状态计算和有状态计算。对于流计算而言,时间持续不断地产生,如果每次计算都是相互独立的,不依赖于上下游的事件,则是无状态计算。如果计算需要依赖于之前或者后续的事件,则是有状态计算。State是实现有状态计算的下的Exactly-Once的基础。

        State的典型实例如:Sum求和、去重、模式检测CEP。

        需要做好State管理,需要考虑:

        1、状态数据的存储的和访问

        2、状态数据的备份和恢复

        3、状态数据的划分和动态扩容

        4、状态数据的清理

一、状态类型

按照数据结构的不同,Flink中定义了多种State,应用于不同的场景。如下:

1、ValueState

      类型为T的单值状态。这个状态与对应的Key绑定,是最简单的状态。可以通过update方法更新状态值,通过value()方法获取状态值。

2、ListState

      Key上的状态值为一个列表。可以通过add方法往列表中附加值,也可以通过get()方法返回一个Iterable来遍历状态值。

3、ReducingState

      这种状态通过用户传入的reduceFunction,每次调用add方法添加值时,会调用reduceFunction,最后合并到一个单一的状态值。

4、AggregatingState

       聚合State,和ReducingState不同的是,这里聚合的类型可以是不同元素的元素类型,使用add(IN)来加入元素,并使用AggregateFunction函数计算聚合结果。

5、MapState

        使用Map存储Key-Value对,通过put(UK,UV)或者putAll(Map)来添加,使用get(UK)来获取。

6、FoldingState

        跟ReducingState有点类似,不过它的状态值类型可以与add方法中传入的元素类型不同。已被标位废弃,不建议使用。

二、KeyedState 与 OperatorState

2.1 KeyedState

在KeyedStream中使用。状态是跟特定的Key绑定的,即KeyedStream流上的每一个Key对应一个State对象。KeyedState可以使用所有的State。KeyedState保存在StateBackend中。

import org.apache.flink.api.common.functions.RichFlatMapFunction
import org.apache.flink.api.common.state.{ValueState, ValueStateDescriptor}
import org.apache.flink.api.common.typeinfo.{TypeHint, TypeInformation}
import org.apache.flink.streaming.api.scala.StreamExecutionEnvironment
import org.apache.flink.api.scala._
import org.apache.flink.configuration.Configuration
import org.apache.flink.util.Collector


object KeyedStateDemo {

  class CountWindowAverage extends RichFlatMapFunction[(Long, Long), (Long, Long)] {
    @transient var sum: ValueState[(Long, Long)] = _

    override def open(parameters: Configuration): Unit = {
      /**
       * average: state名字,在获取State的时候使用
       * TypeInformation.of(new TypeHint[Long, Long] {}) State中数据类型的描述,用来做序列化和反序列化。
       * 之前文中提过 hint 用来在类型擦除的情况下来获取泛型信息的。
       */
      val descriptor = new ValueStateDescriptor("average", TypeInformation.of(new TypeHint[(Long, Long)] {}))
      sum = getRuntimeContext.getState(descriptor)
    }

    override def flatMap(value: (Long, Long), out: Collector[(Long, Long)]): Unit = {
      //保存之前的数据和
      val tmpCurrentSum = sum.value()
      //若之前有数据,则置当前数据和位之前的数据和,否则置总和为0
      val currentSum: (Long, Long) = if (tmpCurrentSum != null) {
        tmpCurrentSum
      } else {
        (0L, 0L)
      }
      val newSum = (currentSum._1, currentSum._2 + value._2)
      sum.update(newSum)
      if (newSum._2 % 2 == 0){
        out.collect(value._1,newSum._2)
      }

    }

  }

  def main(args: Array[String]): Unit = {
    val env = StreamExecutionEnvironment.getExecutionEnvironment

    env.fromElements((1L, 1L), (2L, 1L), (1L, 2L), (2L, 22L), (1L, 3L))
      .keyBy(0)
      .flatMap(new CountWindowAverage)
      .print()

    env.execute(s"${this.getClass.getSimpleName}")

  }
}

2.2 算子状态OperatorState

        与KeyedState不同,OperatorState跟一个特定算子的一个实例绑定,整个算子只对应一个State。相比较而言,在一个算子上,可能会有很多个Key,从而对应多个KeyState。

        Operator 目前支持:

        列表状态(List state):将状态表示为一组数据的列表。

        联合列表状态(Union list state):也将状态表示为数据的列表。它与常规列表状态的区别在于,在发生故障时,或者从保存点(savepoint)启动应用程序时如何恢复。

        广播状态(Broadcast state):如果一个算子有多项任务,而它的每项任务状态又都相同,那么这种特殊情况最适合应用于广播状态。

        代码百度吧,太多了。官方Sink案例!!!!原谅我~~~(*^▽^*)

2.3 原始和托管状态

        按照由Flink管理还是用户自行管理,状态可以分为原始状态(Raw State)和托管状态(Managed State)。

        原始状态,即用户自定义的State,Flink在做快照的时候,把整个State当做一个整体,需要开发者自己管理,使用byte数组来读写状态内容。

        托管状态是由Flink框架管理的State,如ValueState,ListState,MapState等,其序列化与反序列化由Flink框架提供支持,无序用户感知,干预。

        KeyedState和OperatorState可以是原始状态,可以是托管状态。

        通常在DataStream上的状态推荐使用托管状态,一般情况下,在实现自定义算子时,才会用到原始状态。

三、状态描述

        State既然是暴露给用户的,那么就有一些属性需要指定,如State名称、State中类型信息和序列化/反序列化器、State的偶其实就等。在对应的状态后端(StateBackend)中,会调用对应的create方法获取到StateDescriptor中的值。在Flink中状态描述叫作StateDescriptor。

Flink 内核原理与实现-状态原理_第1张图片

        对应于每一类State,Flink内部都设计了对应的StateDescriptor,在任何使用State的地方,都需要通过StateDescriptor描述状态的信息。

        运行时,在RichFunction和ProcessFunction中,通过RuntimeContext上下文对象,使用StateDescriptor从状态后端(StateBackend)中获取实际的State实例,然后在开发者编写的UDF中就可以使用这个State了。StateBackend中有对应则返回现有的State,没有则创建新的State。

 Flink 内核原理与实现-状态原理_第2张图片

3.1 广播状态 

        广播状态在Flink中叫做BroadcastState,在广播状态模式中使用。所谓广播状态模式,就是来自一个流的数据需要被广播到所有下游任务,在算子本地存储,在处理另一个流的时候依赖于广播的数据。广播State的类型必须是MapState类型。

        用途:根据规则处理业务流数据。(避免实时性下降,规则更新不及时等情况发生。)

3.2 状态接口

1、面向应用开发者的State接口

只提供了对State中数据的添加、更新、删除等基本操作,用户无法访问状态的其他运行时所需要的的信息。

Flink 内核原理与实现-状态原理_第3张图片

以MapState为例,提供了添加、获取、删除、遍历的API接口 Flink 内核原理与实现-状态原理_第4张图片

2、内部State接口

 内部State接口是给Flink框架使用的,除了对State中数据的访问之外,还提供了内部的运行时信息接口,如State中数据的序列化器、命名空间(namespace)、命名空间的序列化器、命名空间合并的接口。

内部State接口的命名方式为InternalxxxState,内部State接口的体系非常复杂。下面以InternalMapState介绍。

Flink 内核原理与实现-状态原理_第5张图片

InterMapState集成了面向应用开发者的State接口,也继承了InternalKvState接口,既能访问MapState中保存的数据,也能访问MapState运行时的信息。 

Flink 内核原理与实现-状态原理_第6张图片

3、状态访问接口

 有了状态之后,在开发者自定义的UDF中如何访问状态?

OperatorStateStore:数据以Map形式保存在内存中,并没有使用RocksDBStateBackend和HeapKeyedStateBackend。

KeyedStateStore:使用RocksDBStateBackend或者HeapKeyedStateBackend来保存数据,KeyedStateStore中获取/创建状态都交给了具体的StateBackend来处理,KeyedStateStore本身更像是一个代理。

4、状态存储

Flink中无论是哪种类的State,都需要被持久化到可靠存储中,才具备应用级的容错能力,State的存储在Flink中叫做StateBackend。

Flink内置了3种StateBackend。

  • 纯内存:MemoryStateBackend,适用于验证、测试,不推荐生产环境。

        运行时所需要的State数据保存在TaskManagerJVM堆上内存中,KV类型的State、窗口算子的State使用HashTable来保存数据、触发器等。执行检查点的时候,会把State的快照数据保存到JobManager进程的内存中。MemoryStateBackend可以使用异步的方式进行快照,也可以使用同步的方式。推荐使用异步,避免阻塞算子处理数据。

注意点:

1)State存储在JobManager内存中,受限于JobManager的内存大小。

2)每个State默认5MB,可通过MemoryStateBackend构造函数调整。

3)每个State不能超过Akka Frame大小。

  • 内存+文件:FsStateBackend,适用于长周期大规模的数据。

        运行时所需要的的State数据存在TaskManger的内存中,执行检查点的时候,会把State的亏按照保存到配制文件系统中,可以使用分布式文件系统或本地文件系统。

适用场景:

1)适用于处理大状态、长窗口,或者大键值状态的有状态处理任务。

2)FsStateBackend非常适用于高可用方案。

注意点:

1)State数据首先会被存在TaskManager的内存中。

2)State大小不能超过TM内存。

3)TM异步将State数据写入外部存储。

在运行时,MemoryStateBackend和FsStateBackend本地的State都保存在TaskManager的内存中,所以其底层都依赖于HeapKeyStateBackend。HeapKeyStateBackend面向Flink引擎内部,使用者无感。

  • RocksDB:RocksDBStateBackend,适用于长周期大规模的数据。

        适用嵌入式的本地数据库RocksDB将流计算数据状态存储在本地磁盘中,不会受限于TaskManager的内存大小,在执行检查点时,再将整个RocksDB中保存的State数据全量或者增量持久化到配置的文件系统中,在JobManager内存中会存储少量的检查点元数据。

缺点:访问State的成本对比于基于内存的StateBackend 会高很多,可能导致数据流的吞吐量剧烈下降。

适用场景:

1)最适合用于处理大状态、长窗口,或大键值状态的有状态任务处理。

2)RocksDBStateBackend非常适用于高可用方案。

3)RocksDBStateBackend是目前唯一支持增量检查点的后端。增量检查点非常适用于超大状态的场景。

注意点:

1)总State大小仅限于磁盘大小,不受内存限制。

2)RocksDBStateBackend也㤇配置外部文件系统,集中保存State。

3)RocksDB的JNI API基于byte数组,单key和单value的大小不能超过2^31 字节。

4)对于使用具有合并操作状态的程序,如ListState,随着时间累计超过2^31字节大小,将会导致接下来的查询中失败。

5、持久化策略

  • 全量持久化策略

        每次把全量State写入状态存储中。内存型、文件型、RocksDB类型的StateBackend都支持全量持久化策略。

        在执行持久化策略的时候,使用异步机制,每个算子启动1个独立的线程,将自身的状态写入分布式存储中。在做持久化的过程中,状态可能会被持续修改,基于内存的状态后端使用CopyOnWriteStateTable来保证线程安全,RocksDBStateBackend则使用RockDB的快照机制保证线程安全。

  • 增量持久化策略

        每次持久化增量的State,只有RocksDBStateBackend支持增量持久化。

        RocksDB是一个基于LSM-TREE的kv存储,新的数据保存在内存中,成为memtable。如果Key相同,后到的数据将覆盖之前的数据,一旦memtable写满了,RocksDB就会将数据压缩并写入到磁盘。memtable的数据持久化到磁盘后,就变成了不可变的sstable。

        因为sstable是不可变的,Flink对比前一个检查点创建和删除的RocksDB sstable文件就可以计算出状态有哪些改变。为了确保sstable是不可变的,Flink会在RocksDB上触发刷新操作,强刷memtable到磁盘。在执行检查点时,会将新的sstable持久化到存储中(如HDFS等),同时保留引用。这个过程中 Flink并不会持久化本地所有的sstable,因为本地的一部分历史sstable在之前的检查点就已经持久化到存储中可。只需要增加对sstable文件的引用次数就可以。

        RocksDB会在后台合并sstable并删除重复的数据。然后在RocksDB删除原来是sstable,替换成新合成的sstable,新的sstable包含了被删除的sstable中的信息。通过合并,历史的sstable会合并成一个新的sstable,并删除这些历史的sstable,可以减少检查点的历史文件,避免大量小文件产生。

6、状态重分布

  • OperatorState重分布

        1、ListState

        并行度在改变的时候,会将并发上的每个List都取出,然后把这些List合并到一个新的List,根据元素的个数均匀分配给新的Task

        2、UnionListState

        比ListState更灵活,把划分的方式交给用户去做,当改变并发的时候,会将原来的List拼接起来,然后不做划分,直接交给用户。

        3、BroadcastState

        操作BroadcastState要保证不可变性,所以各个算子的同一个BroadcastState完全一样。改变并发的时候,把这些数据分发打新的Task即可。

  • KeyedState重分布

        基于Key-Group,每个Key隶属于唯一的一个Key-Group。Key-Group分配给Task实例,每个Task至少有一个Key-Group.

        Key-Group数量取决于最大并行度(MaxParallism)。KeyedStream并发的上线是Key-Group的数量,等于最大并行度。

7、状态过期

  • DataStream中状态过期

        过期时间:超过多长时间未访问,视为State过期,类似于缓存。

        过期时间更新策略:创建和写时更新、读取和写时更新。

        State的可见性:未清理可用,超期则不可用。

import org.apache.flink.api.common.state.StateTtlConfig;
import org.apache.flink.api.common.state.ValueStateDescriptor;
import org.apache.flink.api.common.time.Time;

StateTtlConfig ttlConfig = StateTtlConfig
    .newBuilder(Time.seconds(1))
    .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite)
    .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired)
    .build();
    
ValueStateDescriptor stateDescriptor = new ValueStateDescriptor<>("text state", String.class);
stateDescriptor.enableTimeToLive(ttlConfig);
  • Time.seconds(1) 周期过期时间

  • setUpdateType 更新类型

  • setStateVisibility 是否在访问state的时候返回过期值

setUpdateType:

  • StateTtlConfig.UpdateType.OnCreateAndWrite - 只在创建和写的时候清除 (默认)

  • StateTtlConfig.UpdateType.OnReadAndWrite - 在读和写的时候清除

setStateVisibility:

  • StateTtlConfig.StateVisibility.NeverReturnExpired - 从不返回过期值

  • StateTtlConfig.StateVisibility.ReturnExpiredIfNotCleanedUp - 如果仍然可用,则返回

在 NeverReturnExpired 的情况下,过期状态的就好像它不再存在一样,即使它未被删除。这个选项对于 TTL 之后之前的数据数据不可用。

另一个选项 ReturnExpiredIfNotCleanedUp 允许在清理之前返回数据,也就是说他ttl过期了,数据还没有被删除的时候,仍然可以访问。

  • FlinkSQL 中状态过期
  @Test(expected = classOf[IllegalArgumentException])
  def testMinBiggerThanMax(): Unit = {
    //设置过期时间 min =12 小时,max = 24小时
    new StreamQueryConfig().withIdleStateRetentionTime(Time.hours(12), Time.hours(24))
  }

   8、状态过期清理

  • 调用ValueState#value()  只有明确读出过期值时才会删除过期值。
  • 调用cleanupFullSnapshot() 做完整快照时清理后,在获取完整状态时激活清理。
  • 调用cleanupIncrementally 通过增量触发器渐进清理State。当进行状态访问或者处理数据时,在回调函数中进行清理。每次递增清理触发时,遍历StateBackend中的状态,清理过期的。

接下来Flink作业提交篇,如果对Flink感兴趣或者正在使用的小伙伴,可以加我入群一起探讨学习。

参考书籍《Flink 内核原理与实现》

欢迎关注公众号: 数据基石

Flink 内核原理与实现-状态原理_第7张图片

你可能感兴趣的:(Flink,flink,Flink,内核原理与实现,Flink)