这是我参与「第四届青训营 」笔记创作活动的的第2天

本节课有4个部分。数据流和动态表、Exactly-Once和Checkpoit、端到端Exactly-Once实现、Flink案例讲解。

1.数据流和动态表

• 传统SQL与流数据

流数据的应用场景非常广泛，在网络监控、传感器网、航空航天、气象测控和金融服务等都有用武之地。下图是流数据的主要特点。

• 数据流和动态表转换

数据流会先转化为动态表（dynamic table），在动态表内进行查询操作得到新的动态表，最后再将这个新的动态表再转化为流。这样就完成了对流数据的查询操作。

注意，动态表是实时更新的，可以像查询静态批处理表一样处理它们。

• 连续查询

动态表实行连续查询，查询不会终止，查询结果会不断更新，产生新的动态表。

• Retract消息的产生

当数据流里的数据需要更新的时候。Retract消息会收回上一个数据（如图的 - Marry，1）。然后再更新数据（如图的 + Marry，2）。

2.Exactly-Once 和 Checkpoint

个人理解，Exactly-Once的基本思路是周期性的check每个算子的状态。如果出现故障，则回滚（rollback）到上一个全局一致的时刻。

• 快照与恢复

暂停处理、恢复的时间点尤为重要，处理不当会产生如累加等错误。需要等待所有算子处理结束，source保留状态及之前的数据。

简易的快照流程是：首先，暂停处理数据。其次，等他所有算子处理完当前的输入。然后，复制所有算子的结果到远端可靠存储。最后，恢复对数据的处理。

• Chandy-Lamport 算法

JM会发送Checkpoint Barrier给每一个source算子开启快照。此时，source算子会短暂的停止其处理逻辑同时保存当前状态（发到远端）。然后，source算子会继续像下游发送Checkpoint Barrier此后恢复对数据的处理。

Barrier Alignment：算子会等待所有的Checkpoint Barrier到达之后才开始快照。已经完成快照的算子会继续处理数据，不会产生阻塞。

此算法的快照制作和数据处理是解藕的，每个算子只需要处理其本身的快照制作，不会收到下游的影响，不会产生阻塞。当所有算子告知JM快照制作完成的时候，checkpoint结束。

我的看法：作为分布式算法的Chandy-Lamport实现了解藕，上游算子制作完快照以后可以立即开始处理数据，效率有显著提高。不过，由于算子必须等待所有barrier到达才能开始制作快照，因此barrier alignment还是可能消耗大量时间。最后，老师也提到了，讲快照保存到远端也可能极为耗时。

3.Flink端到端的Exactly-Once语义

Checkpoint可以保证作业失败的情况下从最近一次快照进行恢复。但是，flink有很多外接系统，比如将数据写到kafka，一旦作业失败重启，offset重置，会消费旧数据，从而将重复的结果写到kafka。因此，还需要端到端端Exactly-Once来保证系统之间的数据一致。

Flink主要使用两阶段提交协议来解决这个问题。

• 两阶段提交协议

coordinator是统一处理执行逻辑的中心节点。被调度的其他业务节点是participate。

预提交阶段：coordinator像所有participate发送commit。participate收到commit后执行任务但是不提交。若执行成功，回复VOTE YES，反之，VOTE NO

提交阶段：若coordinator收到VOTE YES，它会像所有的participate再发一个commit。收到commit后，participate释放资源，结束任务。然后发送ack给coordinator，coordinator将此任务标记为已完成。若coordinator收到VOTE NO，coordinator会给所有participate发送rollback。participate收到rollback后回滚事物的执行操作并释放资源，发送ack给coordinator。接收到ack后，coordinator将任务标记为已回滚。

下面两个图是flink读写kafka的简单例子。

4.Flink案例

时间有限，这里就不多赘述了。