Flink状态编程

• Flink中的状态
  在 Flink 中，算子任务可以分为无状态和有状态两种情况。无状态的算子任务只需要观察每个独立事件，根据当前输入的数据直接转换输出结果，例如， 可以将一个字符串类型的数据拆分开作为元组输出。Flink中的基本转换算子， 如 map、filter、flatMap， 计算时不依赖其他数据， 就都属于无状态的算子。
  
  而有状态的算子任务，则除当前数据之外，还需要一些其他数据来得到计算结果。这里的 “其他据”，就是所谓的状态(state)，最常见的就是之前到达的数据，或者由之前数据计算出的某个结果。比如， 做求和(sum) 计算时， 需要保存之前所有数据的和，这就是状态；窗 口算子中会保存已经到达的所有数据，这些也都是它的状态。Flink中的聚合算子、窗口算子都属于有状态的算 子。
  

  1）状态的管理：
       在传统的事务型处理架构中，这种额外的状态数据是保存在数据库中的。而对于实时流处 理来说，这样做需要频繁读写外部数据库，如果数据规模非常大肯定就达不到性能要求了。所以 Flink 是将状态直接保存在内存中来保证性能， 并通过分布式扩展来提高吞吐量。
  在 Flink 中，每一个算子任务都可以设置并行度，从而可以在不同的 slot 上并行运行多个实例， 我们把它们叫作“并行子任务”。而状态既然在内存中， 那么就可以认为是子任务实例上的一个本地变量， 能够被任务的业务逻辑访问和修改。这样看来状态的管理似乎非常简单， 直接把它作为一个对象交给 JVM 就可以了。然而大数据的场景下， 我们必须使用分布式架构来做扩展， 在低延迟、高吞吐的基础上还要保证容错性，一系列复杂的问题也随之而来。
      1）容错性，也就是故障后的恢复。状态只保存在内存中显然是不够稳定的，我们需要将它持久化保存， 做一个备份；在发生故障后可以从这个备份中恢复状态。

      2）我们还应该考虑到分布式应用的横向扩展性。比如处理的数据量增大时，我们应该相应地对计算资源扩容，调大并行度。这时就涉及到了状态的重组调整。
        可见状态的管理并不是一件容易的事。Flink 作为有状态的大数据流式处理框架，已经搞定了这一切。 Flink 有一套完整的状态管理机制，将底层一些核心功能全部封装起来， 包括状态的高效存储和访问、持久化保存和故障恢复，以及资源扩展时的调整。

  2）状态分类：
    1）托管状态(Managed State)和原始状态(Raw State)
       Flink 的状态有两种：托管状态(Managed State) 和原始状态(Raw State)。托管状态就是由 Flink 统一管理，状态的存储访问、故障恢复和重组等一系列问题都由 Flink 实现，我们只要调接口就可以； 而原始状态则是自定义的，相当于开辟了一块内存，需要我们自己管理，实现状态的序列化和故障恢复。
        具体来讲， 托管状态是由 Flink 的运行时(Runtime)来托管的；在配置容错机制后，状态会自动持久化保存，并在发生故障时自动恢复。当应用发生横向扩展时， 状态也会自动地重组分配到所有的子任务实例上。对于具体的状态内容， Flink  也提供了值状态(ValueState)、 列表状态(ListState)、映射状态(MapState)、聚合状态(AggregateState) 等多种结构， 内部支持各种数据类型。聚合、窗口等算子中内置的状态， 就都是托管状态；我们也可以在富函数类(RichFunction) 中通过上下文来自定义状态，这些也都是托管状态。
       而对比之下，原始状态就全部需要自定义了。 Flink 不会对状态进行任何自动操作， 也不知道状态的具体数据类型，只会把它当作最原始的字节(Byte) 数组来存储。我们需要花费大 量的精力来处理状态的管理和维护。
       所以只有在遇到托管状态无法实现的特殊需求时，我们才会考虑使用原始状态；一般情况下不推荐使用。绝大多数应用场景， 我们都可以用Flink 提供的算子或者自定义托管状态来实现需求。
    2）算子状态(Operator State)和按键分区状态(Keyed State)：
        在 Flink 中，一个算子任务会按照并行度分为多个并行子任务执行， 而不同的子