深入研究RDD内部结构及数据更新恢复机制

在Spark核心开发一章中，读者已经接触了Spark为开发者所提供的诸多操作接口，也尝试了使用这些接口来做应用开发，但这对于理解Spark的内部工作机制来说，还远远不够。RDD作为Spark中最为重要的一类数据抽象，同时也是Spark程序开发者接触最多的数据结构，自然也就成为理解Spark工作原理的入口之一。

RDD的全称为Resilient Distributed Datasets，即弹性分布式数据集。数据集顾名思义，说明RDD是数据集合的抽象，从外部来看，RDD的确可被看成带扩展特性（如容错性等）的数据集合；分布式则能够理解成数据的计算并非只局限于单个节点，而是通过多个节点之间的协同计算得到；RDD内部数据是只读的，但RDD却具有弹性这一特性，实际上，RDD可以在不改变内部存储数据记录的前提下，去调整并行计算计算单元的划分结构，弹性这一特性，自然也是为并行计算服务的。因此，在讲解RDD之前，我们需要记住一个重要概念：RDD是并行计算的数据集。之后，还需要考虑一些设计上需要思考的问题。

首先，前文提及到了并行计算的计算单元，那么在RDD里面，这些单元应该如何表示更为合适？既然要进行并行计算，自然希望计算单元能够尽可能地均匀分配，从而保证集群资源能够被合理利用，那么RDD内部数据的划分依据又是什么？这些计算单元又该如何被计算？(www.xing528.com)

再者，分布式数据集往往需要具备一个重要特性，即容错性，分布式条件下数据的丢失可能会很常见，这时候就需要Spark能够通过某种机制来恢复丢失的数据，从而保证数据的的可靠性和完整性。传统方法的容错机制有两种，一是创建数据检查点，即将某个节点的数据保存在存储介质当中；二是记录更新，即记录下内部数据所遭遇过的所有的更新。对于前者，在网络中传输与复制数据集的带宽开销显然是非常庞大的，对于后者，如果要记录每一个数据记录的所有更新，成本自然也是不小。通过前面对RDD的学习，了解到Spark最终采用的是第二种办法，而为了避免巨大的开销，RDD只支持粗粒度的转换操作，一个操作会应用到多个数据而非单个记录。那么，在RDD内部，如何去记录数据的更新，丢失的数据又是通过何种方式恢复的呢？

本章会围绕着这些问题，深入到RDD的源码内部，通过研究RDD各个接口的实现，从而理解ApacheSpark的设计者们是如何设计RDD这一数据抽象的。