这是我参与「第四届青训营」笔记创作活动的第3天。
知识点小记
数据流和动态表
传统SQL和流处理的差异
- 传统SQL处理的表是有界的，而流是无限元祖序列。
- 传统SQL执行查询后可以得到完整的数据，为流处理无法访问所有的数据。
- 传统SQL可在一定时间内终止并产生结果，而流处理的结果会不断更新，永不终止。
数据流和动态表的转换
graph LR
A(Stream) --> B(Dynamic Table)
B --> |Continues Query| C(Dynamic Table)
C --> D(Stream)
写入的数据流通过转换写入动态表，有了该动态表之后就可以对其进行连续查询并将查询结果写入另一动态表中， 之后即可将该动态表转换为另一种数据流进行写出。由此可看出，表和流可进行动态转化。
Checkpoiot 状态快照制作
Exactly-once : 保证每条数据均被消费且只被消费一次。
Checkpoint Barrier：状态快照制作的开始的标志。
状态快照与恢复
当作业出现故障并恢复后，作业会进行重启，此时可从可靠的远端存储去拿离故障最近时间的状态快照的数据将其恢复到对应的算子中去。
制作状态快照的时间点的要求
对于时间点的要求：需要等待所有的下游处理逻辑处理完source保留的状态之前的数据，否则有些数据有可能没有被下游的算子处理而被保存，从而引发数据的丢失。
快照制作方法
方法一：
最简单地想法就是当要保存某一时间算子的状态，上游source算子会停止后续数据的处理，待下游的所有算子状态制作完成后，才能继续进行后续数据的处理。但该方法会降低算子的完成作业效率。
方法二：
可用下发Checkpoint Barrier标识的形式来标识快照制作的开始，当前算子接收到上游所有的算子发放的Checkpoint Barrier后开始处理该数据并保存当前算子的状态，并向下游的所有算子也下发Checkpoint Barrier标识并告知JM自己的状态制作已经完成，此时，当前算子可以继续处理后续的数据而不用等待下游的算子状态是否制作完成。该方法通过Checkpoint机制对所有算子的状态实现Exactly-Once，可以将快照制作和数据处理过程进行解耦。
总结
传统的快照制作的方法一虽然能够实现其功能，但是节点的利用率会下降很多。而方法二中上游节点制作完状态快照后不用等待下游节点而可以继续执行后面数据的处理，相对于方法一来说处理作业的效率会大大增加。
