这是我参与「第四届青训营 」笔记创作活动的的第3天
传统SQL和流处理
动态表：与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询它们。
连续查询：①查询从不停止 ②查询结果会不断更新，产生一个新的动态表。 在任何时候，连续查询的结果在语义上于以批处理模式在输入表快照上执行的相同查询的结果相同。
不同数据处理保证的语义
1、At-most-once：出现故障的时候，啥也不做。数据处理不保证任何语义，处理时延低； 2、At-least-once：保证每条数据均至少被处理一次，一条数据可能存在重复消费 3、Exactly-once：最严格的处理语义，从输出结果来看，每条数据均被消费且仅消费一次，仿佛故障从未发生。
状态恢复的时间点：需要等待所有处理逻辑消费完成source保留状态及之前的数据。 一个简单的快照制作方法：①暂停处理输入的数据②等待后续所有处理算子消费当前已经输入的数据③待上一步处理完后，作业所有算子复制自己的状态并保存到远端可靠存储④恢复对输入数据的处理
Chandy-Lamport算法
Checkpoint对作业性能的影响： 1、解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子制作完成快照 2、在快照制作和Barrier Alignment过程中需要暂停处理数据，仍然会增加数据处理延迟 3、快照保存到远端也有可能极为耗时
CheckpointCoordinator周期性的向该流应用的所有source算子发送barrier。 当某个source算子收到一个barrier时，便暂停数据处理过程，然后将自己的当前状 态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告 自己快照制作情况，同时向自身所有下游算子广播该barrier，恢复数据处理 下游算子收到barrier之后，会暂停自己的数据处理过程，然后将自身的相关状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自身 快照情况，同时向自身所有下游算子广播该barrier，恢复数据处理。 每个算子按照步骤3不断制作快照并向下游广播，直到最后barrier传递到sink算子，快照制作完成。 当CheckpointCoordinator收到所有算子的报告之后，认为该周期的快照制作成功; 否则，如果在规定的时间内没有收到所有算子的报告，则认为本周期快照制作失败
