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

这是我参与「第四届青训营 」笔记创作活动的的第3天，本篇笔记主要是关于第三次大数据课程《Exactly Once语义在Flink中的实现》的课堂笔记

传统SQL和流处理

先将数据流用某种方式转化为一个动态表，再在动态表上执行查询语句，得到新的动态表，再转化为数据流。 动态表：与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询它们。当插入更多的单击流记录时，结果表将不断增长。

• 连续查询：
  1. 查询从不终止；
  2. 查询结果不断更新，产生一个新的动态表；

动态表到实时流的转换：

• Append-only Stream: Append-only 流（只有 INSERT 消息）
• Retract Stream: Retract 流（同时包含 INSERT 消息和 DELETE 消息）

若出现故障，不同数据处理保证的语义：

1. At-most-once: 出现故障的时候，啥也不做。数据处理不保证任何语义，处理时延低。可以得到近似结果。
2. At-least-once: 保证每条数据均至少被处理一次，一条数据可能存在重复消费。可保证数据不丢失。
3. Exactly-once: 最严格的处理语义，从输出结果来看，每条数据均被消费且仅消费一次，仿佛故障从未发生。

状态快照与恢复：

可保证语义不丢不重。把历史某一刻的数据保存下来，一旦故障发生，就回到那个时刻，并恢复那个时刻的状态

• 状态恢复的时间点: 需要等待所有处理逻辑消费完成source保留状态及之前的数据。
• 一个简单的快照制作算法:
  1. 暂停处理输入的数据;
  2. 等待后续所有处理算子消费当前已经输入的数据;
  3. 待2处理完后，作业所有算子复制自己的状态并保存到远端可靠存储;
  4. 恢复对输入数据的处理
• Checkpoint对作业性能的影响：
  1. 解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子制作制作完成快照;
  2. 在快照制作和Barrier Alignment过程中需要暂停处理数据，仍然会增加数据处理延迟;
  3. 快照保存到远端也有可能极为耗时。

Flink两阶段提交：

先预处理，当所有参与者都向协调者发出成功信号时，才进行数据commit同步，否则就进行回滚操作。
- Coordinator：协作者，同步和协调所有节点处理逻辑的中心节点
- Participant：参与者，被中心节点调度的其他执行处理逻辑的业务节点

1. 事务开启:在sink task向下游写数据之前，均会开启一一个事务，后续所有写数据的操作均在这个事务中执行，事务未提交前，事务写入的数据下游不可读;
2. 预提交阶段: JobManager开始下发Checkpoint Barrier, 当各个处理逻辑接收到barrier 后停止处理后续数据，对当前状态制作快照，此时sink也不在当前事务下继续处理数据(处理后续的数据需要新打开下一个事务)。状态制作成功则向JM成功的消息，失败则发送失败的消息;
3. 提交阶段:若JM收到所有预提交成功的消息，则向所有处理逻辑(包括sink )发送可以提交此次事务的消息，sink接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据;若JM有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时sink 则丢弃这次事务提交的数据下。

从Kfaka消息队列读出消息后，结点通过checkpoint barrier来表示当前结点的数据已经更新，并向State Backend发出快照状态，进行记录。最终当各结点都发出快照状态后，执行commit同步数据。 优势:

1. 严格意义上的端到端的Exactly- Once语义:下游读到的数据是不丢不重的;
2. 增强的去重能力:可以在更长的时间维度对数据进行去重。

最终总结：

1. 数据流可以转换成动态表，动态表也能重新转换成数据流
2. 处理无限数据流的算子可以是有状态的
3. Flink通过Checkpoint机制实现故障前后的状态快照制作和恢复
4. 支持两阶段提交协议的下游存储可以结合Flink Checkpoint机制实现严格意义上端到端的Exactly-Once语义实现