实时数据开发 | 怎么通俗理解Flink容错机制,提到的checkpoint、barrier、Savepoint、sink都是什么

今天学Flink的关键技术--容错机制,用一些通俗的比喻来讲这个复杂的过程。参考自《离线和实时大数据开发实战》

需要先回顾昨天发的Flink关键概念

检查点(checkpoint)

Flink容错机制的核心是分布式数据流和状态的快照,从而当分布式job由于网络、集群或者任何原因失败时,可以快速从这些分布式快照(检查点checkpoint)中快速恢复,且是轻量级的。

理解思路

Flink容错机制的关键是分组标记栏(barrier)。用河水的例子来简单类比:

  • Storm是一滴一滴地处理数据;
  • SparkStreaming就像水坝一样,一批一批地放水,上一批放的水处理完了,才会放下一批水;
  • Flink的处理方式则更为优雅,它在水中定期地插入barrier,水仍然继续流(所以轻量)只是加了些barrier,如果源头有多个数据流,那么都会同步地增加同样的barrier。

同时在job处理的过程中,为了保证iob失败的时候可以从错误中恢复,Flink还对barrier 进行对齐(align)操作,比如某个operator有多个数据流,那么Flink会等到其多个输入流的同样的barrier 都到了(这就是align的含义),才会将对齐那一刻的状态进行保存,确保出等的时候可以恢复。当然,对齐也是有负面影响的,如果某个源头数据延迟很多,为了对其可能造成任务延迟,对齐是可以根据业务选择关闭的

详细描述

barrier不会干扰正常数据,数据流分割成两部分,一部分进去当前检查点,一部分进入下一检查点。每个barrier带有检查点ID n ,并且之前的数据都进入了这个检查点,检查点中会记录数据的进度信息偏移量 。分布式job中间的operato r会接受这些数据流,当接收到带有检查点n标识的barrier 时,会给所有输出流也插入一个标识n的barrier。当sink operator(DAG的终点)接收到所有输入流的barrier n时,确认检查点n 已完成。所有sink都确认检查点n完成,这个检查点才完成。

这个中间的operator,如果有多个输入流,是需要对齐

对齐操作:
  1. 接收到某个输入流的barrier n,就不能继续处理这个输入流后的数据,直到其余流都收到。不然检查点会和下一个混淆
  2. 先不处理barrier n所属的数据流,从这些数据流接收到的数据先放缓冲区
  3. 当从最后一个流提取到barrier n,operator会把等待发送的数据向后传,同时发射检查点n所属的barrier。

经过上述步骤,operator恢复所有输入流数据的处理,并优先处理输入缓存中的数据。

保存点(Savepoint)

检查点是由Flink自动管理的,定期创建,发生故障之后自动读取进行恢复,这是一个"自动存盘"的功能;而保存点不会自动创建,必须由用户明确地手动触发保存操作,所以就是"手动存盘"。

场景:

  • 版本管理和归档存储
  • 更新Flink版本
  • 更新应用程序
  • 调整并行度
  • 暂停应用程序
相关推荐
TDengine (老段)4 小时前
TDengine 中的关联查询
大数据·javascript·网络·物联网·时序数据库·tdengine·iotdb
直裾8 小时前
Mapreduce的使用
大数据·数据库·mapreduce
麻芝汤圆10 小时前
使用 MapReduce 进行高效数据清洗:从理论到实践
大数据·linux·服务器·网络·数据库·windows·mapreduce
树莓集团11 小时前
树莓集团海南落子:自贸港布局的底层逻辑
大数据
不剪发的Tony老师11 小时前
Hue:一个大数据查询工具
大数据
靠近彗星11 小时前
如何检查 HBase Master 是否已完成初始化?| 详细排查指南
大数据·数据库·分布式·hbase
墨染丶eye12 小时前
数据仓库项目启动与管理
大数据·数据仓库·spark
SelectDB12 小时前
Apache Doris 2025 Roadmap:构建 GenAI 时代实时高效统一的数据底座
大数据·数据库·aigc
遇到困难睡大觉哈哈12 小时前
Git推送错误解决方案:`rejected -> master (fetch first)`
大数据·git·elasticsearch
Roam-G13 小时前
Elasticsearch 证书问题解决
大数据·elasticsearch·jenkins