CheckPoint执行机制详解

CheckPoint执行机制详解

本文将对Checkpoint的执行流程逐步拆解进行分析:
CheckPointCoordinator:整个checkpoint的发起者,由Jobmanger管理着
source:数据源
sink:数据sink
map:算子
HDFS:checkpoint存储地

第一步:checkpoint coordinator 向所有的source节点,trigger checkPoint

如下图:

第二步:每个source节点向下游所有task广播barrier,这个barrier是流中的一种特殊数据,

实现了chandy-lamport分布式快照算法核心,当下游所有task接收到所有input的barrier才会执行checkpoint,对于在barrier后面的来到的数据,但是还有没有做完checkpoint的数据,会先缓存在内存中,对于barrier之前的数据,会等计算完了,才做对应checkpoint.

如下图:

第三步:当所有task完成state备份以后,会将备份的数据地址(state handle)通知给checkpoint coordinator.

第四步:下游的sink节点收集齐上游所有的source输出的barrier之后,会进行本地快照,这里特地展示了 RocksDB incremental Checkpoint 的流程，首先 RocksDB 会全量刷数据到磁盘上（红色大三角表示），然后 Flink 框架会从中选择没有上传的文件进行持久化备份（紫色小三角）。

第五步:sink节点在完成自己的checkpoint之后,会将state handle返回通知 coordinator.

第六步:当checkpoint coordinator收集器所有的task的state handle,就会认为这一次的check point全局完成了,向持久化存储再备份一个checkpoint meta文件.

checkpoint的Exactly_once

对于事务写入,两种实现方式:预写日志和两阶段提交为了实现Exactly_once语义,Flink通过barrier将对齐阶段收到的数据缓存起来,等对齐之后再完成之后的处理,对于At Least once语义,无需缓存收集到的数据,对后续直接处理,所以导致重启时,数据可能会被多次处理,导致数据的重复
	Flink的checkpoint机制只能保证Flink的计算过程可以做到Exactly_once,但是端到端的Exactly Once需要source和sink的支持,而且取决于source sink中最弱的一端
	如果想要端到端的Exactly_once
	Flink内部:checkpoint机制
	source:可以重置数据的读取位置
	sink:需要保证从故障恢复是,数据不会重复写入
		sink有两种具体的实现方式:
		1.幂等性
			所谓幂等操作，是说一个操作，可以重复执行很多次，但只导致一次结果更改，也就是说，后面再重复执行就不起作用了。
		2.事务写入
		需要构建事务来写入外部系统，构建的事务对应着 checkpoint，等到 checkpoint 真正完成的时候，才把所有对应的结果写入 sink 系统中。
		对于事务写入,两种实现方式:预写日志和两阶段提交

Flink+Kafka 实现端到端的Exactly_once

	内部:flink的checkpoint
	source:kafka source,可以设置重置偏移量
	sink:kakfa sink 实现了两阶段提交
	具体步骤:
	我们知道Flink由jobmanager管理各个TaskManager进行checkpoint的.
	1.jobmanager会启动checkpoint coordinator,向所有的source 触发checkpoint
	2.所有source会向所有的task广播barrier,barrier会在算子间传递下去
	3.当每个算子对当前状态都做了快照,保存在转台后端了,source就会把当前offset作为状态保存起来,下次checkpoint恢复是,重新提交偏移量,从上次保存的位置开始重写消费数据
	4.每个算子遇到barrier时,都会把状态存到checkpoint中
	5.sink任务当第一条数据来到时,会开启一个事务,把数据写入kafka中,此时是预提交,数据不能被消费,当遇到 barrier 时，把状态保存到状态后端，并开启新的预提交事务。
    当所有算子任务的快照完成，也就是这次的 checkpoint 完成时，JobManager 会向所有任务发通知，确认这次 checkpoint 完成。
    当sink 任务收到确认通知，就会正式提交之前的事务，kafka 中未确认的数据就改为“已确认”，数据就真正可以被消费了。
    执行过程实际上是一个两段式提交，每个算子执行完成，会进行“预提交”，直到执行完sink操作，会发起“确认提交”，如果执行失败，预提交会放弃掉。
    
    具体总结:
    1.当第一条数据来了之后,开启一个kafka事务,正常写入kafka的分区中,但是此时数据被标记为预提交,不能被消费
    2.jobmanager触发了checkpoint操作,barrier从source向下游传递,算子遇到barrier就会将状态存入状态后端,并且会通知Jobmanager
    3.sink接收到barrier后,保存当前状态,存储checkpoint中,通知Jobmanager开启一阶段的事务,用于提交下阶段的数据
    4.jobmanager接收到所有任务的通知后,发出确认信息,表示此次checkpoint完成.
    5.当sink接收到了jobmanager的确定信息后,就会正式提交事务.
    6.外部kafka就会关闭该阶段的事务,数据就可以被消费了
``