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

一、 传统SQL和流处理： SQL：处理表是有界的；执行查询可以访问完整的数据；批处理查询产生固定大小结果后终止。 流处理：流是一个无限元组序列；执行查询无法放稳所有的数据；查询不断更新结果，永不终止。

动态表：与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询他们。

连续查询：查询从不终止；查询结果会不断更新，产生一个新的动态表。 状态：需要储存每个用户的url计数，以便能够增加该计数并在输入表接受新行时发送新结果。 数据流和动态表转换： Stream->Dyamic Table->Coutiuous Query->Dynamic Table->Stream。

不同数据处理保证的语义： At-most-once:出现故障时，啥也不做。数据处理不保证任何语义，处理时延低。 At-least-once:保证每条数据均至少被处理一次，一条数据可能存在重复消费。 Exactly-once:最严格的处理语义，从输出结果来看，每条数据均被消费且仅消费一次，仿佛故障从未发生。

二、 账单计算服务：场景简介 从Kafka中读取账单信息，进行处理后写入到MySQL中。 1.在上次记录的位点之后，从Kafka中读取固定大小的数据。 2.对该批数据进行去重和聚合计算。 3.处理完成后写入Mysql中，若全部写入成功，则记录下当前读取到的消息的终止位置；若处理或者写入失败，则不记录位点。 4.跳回步骤一。 问题： 1.去重能力有限；只能在当前处理的一批数据内进行去重，无法在批与批之间进行去重。 优势： 1.严格意义上的端到端的Exactli-Once语义：下游读到的数据是不丢不重的。 2.增强的去重能力：可以在更长的时间维度对数据进行去重。 三、总结 数据流可以转换成动态表，动态表也能重新转换成数据流 处理无限数据流的算子可以是有状态的 Flink通过Checkpoint机制实现故障前后的状态快照制作和恢复 支持两阶段提交协议的下游储存可以结合Flink Checkpoint机制实现严格意义上端到端的Exactly-Once语义实现。