【大数据】flink保证Exactly_Once的理解

1、exactly once

要保证flink 端到端需要满足以下三点
1、flink要开启checkpoint
2、source支持数据重发
3、sink端幂等性写入、事务性写入。我们常使用事务性写入

sink 事务性写入分为两种方式
1、WAL(预写日志的方式):先将数据当作状态保存,当收到checkpoint完成通知后,一次性sink到下游系统
2、2pc(两阶段提交):大致的实现的过程就是:

  • 开始事务(beginTransaction)创建一个临时文件夹,来写把数据写入到这个文件夹里面。
  • 预提交(preCommit)将内存中缓存的数据写入文件并关闭。
  • 正式提交(commit)将之前写完的临时文件放入目标目录下。这代表着最终的数据会有一些延迟。
  • 丢弃(abort)丢弃临时文件

若失败发生在预提交成功后,正式提交前。可以根据状态来提交预提交的数据,也可删除预提交的数据。

2、使用flink-sink- kafka作为例子

一个典型例子:

  1. data source从kafka消费数据
  2. window聚合
  3. data sink将处理后的数据写入到kafka

data sink为了提供exactly-once保证,必须将一个事务中的数据都写入到kafka,一次commit包含了2个checkpoint之间的所有的写操作,这保证了当失败时,也会回滚所有的写操作。

第一步:pre-commit阶段。

pre-commit是一次checkpoint的开始,flink的checkpoint barrier在operator中传递,当一个operator接收到barrier,触发state snapshot。

比如Kafka source会保存消费的offset,完成后传递barrier。
这个过程如果仅仅只涉及internal state(internal state是由flink保存和管理的),是没有问题的,但是如果涉及到external state,则需要外部系统提供一致性保证,外部系统必须要提供对2PC的事务支持。

当所有的operator完成了checkpoint,Pre-commit阶段就算完成了。Checkpoint的snapshot包含了整个application的状态,包括外部系统的pre-commited的external state,如果发生失败,可以回滚到最近一次成功的snapshot。

第二步:JobManager通知所有的operator,checkpoint完成了,执行commit阶段。

例子中的data source和window operator没有external state,在commit执行阶段无需额外的操作。data sink有external state,需要commit这次事务。
整个流程如下:

  • 当所有的operator完成了pre-commit(checkpoint snapshot),开启一个commit。
  • 如果有一个pre-commit失败了,其他都abort,回滚到最近一次成功的checkpoint。
  • Pre-commit成功后,所有的operator和外部系统必须保证commit执行成功,如果有失败(如网络中断),则整个flink application fail,flink任务按重启策略重启,开始一次新的commit尝试。

你可能感兴趣的:(大数据工程师成神之路,#,flink,大数据开发摸爬滚打系列,flink,checkpoint,exactly,once)