spark学习笔记5 spark容错性

一般来说，分布式数据集的容错性有两种方式：数据检查点和记录数据的更新。 面向大规模数据分析，数据检查点操作成本很高，需要通过数据中心的网络连接在机器之间复制庞大的数据集，而网络带宽往往比内存带宽低得多，同时还需要消耗更多的存储资源。 因此，Spark选择记录更新的方式。 但是，如果更新粒度太细太多，那么记录更新成本也不低。 因此，RDD只支持粗粒度转换，即在大量记录上执行的单个操作。 将创建RDD的一系列Lineage（即血统）记录下来，以便恢复丢失的分区。Lineage本质上很类似于数据库中的重做日志（Redo Log），只不过这个重做日志粒度很大，是对全局数据做同样的重做进而恢复数据。

1、Lineage机制

1、简介

RDD的Lineage记录的是粗颗粒度的特定数据Transformation操作（如filter、 map、 join等）行为。 当这个RDD的部分分区数据丢失时，它可以通过Lineage获取足够的信息来重新运算和恢复丢失的数据分区。 因为这种粗颗粒的数据模型，限制了Spark的运用场合，所以Spark并不适用于所有高性能要求的场景，但同时相比细颗粒度的数据模型，也带来了性能的提升。

2、两种依赖

Narrow Dependencies是指父RDD的每一个分区最多被一个子RDD的分区所用，表现为一个父RDD的分区对应于一个子RDD的分区或多个父RDD的分区对
应于一个子RDD的分区，也就是说一个父RDD的一个分区不可能对应一个子RDD的多个分区。 Shuffle Dependencies是指子RDD的分区依赖于父RDD的多个分区或所有分区，即存在一个父RDD的一个分区对应一个子RDD的多个分区。

对于Shuffle Dependencies，当容错重算分区时，因为父分区数据只有一部分是需要重算子分区的，其余数据重算就造成了冗余计算。

对于Shuffle Dependencies，Stage计算的输入和输出在不同的节点上，对于输入节点完好，而输出节点死机的情况，通过重新计算恢复数据这种情况下，这种方法容错是有效的，否则无效，因为无法重试，需要向上追溯其祖先看是否可以重试（这就是lineage，血统的意思），Narrow Dependencies对于数据的重算开销要远小于Wide Dependencies的数据重算开销。

3、容错原理

在Narrow Dependency中，在子RDD的分区丢失、 重算父RDD分区时，父RDD相应分区的所有数据都是子RDD分区的数据，并不存在冗余计算。 在Shuffle Dependency情况下，丢失一个子RDD分区重算的每个父RDD的每个分区的所有数据并不是都给丢失的子RDD分区用的，会有一部分数据相当于对应的是未丢失的子RDD分区中需要的数据，这样就会产生冗余计算开销，这也是ShuffleDependency开销更大的原因。

在Lineage足够长，存在宽依赖的情况下，对Shuffle Dependency加Checkpoint是最物有所值的，可以节约大量的系统资源。

Checkpoint算子的检查点（本质是通过将RDD写入Disk做检查点）是为了通过Lineage做容错的辅助，lineage过长会造成容错成本过高，这样就不如在中间阶段做检查点容错，如果之后节点出现问题而丢失分区，从做检查点的RDD开始重做lineage，就会减少开销。下面具体介绍checkpoint机制。

4、CheckPoint机制

通过上述分析可以看出在以下两种情况下，RDD需要加检查点。
1）DAG中的Lineage过长，如果重算，则开销太大（如在PageRank中）。
2）在Shuffle Dependency上做Checkpoint（检查点）获得的收益更大。

在RDD中的doCheckPoint方法相当于通过冗余数据来缓存数据，而之前介绍的血统就是通过相当粗粒度的记录更新操作来实现容错的。

可以通过SparkContext.setCheckPointDir（）设置检查点数据的存储路径，进而将数据存储备份，然后Spark删除所有已经做检查点的RDD的祖先RDD依赖。 这个操作需要在所有需要对这个RDD所做的操作完成之后再做，因为数据会写入持久化存储造成I/O开销。做检查点的RDD最好是在内存中已经缓存的RDD，否则保存这个RDD在持久化的文件中需要重新计算，产生I/O开销。