Flink学习知识分享三（State、Checkpointin）

1.State

参考网址：https://ci.apache.org/projects/flink/flink-docs-release-1.8/dev/stream/state/

1.1定义

实际上就是指flink计算中间的计算结果或者元数据属性等信息，State会做相应的持久化，说白了State就是Flink计算过程中与时间相关的内部数据的快照，它是用于checkpoints做容错。

1.2为什么需要

基于各种原因，导致需要使用checkpoints去从state中做恢复

1.3何时启动

在使用checkpoint时

1.4state的工作机制

• keyed state：
  只能针对keystarem想的function或者operators做操作
  可以理解成是operator state的一个特例(已经分区/分片)
• operator state：
  每一个都绑定到一个并行实例(eg: kafka connector)，当并行度变化， 它支持重新分配state

1.5state的呈现形式

keyed state和operator state都有两种呈现形式：

• Raw state:自己管理内部数据结果，flink是看不见内部的数据结构(byte[])
• Managed State：flink控制内部结构，在runtime时进行相应编码，写入checkpoint

1.6useing managed keyed state

作用域指当前输入元素的key，即只能在keyedStream上使用(eg：stream.keyby())。状态不一定存储在内部，可能在磁盘或者其他地方。

• State Time-To-Live (TTL，存活时间)
  可以分配给任何类型的keyed state
  要使用时需先构建一个配置对象(StateTtlConfig)
  [newBuilder第一个参数是强制性的，因为是生存时间]

    		注意：
    			1.存储的是最后一次修改的时间戳以及user值
    			2.目前TTL只支持处理processing time
    			3.兼容性失败以及异常注意(尝试恢复state时)
    			4.TTL不是checkpoint 或者savepoint的部分，是flink runtime时的如何处理
    			的一种方式
    			5.针对null value处理 
    		过期状态清除:
    			只有在显示读取时才会清除：ValueState.value()
    			默认情况未读取的过去状态不会清除，会导致state不断增大；
    			获取完整的状态快照时做激活清理，减少状态大小，不会清理本地状态，
    			但从上一个快照恢复时，不会包含已删除的过期状态，可通过StateTtlConfig配置
    			不适用于RocksDB状态后端的增量检查点
  

1.7The Broadcast State Pattern

它是第三种支持的operator state，可参考文章：https://www.ververica.com/blog/a-practical-guide-to-broadcast-state-in-apache-flink

• 目的：将下游任务需要的一些数据广播出去
• 差异(其他operator state)：
  map format
  只对broadcast和non-broadcast输入的特性操作符可用
  这种的操作符可以有多个不同名称的broadcast state
• 注意事项：
  1.There is no cross-task communication: 没有跨任务的沟通
  2.Order of events in Broadcast State may differ across tasks：event在广播中的顺序可能导致task任务结果不同
  3.All tasks checkpoint their broadcast state：所有的任务的checkpoint都需要检查他们的广播状态
  [保证在恢复时不会有重复或者数据的丢失]
  4.没有RocksDB的后端状态存储方式

1.8 State Backends(状态后端存储)

• MemoryStateBackend：
  维护在Java堆上的一个内部状态后端
  注意点：
  1.每个状态的大小限制为5M
  2.状态大小不能超过akka的framesize
  3.状态总大小不能超过JobManager的总内存
  何时使用：
  1.开发或者调试
  2.小状态用例

• FsStateBackend：
  配置URL等信息，checkpoint时写入对应目录，并在JobManager内存中存储极少的元数据
  注意：
  这种状态仍然先存在TaskManager中，所以大小不能超过TaskManager的大小
  何时使用：
  1.大状态、长窗口、大的kv state job作业
  2.高可用安装

• RocksDBStateBackend：
  配置URL等信息，checkpoint时写入对应目录，并在JobManager内存中存储极少的元数据
  注意点：
  1.大小支持2^31个字节，受限于RocksDB自身的byte[]形式
  2.对于有合并的操作状态的应用要注意，可能会超过RocksDB的最大字节数，导致检索失败
  何时使用：
  1.大状态、长窗口、大的kv state job作业
  2.高可用安装

1.9 Checkpointing

本身用于flink的状态容错，checkponit允许flink恢复流内部的状态以及位置，可以为程序提供无障碍执行的的语义

• 为了使检查点与stream与state持久性存储做交互，需要满足两点：
  1.一个持久性的数据源，在一定时间内做数据重放
  2.状态的持久存储

• 配置(默认是禁用的)：
  exactly-once vs at-least-once
  checkpoint time
  mininum between checkpoints
  …

• 重置策略:
  Fixed Delay Restart Strategy ：基于延迟重启
  Failure Rate Restart Strategy：基于故障重启
  No Restart Strategy ：没有重启
  Fallback Restart Strategy ：基于回退重启

• checkpoints：
  retained checkpoints：
  默认不保留，可以做配置保留检查点
  默认随着job结束而被清理，也可配置不清理
  保留：后续需要手动去销毁
  直接删除：
  目录结构：
  元数据文件、状态后端、一些额外的数据文件

• savepoints:
  是流job的一个映像，通过checkpointing进行创建
  用于停止、恢复、更新flink job

    目录结构：
    	一个目录(在稳定存储上的二进制文件)
    	元数据文件(相对较小的)
  

• checkpoints vs savepoints：https://www.ververica.com/blog/differences-between-savepoints-and-checkpoints-in-flink
  官网提供
  1.使用状态后端特定的数据格式，可以做增量checkpoint
  2.不支持flink的一部分特定特性，比如：重新扫描
  连接提供：
  1.目标:
  checkpoint:做flink中job的恢复机制
  savepoint：手动备份，用于恢复暂定的作业
  2.实现：
  checkpoint：轻量、快递
  savepoint：关注的是数据的课移植性，状态生成以及恢复的成本比较高
  3.生命周期：
  checkpoint：由flink去管理
  savepoint：由用户管理