Checkpoint | 青训营笔记

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

什么是Checkpoint

Checkpoint是Flink的检查点，是根据配置文件周期性基于Stream中各个Operator的状态而产生的全局性的SnapShot快照。然后定期持久化的存储到一些外设中，一旦Flink程序出现崩溃状态，则可以通过选择这些SnapShot快照进行快速恢复，从而修正因故障所产生的程序数据中断问题。

一致性保证语义

• At-most-once：每条数据消费至多一次，处理延迟低
• At-least-once：每条数据消费至少一次，一条数据可能存在重复消费
• Exactly-once：每条数据都被消费且仅被消费一次，仿佛故障从未发生

Checkpoint

1. Checkpoint barrier 的下发

开始：JobManager同时对所有的Source发送Checkpoint Barrier;

2. 算子状态制作和 barrier 传递

反馈：各个Source短暂的暂停处理并将自己的状态保存后，向所有连接的下游继续发送Checkpoint Barrier并向JobManager反馈自己的状态已经制作完成;

3. 多个上游的等待 barrier 对齐现象

分界线对齐（Barrier Alignment）：

• 算子会等待上游的barrier到达后才开始快照的制作;
• 已经制作完成的上游算子会继续处理数据，并不会被下游算子制作快照的过程阻塞；

4. 快照制作与处理数据的解耦

• Checkpoint 并不阻塞算子数据处

• Checkpoint ACK和制作完成

课后

1. 流式处理中算子为什么会有状态？

• Flink 需要了解状态，以便使用检查点和保存点使其容错。

2. 数据流和动态表之间是如何进行转换的？ 表 ---> 流：

• Append-onlay流： 仅通过insert 操作修改的动态表可以通过输出插入的行转换为流。
• Retrac流：Retract流包含两种类型的message: add messages和retrace message. 通过镜insert 操作编码为add message， 将delete操作编码为retract message, 将update 操作编码为(先前)更新的retract message和（新）更新的行add message. 将动态表转换为retract流。
• upsert流： upsert流包含两种类型的message: upsert message he deletemessage. 转换为upsert流的动态表需要（可能是组合的）唯一键。 通过将insert 和update 操作编码为upsert message, 将delete 操作编码为delete message， 将具有唯一键的动态表转换为流。 消费流的算子和需要知道唯一键的属性， 以便正确的应用message, 与retract流主要的区别在于update操作是用单个message编码的，因此效率更高。 流 ---> 表：
• 通过一个只有插入操作（insert-only）的更新日志（changelog）流，来构建一个表。

3. Flink 作业为什么需要考虑故障恢复？

• 作为生产环境的flink，我们期待做到快速failover、弹性扩缩容和平滑迁移，尽量做到用户无感知和变更方便，从而让用户将更多精力放在功能实现上。

4. Flink 故障恢复前为什么需要Checkpoint？

• Checkpoint是一种分布式快照，在某一时刻，对一个Flink作业中所有task做一个快照，并且保存在memory/file system等存储系统中，在任务进行故障恢复的时候，可以还原到任务故障前最近一次检查点的状态。

5. 为什么不能保留任意时刻的状态作为故障恢复的时间点？

• 检查点作为应用状态的一份存档，其实就是所有任务状态在同一时间点的一个快照（snapshot），它的触发是周期性的。

6. Flink Checkpoint 对作业性能的影响有多大？

• 强大的 checkpoint 机制，使它在获取高吞吐量性能的同时，也能保证 Exactly Once 级别的快速恢复。