flink-2.概念-有状态的流式处理

什么是

流式处理的传统状态处理思路

传统批处理方法是持续收取数据，以时间作为划分多个批次的依据，再周期性地执行批次运算。但假设需要计算每小时出现事件转换的次数，如果事件转换跨越了所定义的时间划分，跨越了批次的时间边界，传统批处理会将中介运算结果带到下一个批次进行计算；除此之外，当出现接收到的事件顺序颠倒情况下，传统批处理仍会将中介状态带到下一批次的运算结果中，这种处理方式也不尽如人意。
意思就是，批处理无法做到实时，比如3点-4点，批处理无法保证系统时间3点-4点时接受的数据就是想要的

有状态的计算要有2个要素：

1. 从一个queue中累积状态、维护状态
2. 时间，根据时间判断是否接受到所有需要的数据

问题

有状态的分布式流计算
比如根据key分组求count，count就是状态，根据key分组就是分布式。
要有一个机制去维护状态，并且可以容错。

1. 状态容错

如何保证exactly once的容错

将数据为key，state的快照为value，建立一个映射，如果哪条数据出错了，直接回退到之前的快照

如何在分布式场景下产生一个全局一致（global consistent snapshot）的快照，并且不中断运算

产生gcs的方法有2：

1. 一条数据经过所有分布式节点上的算子的计算后，记录产生的状态，这样需要中断运行

2. 首先引入checkpoint的概念，所有的节点在经过一个checkpoint后，会将当前状态传输到一个共享的dfs中
   

2. 状态维护

共享变量

本地JVM
远程的，比如rocksDB，

3. Event Time处理

定义一个时间窗口，并不是按系统收到的时间，而是event产生的时间，这就需要event中带有时间信息，并且在处理时要读取这个时间信息。
watermark 用来保证指定窗口的数据是否已经全部收集完。接受一个3-4的时间窗口的数据，会设置一个延迟delay，比如5分钟，到4:05的时候才把所有3-4的event进行处理。

4. 状态保存与迁移

比如项目升级、修改bug、升级flink版本，如何把之前的状态迁移到新版本中
重新定义分区

保存点：手动设置的checkpoint

比如升级花了3小时，期间kafka仍然一直采集数据，等系统升级完，利用eventTime来进行运行窗口，此时一定不能用processTime，否则会放到一个窗口中。

总结