【Flink】 Flink 相关知识点以及踩坑记录

1、 Flink任务调度原理之逻辑数据流与执行图

2、Flink检查点（checkpoint）、保存点（savepoint）的区别与联系

（1） checkpoint面向Flink Runtime本身，由Flink的各个TaskManager定时触发快照并自动清理，一般不需要用户干预；savepoint面向用户，完全根据用户的需要触发与清理。
（2） checkpoint是支持增量的（通过RocksDB），特别是对于超大状态的作业而言可以降低写入成本。savepoint并不会连续自动触发，所以savepoint没有必要支持增量。

2.1 checkpoint的代码实现

参考链接：https://blog.csdn.net/aa1215018028/article/details/93159049

3、 Flink Checkpoint 原理

4、 State 存储方式

三种状态后端的介绍：
MemoryStateBackend 默认，小状态，本地调试使用
FsStateBackend 大状态，长窗口，高可用场景
RocksDBStateBackend 超大状态，长窗口，高可用场景，可增量checkpoint
参考链接：https://www.cnblogs.com/YuanWeiBlogger/p/12072782.html

5、 并行度

slot 是指 taskmanager 的并发执行能力
parallelism 是指 taskmanager 实际使用的并发能力
max parallelism : 最大并行度，最大并行度的默认设置大致为operatorParallelism+（operatorParallelism/2），下限为128，上限为32768。
如果要使用保存点，还应考虑设置最大并行度（或最大并行度）。从保存点还原时，可以更改特定运算符或整个程序的并行度，此设置指定并行度的上限。这是必需的，因为Flink在内部将状态划分为键组，并且我们不能有无限个键组，因为这将对性能有害。
注意：将最大并行度设置为非常大的值可能会对性能造成不利影响，因为某些状态后端必须保持内部数据结构随密钥组的数量而扩展（这是可重缩放状态的内部实现机制）

6、 重启策略

（1） 为什么需要 RestartStrategy？
重启策略会让 Job 从上一次完整的 Checkpoint 处恢复状态，保证 Job 和挂之前的状态保持一致，另外还可以让 Job 继续处理数据，不会出现 Job 挂了导致消息出现大量堆积的问题，合理的设置重启策略可以减少 Job 不可用时间和避免人工介入处理故障的运维成本，因此重启策略对于 Flink Job 的稳定性来说有着举足轻重的作用。
（2）如何配置 RestartStrategy？
默认重启策略可以在 Flink 的配置文件 flink-conf.yaml 中设置，由 restart-strategy 参数控制，有 fixed-delay（固定延时重启策略）、failure-rate（故障率重启策略）、none（不重启策略）三种可以选择，如果选择的参数不同，对应的其他参数也不同。

7、 Flink的背压机制

在流式处理系统中，如果出现下游消费的速度跟不上上游生产数据的速度，就种现象就叫做反压。出现反压时，理所应当限制上游生产者的速度，使得下游的速度跟得上上游的速度。
反压会导致流处理作业数据延迟的增加，同时还会影响到Checkpoint。由于Flink的Checkpoint机制需要进行Barrier对齐，如果此时某个Task出现了反压，Barrier流动的速度就会变慢，导致Checkpoint整体时间变长，如果反压很严重，还有可能导致Checkpoint超时失败。
长期或者频繁出现反压才需要处理，如果只是由于网络波动或者正常GC出现的偶尔反压可以不必处理。

原文链接：https://blog.csdn.net/zc19921215/article/details/109246591

7.1 Flink1.11 Checkpoint机制

原文链接：https://blog.csdn.net/young_0609/article/details/111154824
Flink1.11 Checkpoint机制适用场景：
Unaligned Checkpoint由于要持久化缓存数据，State Size 会有比较大的增长，磁盘负载会加重。并且随着 State Size 增长，作业恢复时间可能增长，运维管理难度增加。目前看来，Unaligned Checkpoint 更适合容易产生高反压同时又比较重要的复杂作业。对于像数据 ETL 同步等简单作业，更轻量级的 Aligned Checkpoint 显然是更好的选择。

原文链接：https://blog.csdn.net/zc19921215/article/details/108171455
其他相关链接：
Flink 源码之分布式快照：https://www.jianshu.com/p/586792379466

7.2 flink-checkpoint 目录内容

_metadata:保存了state 的句柄,JM 解析元数据文件，做一些校验，将信息写入到 zk 中，然后准备从这一次 Checkpoint 中恢复任务
其余小文件:是 state 数据，由各 Task 在触发 checkpoint 的时候上传，恢复的时候，JM 读取_metadata 将相应句柄下发到 Task，Task 通过远端 HDFS 拉取对应的 state
原文链接：https://blog.csdn.net/u013086392/article/details/106569717

7.3 Rescale 过程

如下图所示是 Flink 依赖 KeyGroup 修改并发的 Rescale 过程（并发度从 3 改成 4）：

maxParallelism 修改则任务不能恢复

KeyGroup 的数量为 maxParallelism，一旦 maxParallelism 变了，说明 KeyGroup 的分组完全变了，而 KeyedState 恢复是以 KeyGroup 为最小单元的，所以 maxParallelism 改变后，任务将无法恢复。在 Checkpoint 恢复过程中也会对新旧 Job 的 maxParallelism 进行检查匹配，如果某个算子的 maxParallelism 变了，则任务将不能恢复。
原文链接： https://www.modb.pro/db/81224

7.4 flink state restore 流程源码分析

operator state 的三种分发模式可以用下面的图描述：

【TODO】