我有兴趣了解Spark如何实现容错。在他们的paper中，他们描述了他们是如何为狭隘的依赖关系而做的。喜欢相当直接的地图。但是，如果节点在像排序操作这样的广泛依赖之后崩溃，我们就不会说明他们做了什么。我唯一能找到的是：
相反，在具有广泛依赖关系的沿袭图中，单个故障节点可能会导致RDD的所有祖先丢失某个分区，需要完全重新执行。
这对于了解发生的事情并不足够。
排序后，没有办法知道存储在崩溃节点上的数据来自何处，而不存储一些额外信息。因此，如果在排序后发生崩溃，是否重新执行了整个血统，或者是否存在一些减少计算开销的机制？那么其他广泛的依赖呢？
答案 0 :(得分：1)
RDD依赖项实际上是根据分区以及如何从其他RDD的分区创建的。
宽依赖性表示创建分区所需的数据是从多个分区（来自相同或不同的RDD）获得的。 每个分区都分配了一个执行程序。
现在假设，我们正在加入两个分别具有 n 和 m 分区的RDD R1和R2。另外，为简单起见，我们假设R1和R2都是由（n×m）不同的执行器计算的。 我们将通过加入R1和R2来创建第三个RDD R3。
在计算R3时，假设包含 x 执行程序的节点（（n x m）执行程序中的节点）由于某种原因失败。 它不会影响剩余的执行者及其他节点上的数据。
只有R3 中那些应该从那些失败的 x 执行程序数据创建的分区才会受到影响。只重新创建 x 分区。
有更详细的视觉解释here
已更新：关于Spark缓存 URL下面应该可以帮助您理解Spark的整个持久性功能