Flink 原理与实现：Savepoint

喜欢ヅ旅行 2023-06-24 11:21 12阅读 0赞

扫码关注公众号免费阅读全文：**冰山烈焰的黑板报**  
![在这里插入图片描述][20200906232656299.jpg_pic_center]

Savepoint 和 Checkpoint 都是使用 Asynchronous Barrier Snapshotting（简称 ABS）算法实现分布式快照的，都可以确保一致性、容错、故障恢复。何其相似乃尔，却又为何既生瑜，又生亮？是无心之举，还是有意为之？且听下文分解。

# 1. What are savepoints? #

**Savepoint** 是 Flink 的一个非常独特的功能，类似于“瑞士军刀（Swiss Army knife）”的工具，可解决操作流应用程序的许多挑战。Savepoint 可以让你在某个指定的时间节点对整个流系统做快照。这个全局一致性快照（Global Consistent Snapshot）包含有关输入在数据源中所处位置的信息，以及有关源的所有位置和整个应用程序状态的信息。Savepoint 使用 Chandy-Lamport 算法的变体来获得整个状态的一致快照（可参考[Flink 原理与实现：Checkpoint][Flink _Checkpoint]），而无需停止应用程序。Savepoint 需要有两个主要元素：

1.  Savepoint 通常需要一个比较大的文件目录，用于存放发生在该 Savepoint 的整个流应用的全部 State 的二进制文件。
2.  一个相对较小的元数据文件，其中包含指向所有文件的指针（即，文件路径），这些文件是 Savepoint 的一部分，并存储在指定的分布式文件系统或数据存储中。

***Global Consistent*** 表示所有输入中，全部并行 Operator 的 State 在完全相同的明确位置被 Checkpoint。如果你有一个流系统某些时刻的 Savepoint，那么你就可以从这些 Savepoint 的位置处重启该应用程序。这个新的应用程序会用 Savepoint 中 Operator 的 State 进行初始化，同时从 Savepoint 中获取的输入源的位置，并从该位置处开始重新处理数据。由于 Flink 的 Savepoint 之间彼此是相互独立的，一个应用程序可以拥有多个 Savepoint。因此，你也可以用不同的 Savepoint，从多个不同的处理位置重新启动多个不同版本的应用程序。如下图：  
![图1 从不同 Savepoint 重启的不同应用程序][1 _ Savepoint]

# 2. When to use savepoints? #

流式处理应用程序处理的数据是无界的，意味着理论上会永远运行下去。但是，成也萧何败萧何，正是由于这种特性，也暗示着流式处理应用程序总会有挂掉的一天，因为网络超时、磁盘坏道、机器故障等，都需要从某个特定的位置处进行失败恢复。实际上，很多应用案例是需要应用程序重新处理之前的数据。而 Savepoint 一般会应用于以下场景中：

1.  部署一个应用程序的更新版本，比如，添加新功能、bugfix、更优的 Machine Learning Model。
2.  为应用程序引入 A/B 测试，使用相同的数据流测试程序的不同版本，从相同的时间点开始测试而不会牺牲先前的状态。
3.  对于不同资源，使用不同的并行度启动同一应用程序，然后将应用程序横向或横向扩展。
4.  将应用程序迁移到新版本的 Apache Flink，或者将应用程序升级到其他集群。
5.  暂停应用程序，释放集群资源给更高优先级的应用程序，稍后再重新启动，或者在输入流暂时不继续生产数据的时候。
6.  使用 Savepoint 进行版本化并存档应用程序的状态。

# 3. Savepoint vs Checkpoint #

**Savepoint** 和 [**Checkpoint**][Flink _Checkpoint] 是 Flink 两个特有的功能。Savepoint 和 [Checkpoint][Flink _Checkpoint] 在实现上是相似的，但是却存在着三方面的不同：

1.  **目的不同**。从概念上讲，Flink的 Savepoint 和 Checkpoint 的区别类似于备份与传统数据库系统中的恢复日志的区别。 Checkpoints 的主要目的是作为 Apache Flink 的恢复机制，以确保容错处理框架能够从潜在的作业失败中恢复。 相反，Savepoints 的主要目的是充当用户手动备份和恢复活动后重新启动，继续或重新开启已暂停的应用程序的方式。
2.  **实现方式不同**。Checkpoint 的设计是轻量级且快速的。它们可能（但不一定必须）利用底层状态后端的不同特性，并尽可能快地恢复数据。例如，RocksDB 状态后端增量检查点使用RocksDB 的内部格式，而不是 Flink 的本机格式。这有利于加速 RocksDB 的 Checkpoint 过程，使它们成为更轻量级检查点机制的第一个实例。相反，Savepoint 的设计更多地关注于数据的可移植性，并支持对作业所做的任何更改，这些更改会使生成和恢复工作的成本略微增加。
3.  **生命周期不同**。Checkpoint 是自动的和周期性的。它们由 Flink 自动地、定期地拥有、创建和删除，不需要任何用户交互，以确保在发生作业失败时能够完全恢复。相反，Savepoint 是由用户手动拥有和管理的(即，它们是有计划地创建的和删除的)。

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>Checkpoint</th> 
   <th>Savepoint</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>目的</td> 
   <td>从潜在的作业失败中恢复的机制</td> 
   <td>重新启动应用程序的人工备份</td> 
  </tr> 
  <tr> 
   <td>实现</td> 
   <td>轻量级且尽可能快速的恢复数据</td> 
   <td>关注于数据的可移植性，生成和恢复工作的成本更高</td> 
  </tr> 
  <tr> 
   <td>生命周期</td> 
   <td>无需任何人为干预，Flink 自动化管理</td> 
   <td>人工手动地创建和删除</td> 
  </tr> 
 </tbody> 
</table>

# 4. 总结 #

**Savepoint** 和 [**Checkpoint**][Flink _Checkpoint] 是 Apache Flink 两个不同的特性，可以适用于不同的需求，以确保一致性、容错、故障恢复。Savepoint 可用于 Upgrade，Bugfix、Migration、A/B Test。这两个特性结合使用效果更好，从而确保应用程序的状态在不同的场景和环境中保持不变。

[20200906232656299.jpg_pic_center]: https://img-blog.csdnimg.cn/20200906232656299.jpg#pic_center
[Flink _Checkpoint]: https://gatsbynewton.blog.csdn.net/article/details/103266504
[1 _ Savepoint]: https://img-blog.csdnimg.cn/20200301000110315.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTAzNzY3ODg=,size_16,color_FFFFFF,t_70