网站建设行业动态,淘宝运营视频教程全集,自己做网站用花钱么,.net做的网站代码文章目录知识点状态Flink容错恢复周期性的 Checkpoint错误检测 Failure Detected重新调度 Re-scheduling状态恢复 State Recovery通用增量Checkpoint知识点
状态
算子需要记录之前数据处理的中间结果#xff0c;把中间结果暂时缓存在算子的内部#xff0c;这就是算子的状态…
文章目录知识点状态Flink容错恢复周期性的 Checkpoint错误检测 Failure Detected重新调度 Re-scheduling状态恢复 State Recovery通用增量Checkpoint知识点
状态
算子需要记录之前数据处理的中间结果把中间结果暂时缓存在算子的内部这就是算子的状态。
为了避免算子挂掉状态丢失就需要重头开始进行Flink作业这样效率太差为了解决算子挂掉导致状态丢失无法恢复算子、算子状态的问题周期性的对算子状态进行snapshot这就是Flink的CheckPoint机制
Flink容错恢复
因为Checkpoint是频发的所以Checkpoint过程要尽可能轻量、稳定且能够保证成功。
容错恢复过程有以下几个方面
周期性的 Checkpoint
错误检测 Failure Detected
如果某个节点挂了就需要快速的发现这个失败节点并完成相应的清理工作
重新调度 Re-scheduling
生成新的作业并重新调度最后完成部署
状态恢复 State Recovery
作业重新调度起来以后就需要从最新的快照中把算子的中间状态恢复起来
通用增量Checkpoint
Generic Log-based Incremental Checkpoints
算子在更新自身状态时会将状态更新结果记录到状态表中
快照异步上传到DFS的时间和状态表的大小正相关时间非常长并且不可控
为了解决这个问题引入了通用增量Checkpoint机制
解耦状态表和增量日志上传过程
在维护原有状态表的同时记录一份增量状态更新日志Change Log
原有的算子状态快照的过程有两个部分 第一个部分是同步对算子进行快照这个过程中内存的数据会刷写到磁盘准备好上传到DFS的文件
第二个部分就是异步上传快照文件
存在的问题
异步上传的文件大小严重依赖StateBackend的实现在同步快照结束前是无法开始异步上传过程的整个异步上传过程要等到同步过程结束后才能进行
对于第一个问题以RocksDB为例虽然说RocksDB支持增量快照但是RocksDB因为自身的实现机制需要对文件Compaction每次Compaction都会产生新的比较大的文件这种情况下即使是增量的Checkpoint也会时不时的使需要上传的Checkpoints文件变得比较大如果并发比较大的情况下上传文件时不时变大导致的问题就会很严重因为只有等所有并发上传的文件都上传完毕一个完整的算子状态才算是快照完成。
对于第二个问题状态同步快照结束前无法开始异步上传过程会导致较大的作业延迟
针对以上两个问题新的通用增量Checkpoint机制 算子状态更新时不仅会更新状态表还会记录状态更新日志这样的话状态表还是会周期性的刷新到DFS中但是这个周期可以变得比较大比如10分钟状态表在后台慢慢的进行上传这个过程称之为物化过程物化过程。同时这个状态更新日志也会不断的上传到远端DFS并且在Checkpointing的时候Flush剩余的全部日志。
通过将状态快照过程和物化过程完全的独立开来可以让异步上传的文件大小变得很稳定同时因为状态更新是持续的可以在快照之前就一直持续的上传、更新所以在快照的时候实际上需要上传的数据量就会变得很小。物化过程结束后相对应的更新日志可以被删除。
Change Log Storage DSTLDurable Short-term Log
DSTL的几个特性 持久化 高频写 写延迟 一致性
待定…
资料
Flink 1.15 新功能架构解析高效稳定的通用增量 Checkpoint
