Exactly Once 语义在Flink中的实现（一）|青训营笔记

这是我参与「第四届青训营 」笔记创作活动的第2天，笔记内容围绕《Exactly Once 语义在Flink中的实现》课程前半部分展开，分以下两部分记录：01.数据流和动态表，02.Exactly-Once和Checkpoint

1. 数据流和动态表

本节主要记录如何在数据流上执行SQL语句以及说明流式处理中状态的概念

• 数据流 : 数据并不是收集好的，而是像水流一样，是一组有序的数据序列，逐个到来、逐个处理。
• 动态表 : 随时间不断变化的表，在任意时刻，可以像查询静态批处理表一样查询它们。
  比较传统 SQL和流处理 连续查询的特点 :
  1. 查询从不终止
  2. 查询结果会不断更新，产生一个新的动态表

数据流和动态表转换关系图 如果把流看作一张表，那么流中每个数据的到来，都应该看作是对表的一次插入（Insert）操作，会在表的末尾添加一行数据。因为流是连续不断的，而且之前的输出结果无法改变、只能在后面追加；所以我们其实是通过一个只有插入操作（insert-only）的更新日志（changelog）流，来构建一个表。

2.Exactly-Once和Checkpoint

2.1一致性保证语义：

• At-most-once:每条数据消费至多一次，处理延迟低。
• At-least-once:每条数据消费至少一次，一条数据可能存在重复消费。
• Exactly-once:每条数据都被消费且仅被消费一次，仿佛故障从未发生。

2.2一致性检查点Checkpoint

Checkpoint是Flink 故障恢复机制的核心，所谓的checkpointe就是把整个flink job的某一瞬间的状态数据进行快照（拍照），后续可以从这个快照（持久到外部存储）来恢复状态，Checkponit是可以周期性执行。

有状态流应用的一致检查点，其实就是所有任务的状态，在某个时间点的一份拷贝（一份快照）；这个时间点，应该是所有任务都恰好处理完一个相同的输入数据的时候

flink的checkpoint是向数据流中加入一个barrier，每个operator收到这barrier时把自己的state持久化出去，等到每个operator都进行这个checkpoint动作那就可以认为在这个barrier之前所有的数据都已经被所有operator处理过了。所以从checkpoint恢复数据一定是不会丢失和重复的flink的一致性检查点不是去保存数据，而是保存当前状态；不管当前正在处理的数据是什么，就考虑同一个数据被所有任务都处理完之后的状态保存下来。

Checkpoint 对作业性能的影响 1．解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子制作制作完成快照;
2.在快照制作和Barrier Alianment过程中需要暂停处理数据，仍然会增加数据处理延迟;
3.快照保存到远端也有可能极为耗时。