翻译自：3 differences between Savepoints and Checkpoints in Apache Flink
本文发布于Flink周五小贴士中，解释了保存点（Savepoints）和检查点（CheckPoints）是什么以及细究在Apache Flink中他们的主要不同点。在接下来段落中，我们解释了保存点是什么，应用场景以及与检查点不同点一对一的比较。
在Apache Flink中保存点和检查点是什么？
保存点是一个能让你对你的整个流应用提取一个时间点（point-in-time）快照的特性。这份快照包含你在输入中的何处的信息、Source中位置的信息和整个应用的状态。利用Chandy-Lamport算法的变体，我们可以在不停止应用的情况下，获得整个状态的持久性快照。保存点文件夹内包含两个主要元素：
- 一个拥有字节文件（通常很大），里面是在某一时刻检查点或保存点内流应用的所有状态。
- 一个元数据文件(相对较小)，包含存储在你选择的分布式文件系统或数据存储中的保存点所有文件的指针（路径）
上面描述的保存点的信息听起来和我们之前介绍过的检查点很像。检查点是Flink的内部机制用于从失败中恢复，包括应用状态的副本和对输入的处理位置。一旦失败，Flink通过从检查点中加载应用状态，然后像什么都没发生过一样从已经保存过的处理位置继续处理的方法来恢复应用。
保存点和检查点的3点不同
对Flink作为流输出框架而言，检查点和保存点是两个非常不同的的特征。保存点和检查点在他们的实现上看起来很像，但是，这两个特征在下面三点存在不同。
- 目标：概念上，Flink的保存点和检查点的不同比较像传统数据库系统中的恢复日志的实现（buckups）不同。检查点的主要目标是作为Flink的恢复机制保证一个处理容错框架可以从部分job失败中恢复。相反的，保存点的主要目标是由用户在手动维护后触发的应用重启等操作。
- 实现：检查点和保存点在实现上不同。检查点被设计称轻量而快速。他们经常（但是不是必须）使用下面状态后端的不同特征，尝试尽可以快的保存的保存数据。举个例子，使用RicksDB状态服务的增量检查点使用RocksDB的内部格式而不是FLink本身的格式。这被用来加速RocksDB的检查点处理，从而是他们成为第一个更轻量检查点机制的案例。相反，保存点被设计为更关注与数据的便携性，支持Job的任意修改，这会使得他们在生产和存储方面稍微重量级一点。
-
生命周期：检查点本质上是自动化和周期性的。他们被Flink自动而周期性的持有、创建和废弃，而不用用户干预，从而保证在意料外的失败后全部恢复。相反，保存点被用户手动持有和管理（例如调度、创建和删除）。
3 differences between savepoints and checkpoints in Flink
什么时候在你的流应用中使用保存点
尽管一个流数据处理应用处理持续产生的数据（data “in motion”）,还是有一些需要重复处理之前已经处理过的数据的案例。Flink中的保存点可以在以下场景中做到这一点：
- 为你的流应用更新版本，包括新的功能、bug修复或者更好的机器学习模型
- 为你的应用引入A/B测试，测试使用同一个数据源但不同版本的应用，从同一点启动测试应用而不用牺牲之前的状态。
- 在需要更多资源时，扩容你的应用
- 迁移你的应用到一个新版本的Flink，或者更新你的应用到其他的集群
注册Flink的Public Traning可以从中获得关于怎样为上述案例使用保存点的手把手的指导
结论
检查点和保存点是Flink中两个不同的特征来满足不同的需求来保证持久性、容错还有无论在期望外的Job失败（使用检查点）和常规的的升级、bug修复、迁移或A/B测试（使用保存点）情况下状态被持久化。这两个特征一起用让你能够在不同的情况下保证你的应用状态在不同的场景下被持久化。
