这是我参与「第四届青训营 」笔记创作活动的第3天
1. 数据流与动态表
1.1 传统SQL与流处理
SQL：处理的表是有界的，执行查询可以访问完整的数据，批处理查询产生固定大小结果后终止
流处理：流是一个无限元组序列，执行查询无法访问所有的数据，查询不断更新结果（产生新的动态表）且永不终止
1.2 不同数据处理保证的语义
1.At-most-once: 出现故障不处理。数据处理不保证任何语义，处理时延低
2.At-least-once：保证每条数据均至少被处理一次，一条教据可能存在重复消费
3.Exactly-once：最严格的处理语义，从输出结果来看，每条数据均被消费且仅消费一次，仿佛故障从未发生
2. Exactly-Once和 Checkpoint
2.1 制作快照的时间点
状态恢复的时间点：需要等待所有处理逻辑消费完成source保留状态及之前的数据。
一个简单的快照制作算法:
1.暂停处理输入的数据;
2等待后续所有处理算子消费当前已经输入的数据;
3.待2处理完后，作业所有算子复制自己的状态并保存到远端可靠存储;
4.恢复对输入数据的处理
2.2 Checkpoint 对作业性能的影响
1.解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子制作制作完成快照;
2.在快照制作和 Barrier Alignment过程中需要暂停处理数据，仍会增加数据处理延迟;
3.快照保存到远端也有可能极为耗时。
3. Flink端到端的 Exactly-once语义
3.1 端到端Exactly-once语义
1. Checkpoint能保证每条数据都对各个有状态的算子更新一次，sink输出算子仍然可能下发重复的数据;
2.严格意义的端到端的Exactly-once语义需要特殊的sink算子实现。
3.2 Flink二阶段提交
1.事务开启:在sink task向下游写数据之前，均会开启一个事务，后续所有写数据的操作均在这个事务中执行,事务未提交前,事务写入的数据下游不可读;
2.预提交阶段:JobManager开始下发Checkpoint Barrier，当各个处理逻辑接收到barrier后停止处理后续数据，对当前状态制作快照，此时sink 也不在当前事务下继续处理数据。状态制作成功则向JM发送成功的消息，否则发送失败的消息;
3.提交阶段:若JM收到所有预提交成功的消息，则向所有处理逻辑（包括sink)发送可以提交此次事务的消息，sink接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据;若JM有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时sink 则丢弃这次事务提交的数据下
