从0到1Flink的成长之路(二十)-Flink 高级特性之有状态计算场景

Posted 2021-07-25 熊老二-

有状态计算场景

什么场景会用到状态呢，下面列举了常见的 4 种：
去重（Distinct）：比如上游的系统数据可能会有重复，落到下游系统时希望把重复的数据都去掉。去重需要先了解哪些数据来过，哪些数据还没有来，也就是把所有的主键都记录下来，当一条数据到来后，能够看到在主键当中是否存在。  窗口计算（Window）：比如统计每分钟 nginx 日志 API 被访问了多少次。窗口是一分钟计算一次，在窗口触发前，如 08:00 ~ 08:01 这个窗口，前59秒的数据来了需要先放入内存，即需要把这个窗口之内的数据先保留下来，等到 8:01 时一分钟后，再将整个窗口内触发的数据输出。未触发的窗口数据也是一种状态。
机器学习/深度学习（ML和DL）：如训练的模型以及当前模型的参数也是一种状态，机器学习可能每次都用有一个数据集，需要在数据集上进行学习，对模型进行一个反馈。
访问历史数据（History）：如与昨天的数据进行对比，需要访问一些历史数据。如果每次从外部去读，对资源的消耗可能比较大，所以也希望把这些历史数据也放入状态中做对比。
什么是状态
state
先回顾一下到底什么是 state，流式计算的数据往往是转瞬即逝， 当然，真实业务场景不可能说所有的数据都是进来之后就走掉，没有任何东西留下来，那么留下来的东西其实就是称之为state，中文可以翻译成状态。
在下面这个图中，所有的原始数据进入用户代码之后再输出到下游，如果中间涉及到 state的读写，这些状态会存储在本地的 state backend（可以对标成嵌入式本地 kv 存储）当中。

状态分类
working-with-state
1 组织形式划分
转态State存在的两种形式（Forms）：Managed（管理）和Raw（原始）。

从Flink是否接管角度，状态可以分为：
ManagedState(托管状态)
RawState(原始状态)
两者的区别如下：

1. 从状态管理方式的方式，Managed State 由 Flink Runtime 管理，自动存储，自动恢复，在内存管理上有优化；而 Raw State 需要用户自己管理，需要自己序列化，Flink不知道 State中存入的数据是什么结构，只有用户自己知道，需要最终序列化为可存储的数据结构。
2. 从状态数据结构来说，Managed State 支持已知的数据结构，如 Value、List、Map 等。而Raw State只支持字节数组 ，所有状态都要转换为二进制字节数组才可以。
3. 从推荐使用场景来说，Managed State 大多数情况下均可使用，而 Raw State 是当
   Managed State 不够用时，比如需要自定义 Operator 时，才会使用 Raw State。
   在实际生产中，都只推荐使用ManagedState，后续将围绕该话题进行讨论。
   2 基本类型划分
   Flink中有两种基本的状态：Keyed State 和 Operator State。
   
   Managed State 分为两种：Keyed State 和 Operator State ，Raw State都是Operator State。
   Keyed State
   在Flink Stream模型中，Datastream 经过 keyBy 的操作可以变为 KeyedStream。
   Keyed State是基于KeyedStream上的状态，这个状态是跟特定的key绑定的，对KeyedStream流上的每一个key，都对应一个state，如stream.keyBy(…)。 keyBy之后的State，可以理解为分区过的State，每个并行keyed Operator的每个实例的每个key都有一个Keyed State，即<parallel-operator-instance,key>就是一个唯一的状态，由于每个key属于一个keyed Operator的并行实例，可以将其简单的理解为<operator,key>。
   
   Operator State
   
   这里的fromElements会调用FromElementsFunction的类，其中就使用了类型为 list state 的operator state。
   Operator State又称为 non-keyed state，与Key无关的State，每一个 operator state 都仅与一个 operator 的实例绑定。Operator State 可以用于所有算子，但一般常用于 Source。