传统批次处理方法
【1】持续收取数据（
kafka
等），以
window
时间作为划分，划分一个一个的批次档案（按照时间或者大小等）；
【2】周期性执行批次运算（
Spark/Stom
等）；
传统批次处理方法存在的问题：
【1】假设计算每小时出现特定事件的转换次数（例如：1、2…），但某个事件正好处于1到2之间就尴尬了。需要将1点处理一半的结果带到2点这个批次中进行运算。而这个划分跟我们事件发生的时间也是有误差的。
【2】在分布式多线程的情况下，如果接收到事件的顺序颠倒了，又该如何处理？
理想方法
累积状态：表示过去历史接收过的所有事件。可以是计数或者机器模型等等。
我们要处理一个持续维护的状态时，最适合的方式就是状态流处理（累积状态和维护状态+时间，是不是该收的结果都收到了）
【1】有状态流处理作为一种新的持续过程范式，处理连续的数据；
【2】产生准确的结果；
【3】实时可用的结果仅为模型的自然结果；
流式处理
流处理系统或者流处理引擎都是数据驱动的，而不是定期或者人为的去触发。数据也没有物理边界。
一般系统都会把操作符放上去，等待数据的到来进行计算。如下是一个逻辑模型（
DAG
）
分散式流式处理
【1】从数据中选择一个属性作为
key
对输入流进行分区；
【2】使用多个实例，每个实例负责部分
key
的存储，根据
Hash
值，相同的
key
一定落在相同的分区进行处理；
【3】根据流式数据处理的
DAG
模型，有对应如下的分布式流处理的实例模型。例如A算子拥有两个实例，上游的实例节点可能同时与下游的一个或多个节点进行传输。这些实例根据系统或者人为的因素分配在不同的节点之上。节点与节点之间数据传输也会涉及网络之间的占用。本地的传输就不需要走网络
有状态分散式流式处理
定义一个变量
X
，输出结果依据这个
X
，这个
X
就是一个状态。有状态分散的流失处理引擎，当状态可能会累计非常大。当
key
比较多的时候就会超出单台节点的负荷量。这个
x
就应该有状态后台使用
memory
去维护它。【数据倾斜】
状态容错（State Fault Tolerance）
状态挂了，如何确保状态拥有精确一次（
exactly-onceguarantee
）的容错保证？就是通过定期的快照+事件日志位置。我们先假设一个简单的场景，如下，一个队列在不断的传输数据。单一的
process
在处理数据。这个
process
没处理一个数据都会累计一个状态。如何为这个
process
做一个容错。做法就是没处理完一笔，更改完状态之后，就做一次快照（包含它处理的数据在队列中的位置和它处理到的位置以及当时的状态进行对比）
举个例子：如下我处理到第二笔数据，我就会记录下第二个位置在进入
process
之前的信息（位置
X
+状态
@X
）
当进入
process
处理的时候出现了
fail
时，
Flink
就会根据上一次的位置+状态进行恢复。
如何在分散式场景下替多个拥有本地状态的运算子产生一个全域一致的快照（
global consistent snapshot
）？
方式一：更改该任务流过的所有运算子的状态。比较笨，有一个副作用，就是我处理完这笔数据，它应该就到了一个
process
，我本应该做其他数据的处理了，可是为了全局一致性快照就会停止前面和当前的
process
的运算来保证全局一致性。
分散式状态容错
通过
checkpoint
实现分散式状态容错
每一个运算子它本地都有一个维护一个状态，当要产生一个检查点（
checkpoit
）的时候，都会将这个检查点存储在一个更小的分布式文件系统
DFS
中。当出现某个算子
fail
之后，就会从所有的
checkpoint
中获取所有算子的上一个状态进行恢复。把消息队列的位置也进行恢复。也就是多线程工作，每一个任务在
DFS
中就可以看作一个线程，它们数据存储的
key
就是这个任务，每一个算子的处理状态都会按照处理顺序添加进去。
分布式快照（Distributed Snapshots）
更重要是时如何在不中断运算的前提下生成快照？其实就是给每一个任务标记一个
checkpoint n
不同的任务这个
n
是不同的，相同的任务在不同的算子里面它是相同的。具体我们把这个分解后看看。
【1】如下图，当我们从数据源获取数据的时候，其实我们已经开始有状态了，这个时候我们可以把任务处理的整个过程抽象成如下图中的一张表。
【2】首先是数据源的状态，就是数据在操作前的一个位置
offset
进行快照存储，如下图所示：
【3】当获取到数据源之后，就进入算子中进行处理，此时就会对数据进入之前的状态进行
checkpoint
。记录一个
savepoint
。
【4】在最后一次操作前（输出）也会记录
checkpoint
。在这个过程中，其实前面的算子也在产生不同的
checkpoint n-1
等。如果要进行恢复使用的话，必须是一个
complete
完整的
Checkpoint
。只有部分数据的Checkpoint是不能使用的。
状态维护（State Management）
本地维护的这个状态可能非常非常大。后端的管理系统一般使用内存维护这些状态。
Flink
提供了两种状态后端：
JVM Heap
状态后端，适合比较小的状态，量不要很大。当运算子
action
要读取状态的时候，都是一个
Java
对象的
read
或者
write
。当要产生一个检查点的时候，需要将每个运算子的本地状态数据通过序列化存储在
DFS
中，
当状态非常大的时候就不能使用
JVM Heap
的时候，就需要用到
RocksDB
。当算子需要读取的时候本地
state
的时候需要进行序列化操作从而节省内存，同时，当需要进行
checkpoint
到
DFS
时，也少了序列化的步骤。它也会给本地存储一份，当
fail
的时候就可以很快恢复，提高效率。
Event-time 处理
EventTime
是事件产生的时间。
下面是一张，程序处理时间与事件发生时间的时间差的一张对比图来更好的理解
EventTime
。
Event-Time 处理
也就是说我们要统计的
3-4
点之间的数据，程序4点结束这个执行不是根据
window
时间，而是根据
event-Time
。
Watermarks
Flink
是
watermarks
实现
Event-Time
功能的。在
Flink
里面也属于一个特殊事件，精髓是当某个运算子收到一个带有时间戳
t
的
watermark
后就不会再收到任何小于该时间戳的事件了。也就是当
window
需要统计
4
点的数据时，例如我们每
5
分钟发一次
watermark
，那么当
window
收到
4.05
的
watermark
的时候才会去统计
4
点之前的数据（下一次）。如果
4.05
收到了
4
点之前的数据的话，
Flink1.5
会把这个事件输出到旁路输出(
side output
)，你可以获取出来，进行处理。目前有一个问题就是：如果某个Stream Partition 没有输入了，也就没有
Watermarks
。那么
window
就没办法进行处理了。当多个数据流的
watermarks
不相同的时候，
Flink
会取最小的
watermarks
进行运算。可以在接收到资源的时候通过代码设置
watermarks
。
OutputTag<String> outputTag =newOutputTag<String>("side-output"){};
状态保存与迁移（Savenpoints and Job Migration）
可以想成：一个手动产生的检查点（
CheckPoint
）：保存点记录某一个流失应用中的所有运算中的状态。当触发
SavePoint
之后，
Flink
提供了两种选择停止消费或者继续运算，根据场景定义。
执行停止之前，产生一个保存点。就可以解决上面提到的3个问题。
从保存点恢复新的执行，这个时候，例如我们重启花了
30
分钟，这段事件
kafka
还在不断的接收新的数据。恢复之后，
Flink
就需要从当时记录的
kafka
位置赶上最新的位置。这个时候利用
Event-Time
处理新的数据都是事件发生时的数据，这个时候再跟程序执行的时间比较就更能体现
Event-time
的价值。
版权归原作者 程序猿进阶 所有， 如有侵权，请联系我们删除。