【大数据】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尝试。