Spark RDD 论文详解（一）摘要和介绍
前言
本文隶属于专栏《1000个问题搞定大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！
本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系
目录
Spark RDD 论文详解（一）摘要和介绍
Spark RDD 论文详解（二）RDDs
Spark RDD 论文详解（三）Spark 编程接口
Spark RDD 论文详解（四）表达 RDDs
Spark RDD 论文详解（五）实现
Spark RDD 论文详解（六）评估
Spark RDD 论文详解（七）讨论
Spark RDD 论文详解（八）相关工作和结尾
思维导图
正文
这里分享一下 RDD 论文下载链接：
Resilient Distributed Datasets: A Fault-tolerant Abstraction for In-memory Cluster Computing
标题
Resilient Distributed Datasets: A Fault-tolerant Abstraction for In-memory Cluster Computing
从标题就可以看出，RDD 虽然翻译过来是弹性分布式数据集，但是更进一步的解释是：一个用于内存集群计算的容错抽象。
摘要
原文翻译
我们提出了弹性分布式数据集（RDDs）这个概念，这是一个分布式的内存抽象，它可以让程序员以容错的方式在大型集群上进行内存计算。
当前（2012 年）的计算框架在处理迭代式算法场景与交互性数据挖掘场景时性能非常差，这个是 RDDs 提出的动机。
如果能将数据保存在内存中，将会使得上面两种场景的性能提高一个数量级。
为了能达到高效的容错，RDDs 提供了一种受限制的共享内存的方式，这种方式是基于粗粒度的转换共享状态而非细粒度的更新共享状态。
然而，我们分析表明 RDDs 可以表达出很多种类的计算，包括目前专门从事迭代任务的编程计算模型，比如 Pregel，当然也可以表达出目前模型表达不出的计算。
我们通过 Spark 系统来实现了 RDDs，并且通过各种各样的用户应用和测试来评估了这个系统。
解析
为了更好的理解上面的摘要，这里介绍一下 Apache Spark 的历史背景。
Apache Spark 来源于加州大学伯克利分校 2009 年的 Spark 研究项目，该校 AMPLab 实验室在 2010 年发表了题为：Spark：Cluster Computing with Working Sets 的论文。
这篇论文的下载链接在这里——Spark：Cluster Computing with Working Sets
在当时，Hadoop MapReduce 是运行在计算机集群上的主要并行计算引擎，是第一个在数千个节点集群上进行并行数据处理的开源系统。
AMPLab 曾与多位早期的 MapReduce 用户合作，以了解这种新编程模型的优缺点，因此能够针对多个实际中的问题，开始设计更通用的计算平台。
此外，他们还与加利福尼亚大学伯克利分校的 Hadoop 用户合作，了解他们对平台的需求，特别是使用迭代算法进行大规模机器学习的团队，他们需要对数据进行多次迭代处理。
在于 MapReduce 用户的交流中，有两件事很确定。
1. 集群计算具有巨大的潜力。
在使用 MapReduce 的每个组织机构中，可以使用现有数据构建全新的应用程序，并且许多研究组在尝试了入门示例后开始使用该系统。
2. MapReduce 引擎构建大型应用程序既具有挑战性又低效。
例如，典型的机器学习算法可能需要对数据进行 10 次或20 次迭代处理，而在 MapReduce 中，每次迭代都必须通过一个 MapReduce 作业来完成，必须在分布式集群上重新读取全部数据并单独启动一次作业。
为了解决这个问题，Spark 团队首先设计了一个基于函数式编程的 API，可以简洁的表达多计算步骤的应用程序。
然后，该团队通过一个新的引擎实现了这个 API，该引擎可以跨多个计算步骤执行高效的内存数据共享。
该团队还开始与伯克利分校和校外用户一起测试该系统。
1、介绍
原文翻译
像 MapReduce 和 Dryad 等分布式计算框架已经广泛应用于大数据集的分析。
这些系统可以让用户不用担心分布式工作以及容错，而是使用一系列的高层次的操作 API 来达到并行计算的目的。
虽然当前的框架提供了大量的对访问利用计算资源的抽象，但是它们缺少了对利用分布式内存的抽象。
这样使得它们在处理需要在多个计算之间复用中间结果的应用的时候会非常的不高效。
数据的复用在迭代机器学习和图计算领域（比如 PageRank，K-means 以及线性回归等算法）是很常见的。
在交互式数据挖掘中，一个用户会经常对一个相同的数据子集进行多次不同的特定查询，所以数据复用在交互式数据挖掘也是很常见的。
然而，目前的大部分的框架对计算之间的数据复用的处理方式就是将中间数据写到一个可靠稳定的系统中（比如分布式文件系统），这样会由于数据的复制备份，磁盘的 I/O 以及数据的序列化而致应用任务执行很费时间。
认识到这个问题后，研究者们已经为一些需要中间数据复用的应用开发出了一些特殊的框架。
比如Pregel 在做迭代式图计算的时候会将中间结果放在内存中。
HaLoop 也提供了迭代式 MapReduce 接口。
然而，这些框架仅仅支持一些特殊的计算模式（比如循环一系列的 MapReduce 步骤），并且它们是隐式的为些计算模式提供数据共享。
它们没有提供更加普遍数据复用的抽象，比如可以让用户加载几个数据集到存中然后对这些内存中的数据集进行专门的查询。
在这篇论文中，我们提出了一个全新的抽象，叫做 RDDs，它可以高效的处理广泛的应用中涉及到的数据用的场景。
RDDs 是一个可以容错且并行的数据结构，它可以让用户显式的将中间结果数据集保存在内存中，可以控制数据集的分区来达到数据存放处理最优以及可以使用丰富的操作 API 来操作数据集。
在设计 RDDs 的时候，最大的挑战是定义一个可以高效容错的编程接口。
已经存在的分布式内存抽象系统比如 distributed shared memory、key-value stores、databases 以及 Poccolo，都是提供了基于粒度的更新可变状态（比如 table 中的 cells）的接口。
基于这种接口下，保证容错的方式无非是将数据复备份到多台机器或者在多台机器上记录更新的日志，这两种方式在数据密集性的工作任务中都是非常的耗时的，因为需要通过网络传输在机器节点间复制大量的数据，宽带传输数据的速度远远比 RAM 内存慢，而这两种方式会占用大量的存储空间。
与这些系统相反，RDDs 提供了基于粗粒度转换（比如 map，filter 以及 join）的接口，这些接口可以对多条数据条目应用相同的操作。
这样就可以通过记录来生成某个数据集的一系列转换（就是这个数据集的 lineage ，中文翻译血缘）而不是记录真实的数据来达到提供高效的容错机制。
这个 RDD 就有足够的信息知道它是从哪个 RDDs 转换计算来的，如果一个 RDD 的分区数据丢失掉了，那么重新计算这个 RDD 所依赖的那个 RDD 对应的分区就行了。
因此可以很快且不用通过复制备份方式来恢复丢失的数据。
虽然基于粗粒度的转换一开始看起来受限制，但是 RDDs 非常适合很多并行计算的应用，因为这些应用基本都是在大量的数据元素上应用相同的操作方法。
事实上，我们分析表明 RDDs 不仅可以高效的表达出目前括 MapReduce，DryadLINQ，SQL，Pregel 以及 HaLoop 等系统提出的分布式编程模型，而且还能表达它们表达不了的新的应用的计算模型，比如交互型数据挖掘。
我们相信，RDDs 解决那些新的框架提出来计算需求的能力将会成为是 RDD 抽象强大的最有力证据。
我们在 Spark 系统中实现了 RDDs，这个系统已经在 UC Berkeley 以及好些个公司中应用于研究和生产应中。
Spark 和 DryadLINQ 类似，使用 scala 语言提供了很方便语言集成的编程接口。
另外，Spark可以利用 scala 的解释器来对大数据集进行交互式的查询。
我们相信 spark 是首个允许使用多种编程语言来进行分布式内存中交互式数据挖掘的系统。
我们通过为基准测试以及用户应用的测试两个方面来评估了 RDDs 和 spark。
我们分析显示，Spark 在迭代应用中可以比 hadoop 快上 20 倍以上、使得现实中的数据分析报表的速度提升了 40 倍以及使的交互式的扫描 1TB 数据集的延迟在 5-7 秒。
更重要的是，为了彰显 RDDs 的普遍性，我们基于Spark 用相对较小的程序（每个包只有 200 行代码）实现了 Pregel 和 Hadoop 的编程模型，包括它们使用的数据分布优化。
本篇论文以 RDDs（第二节）和 Spark（第三节）的概述开始。
然后在第四节中讨论 了RDDs 内部的表达、在第五节中讨论了我们的实现以及在第六节中讨论了实验结果。
最后，我们讨论了 RDDs 是怎么样来表达现在已存在的几个系统的编程模型（第七节）、调查相关工作（第八节）以及总结。
解析
看起来很长，实际上归纳起来就几点：
- 为了更好的数据复用，所以创建了分布式内存抽象- RDD。
- RDD 可以高效表达多种计算模型。
- 通过 lineage 可以实现高效容错。
- Spark 支持多种编程语言，支持 scala 的 REPL。
- 充分的测试数据表明，Spark 是真滴快！