一般来说，分布式数据集容错有两种方法：数据检查点和更新日志数据。
大数据分析要求高数据检查点运营成本，并通过数据中心的网络连接在计算机之间复制大量数据集。 在许多情况下，网络带宽远远低于内存带宽，而且还需要占用更多的存储资源。
因此，Spark选择更新记录的方法。 但是，如果更新的粒度太细，记录更新成本也不低。 因此，RDD只支持粗粒度转换。 也就是说，只记录在一个块中执行的一个操作，并创建RDD的一系列转换序列。 每个RDD都包含有关如何从其他RDD转换以及如何重建一个块中的数据的信息。 因此，RDD容错又称“血统”容错，是为了恢复丢失的分区而记录的。
Lineage本质上类似于数据库中的重做日志，但此重做日志粒度较大，可以通过对全局数据执行相同的重做来恢复数据。
Lineage机制Lineage配置文件与其他系统粒度较细的内存数据更新级别的备份或日志机制相比，RDD的Lineage提供了粒度较粗的特定数据传输操作(例如，过滤器、日志机制) 如果此RDD的部分分区数据丢失，则可以在Lineage中获取足够的信息，重新计算和恢复丢失的数据分区。 由于这种粗粒子数据模型限制了Spark的运行场景，因此Spark并不适用于所有的高性能要求场景，但同时带来了比细粒子度数据模型更好的性能。
两种依赖关系RDD在Lineage依赖方面可分为两类： Narrow Dependencies和Wide Dependencies，源代码中称为Shuffle
Dependencies )解决数据容错的效率。
狭窄的依赖关系意味着父RDD中的每个分区最多由一个子RDD的分区使用，而父RDD中的分区对应于一个子RDD中的分区
或者，多个父RDD的分区与一个子RDD的分区相对应。 这意味着父RDD的一个分区不能与一个子RDD的多个分区相对应。
一个父RDD分区对应于一个子RDD分区，其中还有两个。 一个子RDD分区对应于一个父RDD分区(例如，运算符map、filter等)，而一个子RDD分区对应于n个父RDD分区(例如，协同划分的Join )
宽依赖关系意味着子RDD的分区依赖于父RDD的多个分区或所有分区，这意味着父RDD的一个分区支持子RDD的多个分区。
一个父RDD分区对应于多个子RDD分区，其中一个父RDD对应于所有子RDD分区(未联合拆分的Join )，以及一个父RDD不是全部的多个RDD分区(例如
容错原理在容错中，如果一个节点冻结，运算依赖较窄，则只需重新计算丢失的父RDD分区即可，不依赖于其他节点。 另一方面，广泛的依赖关系包含需要父RDD的所有分区，重新计算成本很高。 可以理解为，如果开销的经济性是子RDD分区丢失并重新计算父RDD分区，则父RDD中相应分区的所有数据都是子RDD分区的数据，而不存在冗馀计算。 在宽相关性情况下，每个父RDD中失去一个子RDD分区重新计算的每个父RDD分区的所有数据并不用于丢失的子RDD分区，有些数据对应于未丢失的子RDD分区所需的数据这也是宽依赖开销更大的原因。 因此，在使用Checkpoint操作符创建检查点时，不仅要考虑Lineage是否足够长，还必须考虑是否存在广泛的依赖，在广泛的依赖中加入Checkpoint是最有价值的。
上述分析表明，在以下两种情况下，Checkpoint机制需要向RDD中添加检查点：
DAG的Lineage太长，重新计算的话开销太大了。 例如，PageRank的情况。
在广泛的依赖关系下进行检查点获得的利益更大。
由于RDD是只读的，因此Spark的RDD计算中一致性不是主要关注的问题，内存相对容易管理也是设计者的远见。 这样可以降低框架的复杂性，提高性能和可扩展性，为今后高级框架的丰富性奠定强大的基础。
RDD计算通过检查点机制进行容错。 传统上，执行检查点有两种方法：冗馀数据和日志记录更新操作。 RDD中的doCheckPoint方法相当于用冗馀的数据缓存数据，但前面介绍的血统通过相当粗粒度的记录更新操作实现了容错。
检查点(本质上是通过将RDD写入磁盘来创建检查点)是为了在lineage中辅助容错。 如果lineage太长，容错成本就会太高，所以最好在中间阶段建立检查点容错机制。 然后，如果节点出现问题而丢失分区，则从创建了检查点的RDD重新创建lineage将减少开销。
一个流应用程序往往需要7*24之间不间断的奔跑，因此需要抵御意外的能力。 例如，机器或系统锁定、JVM crash等)。 为了实现这一点，Spark Streaming要求checkpoint向设计灵活的存储系统提供足够的信息，以便从失败中恢复应用程序。 Spark Streaming检查点两种类型的数据。
元数据检查-在类似的HDFS中存储定义了流计算逻辑的容错存储系统。 用于恢复驱动程序，元数据如下：
配置-使用
创建该 streaming application 的所有配置DStream 操作 - DStream 一些列的操作
未完成的 batches - 那些提交了 job 但尚未执行或未完成的 batches
Data checkpointing - 保存已生成的RDDs至可靠的存储。这在某些 stateful 转换中是需要的，在这种转换中，生成 RDD 需要依赖前面的 batches，会导致依赖链随着时间而变长。为了避免这种没有尽头的变长，要定期将中间生成的 RDDs 保存到可靠存储来切断依赖链 什么时候需要启用 checkpoint？
满足以下任一条件：
使用了 stateful 转换 - 如果 application 中使用了updateStateByKey或reduceByKeyAndWindow等 stateful 操作，必须提供 checkpoint 目录来允许定时的 RDD checkpoint
希望能从意外中恢复 driver
如果 streaming app 没有 stateful 操作，也允许 driver 挂掉后再次重启的进度丢失，就没有启用 checkpoint的必要了。