flink基本概念

Apache Flink 是一个分布式大数据处理引擎，可对有限数据流和无限数据流进行有状态或无状态的计算，能够部署在各种集群环境，对各种规模大小的数据进行快速计算。

有状态的流式处理(State)

Managed State && Raw State

Managed State 是 Flink 自动管理的 State，而 Raw State 是原生态 State，两者的区别如下：

从状态管理方式的方式来说，Managed State 由 Flink Runtime 管理，自动存储，自动恢复，在内存管理上有优化；而 Raw State 需要用户自己管理，需要自己序列化，Flink 不知道 State 中存入的数据是什么结构，只有用户自己知道，需要最终序列化为可存储的数据结构。
从状态数据结构来说，Managed State 支持已知的数据结构，如 Value、List、Map 等。而 Raw State只支持字节数组 ，所有状态都要转换为二进制字节数组才可以。
从推荐使用场景来说，Managed State 大多数情况下均可使用，而 Raw State 是当 Managed State 不够用时，比如需要自定义 Operator 时，推荐使用 Raw State。

Keyed State & Operator State

Managed State 分为两种，一种是 Keyed State；另外一种是 Operator State。在Flink Stream模型中，Datastream 经过 keyBy 的操作可以变为 KeyedStream 。

类别	Keyed State	Operator State
作用算子范围	只能作用keyedStream算子中(一个operator中有处理多个key,那他就可以访问多个key对应的State)	可用于所有算子，常用于source
分配方式	并发改变，State随着key在实例中迁移	并发改变时，可选择均匀分配或者合并后全量分配
访问方式	通过RuntimeContext（RichFunction）	实现CheckpointedFunction或者ListCheckpointed接口
支持的数据结构	valueState,ListState,ReducingState,AggregatingState,MapState	ListState

状态容错和恢复

Checkpoint

定时制作分布式快照，对程序中的状态进行备份
发生故障时,整个作业的所有Task都从最后一次成功的Checkpoint恢复作业
必要条件:数据源支持重发
一致性语义:恰好一次(Barries对齐)，和至少一次(通过Barries是否对齐判断)
轻量，自动从故障中恢复
作业停止后默认删除

Savepoint

用户手动触发
通常在用户重启作业，或者调整并发时手动触发
持久的，以标准格式存储，手动触发从Savepoint恢复

状态存储方式

MemoryStateBackend

支持同步异步
State 存储在TaskManager 内存中
Checkpoint 存储在 JobManager 内存中

FsStateBackend

支持同步异步
State 存储在TaskManager 内存中
Checkpoint 存储在外部文件系统（本地或 HDFS）

RocksDBStateBackend

RocksDB 支持增量的 Checkpoint
State 存储在TaskManager上的 KV数据库中(使用的是内存+磁盘)
Checkpoint 存储在外部文件系统（本地或 HDFS）

Time

在 Flink 中 Time 可以分为三种Event-Time，Processing-Time 以及 Ingestion-Time

在这里插入图片描述

Event-Time 表示事件发生的时间，Processing-Time 则表示处理消息的时间（墙上时间），Ingestion-Time 表示进入到系统(DataSource)的时间。

Watermarks

Flink实际上是用 Watermarks 来实现Event – Time 的功能。Watermarks 在Flink 中也属于特殊事件，其精髓在于当某个运算值收到带有时间戳“ T ”的 Watermarks 时就意味着它不会接收到新的数据了。使用Watermarks 的好处在于可以准确预估收到数据的截止时间。举例，假设预期收到数据时间与输出结果时间的时间差延迟5 分钟，那么Flink 中所有的 Windows Operator 搜索3 点至4 点的数据，但因为存在延迟需要再多等5分钟直至收集完4：05 分的数据，此时方能判定4 点钟的资料收集完成了，然后才会产出3 点至4 点的数据结果。这个时间段的结果对应的就是 Watermarks 的部分。

我们可以考虑一个这样的例子：某 App 会记录用户的所有点击行为，并回传日志（在网络不好的情况下，先保存在本地，延后回传）。A 用户在 11:02 对 App 进行操作，B 用户在 11:03 操作了 App，但是 A 用户的网络不太稳定，回传日志延迟了，导致我们在服务端先接受到 B 用户 11:03 的消息，然后再接受到 A 用户 11:02 的消息，消息乱序了。

那我们怎么保证基于 event-time 的窗口在销毁的时候，已经处理完了所有的数据呢？这就是 watermark 的功能所在。watermark 会携带一个单调递增的时间戳 t，watermark(t) 表示所有时间戳不大于 t 的数据都已经到来了，未来小于等于t的数据不会再来，因此可以放心地触发和销毁窗口了

在这里插入图片描述