这是我参与「第四届青训营」笔记创作活动的第三天
课程中用到的专有名词释义 :
- Stream: 数据流
- Dynamic Table: 动态表
- Continuous Queries: 连续查询
- Append-only Stream: Append-only 流（只有 INSERT 消息）
- Retract Stream: Retract 流（同时包含 INSERT 消息和 DELETE 消息）
- Upsert Stream:: Upsert 流（同时包含 UPSERT 消息和 DELETE 消息）
- Changelog: 包含 INSERT/UPDATE/DELETE 等的数据流
- State: 计算处理逻辑的状态
- Application Consistency Guarantees: 作业一致性保证
- At-most-once：每条数据消费至多一次
- At-least-once：每条数据消费至少一次
- Exactly-once: 每条数据都被消费且仅被消费一次
- Checkpoint: Flink 实现各个计算逻辑状态快照算法，也可指一次状态快照
- Checkpoint barrier: 用于标识状态快照的制作，也将数据划分成不同的消费区间
- Checkpoint Alignment: 等待多个上游的Checkpoint barrier到达的现象
- JobManager: 负责协调和管理 Checkpoint
- Two-phase commit protocol: 两阶段提交协议
- Transaction: 一系列保证原子性操作的集合，即操作同时执行或者都不执行
- Kafka: 消息中间件
- State Backend: 用于管理和保存状态到远端可靠存储
- Deduplication：去重，在 state 保留的时间内对重复消息进行去重
- Aggregation：聚合操作，比如求和、求最大值等
一、数据流和动态表
1.1 传统的SQL和流处理
1.2 数据流和动态表转换
- 数据流和动态表的转换关系图
- 动态表：与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询它们。数据库表是INSERT、UPDATE和DELETE DML语句的stream的结果，通常称为changelog stream。
上图显示了单机事件流（左侧）如何转换为表（右侧），当插入更多的单机流记录时，结果表将不断增长。
1.3 连续查询
-
查询从不终止
-
查询结果会不断更新，并且会产生一个新的动态表
-
结果的动态表也可转换成输出的实时流
-
查询产生仅追加数据的动态表
- 上述两图的连续查询对比
- 虽然这两个示例查询看起来非常相似（都计算分组计数聚合)，但它们在一个重要方面不同：
- 1.第一个查询更新先前输出的结果，即定义结果表的changelog流包，含INSERT和UPDATE操作；
- 2.第二个查询只附加到结果表，即结果表的changelog流只包含INSERT操作。
1.4 状态
需要存储每个用户的山RL计数，以便能够增加该计数并在输入表接收所行时发送所结果。
1.5 数据流和动态表转换总结
- 1.数据流和动态表之间的转换；
- 2.在数据流的查询不会终止；
- 3.查询可能会有状态，用来不断更新查询的结果。
1.6 不同数据处理保证的语义
当数据流和动态表转换查询运行中出现故障怎么办？—— 一致性保证语义！
- 1.At-most-once:出现故障的时候，啥也不做。数据处理不保证任何语义，处理时延低：
- 2.At-east-once:保证每条数据均至少被处理一次，一条数据可能存在重复消费。
- 3.Exactly-once:最严格的处理语义，从输出结果来，每条数据均被消费且仅消费一次，仿佛故障从末发生。
二、Exactly-Once 和 Checkpoint
- Exactly-once：每条数据都被消费且仅被消费一次，仿佛故障从未发生
- Checkpoint: Flink 实现各个计算逻辑状态快照算法，也可指一次状态快照
- Checkpoint barrier: 用于标识状态快照的制作，也将数据划分成不同的消费区间
- Checkpoint Alignment: 等待多个上游的Checkpoint barrier到达的现象
- JobManager: 负责协调和管理 Checkpoint处。
2.1 Checkpoint对作业性能的影响
- 1.解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子制作制作完成快照；
- 2.在快照制作和Barrier Alignment过程中需要暂停处理数据，仍然会增加数据处理延迟；
- 3.快照保存到远端也有可能极为耗时。
三、Flink端到端的Exactly-once语义
3.1 端到端的Exactly-once语义
- 1.Checkpoint能保证每条数据都对各个有状态的算子更新一次，sink输出算子仍然可能下发重复的数据；
- 2.严格意义的端到端的Exactly-once语义需要特殊的sink算子实现。
3.2 两阶段提交协议
在多个节点参与执行的分布式系统中，为了协调每个节点都能同时执行或者回滚某个事务性的操作，引入了一个中心节点来统一处理所有节点的执行逻辑，这个中心节点叫做协作者(coordinator),被中心节点调度的其他业务节点叫做参与者(participant)。
3.2.1 两阶段提交协议（一）—— 预提交阶段
- 1.协作者向所有参与者发送一个commit消息；
- 2.每个参与的协作者收到消息后，执行事务，但是不真正提交；
- 3.若事务成功执行完成，发送一个成功的消息(vote yes);执行失败，则发送一个失败的消息(vote no)
3.2.2 两阶段提交协议（二）—— 提交阶段
- 若协作者成功接收到所有的参与者vote yes的消息：
- 1.协作者向所有参与者发送一个commit消息；
- 2.每个收到coit消息的参与者释放执行事务所需的资源，并结束这次事务的执行；
- 3.完成步骤2后，参与者发送一个ack消息给协作者；
- 4.协作者收到所有参与者的ack消息后，标识该事务执行完成。
- 若协作者有收到参与者vote no的消息（或者发生等待超时）
- 1.协作者向所有参与者发送一个rollback消息；
- 2.每个收到rollback消息的参与者回滚事务的执行操作，并释放事务所占资源；
- 3.完成步骤2后，参与者发送一个ack消息给协作者；
- 4.协作者收到所有参与者的ack消息后，标识该事务成功完成回滚。
3.3 Flink两阶段提交总结
- 1.事务开启：在sink task向下游写数据之前，均会开启一个事务，后续所有写数据的操作均在这事务中执行，事务未提交前，事务写入的数据下游不可读；
- 2.预提交阶段：JobManager开始下发Checkpoint Barrier,当各个处理逻辑接收到barrier后停止处理后续数据，对当前状态制作快照，此时sink也不在当前事务下继续处理数据（处理后续的数据需要新打开下一个事务）。状态制作成功则向JM成功的消息，失败则发送失败的消息；
- 3.提交阶段：若JM收到所有预提交成功的消息，则向所有处理逻辑（包括sink）)发送可以提交此次事务的消息，sink接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据；若JM有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时sink则丢弃这次事务提交的数据下。
四、Flink案例讲解
从Kafka中读取账单消息，进行处理后写入到MySQL中
-
执行步骤：
- 1.在上次记录的位点之后，从Kafka中读取固定大小的数据；
- 2.对该批数据进行去重和聚合计算；
- 3.处理完成后写入Mysq中，若全部写入成功，则记录下当前读取到的消息的终止位置；若处理或者写入失败，则不记录位点；
- 4.跳回步骤1
-
存在的问题：
- 1.非严格意义上的端到端的Exactly-Once语义：若该批数据处理完成后，在写入MySQL中发生异常，存在部分数据写入的情况，下次作业启动后，这部分数据仍然会垂复写入；
- 2.去重能力有限：只能在当前处理的一批数据内进行去重，无法在批与批之间进行去重；
- 优势：
- 1.严格意义上的端到端的Exactly-Once语义：下游读到的数据是不丢不重的：
- 2.赠强的去重能力：可以在更长的时间维度对数据进行去重。
