一、数据流和动态表
1.传统sql与数据流的区别
sql处理的表是有界的，并且查询可以访问全部数据。而流处理是一个无限元组序列，查询访问不到所有的数据，且查询永不终止。
2.流处理流程
持续不断的数据流（Stream） -> 动态表（Dynamic Table） -> 连续的查询（Continuous Queries） -> 动态表 -> 处理后的数据流
3.在流上定义动态表
动态表:与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询它们。数据库表是INSERT、UPDATE和DELETE DML语句的stream 的结果，通常称为changelog stream.
当插入更多的流是，表会不断增长。
4.连续查询
- 查询永不终止
- 查询结果不断更新，产生一个心的动态表
- 在任何时候，连续查询的结果在语义上与以批处理模式在输入表快照上执行的相同查询的结果相同。
5.查询产生仅追加数据的动态表
将每一阶段查询的出局追加到原来的动态表里
7.retract消息的产生（同时包含 INSERT 消息和 DELETE 消息）
将每一阶段查询的数据拆成增加个删除，便于统计计数
8.状态
需要存储每个用户的URL计数，以便能够增加该计数并在输入表接收新行时发送新结果。
9.不同数据处理保证的语义
一致性保证语义
At-most-once：每条数据消费至多一次，处理延迟低
At-least-once：每条数据消费至少一次，一条数据可能存在重复消费
Exactly-once：每条数据都被消费且仅被消费一次，仿佛故障从未发生
二、Exactly-Once和CheckPoint
Flink的容错机制的核心部分是制作分布式数据流和操作算子状态的一致性快照。 这些快照充当一致性checkpoint，系统可以在发生故障时回滚。 Flink用于制作这些快照的机制在“分布式数据流的轻量级异步快照”中进行了描述。 它受到分布式快照的标准Chandy-Lamport算法的启发，专门针对Flink的执行模型而定制。
- Flink的检查点算法用到了一种称为分界线(barrier)的特殊数据形式，用来把一条流上数据按照不同的检查点分开
- 分界线之前到来的数据导致的状态更改，都会被包含在当前分界线所属的检查点中;
- 而基于分界线之后的数据导致的所有更改，就会被包含在之后的检查点中
barriers在数据流源处被注入并行数据流中。快照n的barriers被插入的位置（我们称之为Sn）是快照所包含的数据在数据源中最大位置。
例如，在Apache Kafka中，此位置将是分区中最后一条记录的偏移量。 将该位置Sn报告给checkpoint协调器（Flink的JobManager）。
然后barriers向下游流动。当一个中间操作算子从其所有输入流中收到快照n的barriers时，它会为快照n发出barriers进入其所有输出流中。
一旦sink操作算子（流式DAG的末端）从其所有输入流接收到barriers n，它就向checkpoint协调器确认快照n完成。
在所有sink确认快照后，意味快照着已完成。一旦完成快照n，job将永远不再向数据源请求Sn之前的记录，因为此时这些记录（及其后续记录）将已经通过整个数据流拓扑，也即是已经被处理结束。
三、Flink端到端的Exactly-Once语义
1.两阶段提交协议
类似于TCP/IP的四次握手
Coordinator：协作者，同步和协调所有节点处理逻辑的中心节点
Participant：参与者，被中心节点调度的其他执行处理逻辑的业务节点
预提交阶段
- 协作者向参与者发送一个commit消息；
- 每个参与的协作者收到消息后，执行事务，但是不真正提交;因为此时下游并不能读者这个结果
- 若事务成功执行完成，发送一个成功的消息（vote yes);执行失败，则发送一个失败的消息(vote no)
提交阶段
协作者接收到参与者返回的执行结果是否成功消息后
1．协作者向所有参与者发送一个rollback消息;
2．每个收到rollback消息的参与者回滚事务的执行操作，并释放事务所占资源;3．完成步骤2后，参与者发送一个ack消息给协作者;
4、协作者收到所有参与者的ack 消息后，标识该事务成功完成回滚。
2.Flink里的2PC Sink
- Flink 中协作者和参与者的角色分配
- 协作者（JobManager）发起阶段一提交
- 各算子 Checkpoint 的制作
- 提交阶段及 Checkpoint 的制作完成