Spark好在哪里

RDD的几种存储方式的选择

RDD是内存迭代，MapReduce每轮迭代要读写磁盘；（Spark多个任务之间数据通信是基于内存，而Hadoop是基于磁盘。）

通过记录数据集的一些列转换方式来执行这些task，这样一来，某一分片若是丢失，则可以从该RDD的记录中去就近恢复该分片，而不是从头执行！

1、RDD是一个只读的、有分区的分布式数据集。其分类主要有两种：transformations和action。这两种RDD负责不同的业务。transformations负责数据分片的转换，而action负责激活整个计算链条的实际计算。
2、RDD运转方式
RDD只需知道自己是怎么诞生的就可以了，这就是RDD的实际工作方式。

RDD的好处

为什么分区：1. 为了并行计算；2. 容错更好，挂一个分区后，只需要计算这一个分区；

为什么只读：1. 容错更好，便于从之前的checkpoint恢复之后的数据；2. 可以和 MapReduce 一样来运行执行很慢任务的备份任务来达到缓解计算很慢的节点的问题；

只有丢掉了数据的分区才会需要重新计算, 并不需要回滚整个程序。

action延迟执行lazy策略的好处：可以最后根据DAG拓扑图，进行调度优化。

对于宽依赖（比如 shuffle 依赖）, 中间数据会写入到节点的磁盘中以利于从错误中恢复（因为挂掉一个分区后重新计算它的开销太大了）, 这个和 MapReduce 将 map 后的结果写入到磁盘中是很相似的.

三种RDD存储介质：1）完全内存中的非序列化jvm对象。2）内存中的序列化数据。3）持久化在磁盘。

内存中的RDD怎样被回收来释放资源呢？Spark中采用LRU的回收方式。

 

Spark快在哪里

首先，Spark Task的启动时间快。Spark采用fork线程的方式，而Hadoop采用创建新的进程的方式。

其次，Spark只有在shuffle的时候将数据写入磁盘，而Hadoop中多个MR作业之间的数据交互都要依赖于磁盘交互。

第三，Spark的缓存机制比HDFS的缓存机制高效。

DAG 相比MapReduce 在大多数情况下可以减少 shuffle 次数。Spark 的 DAGScheduler 相当于一个改进版的 MapReduce，如果计算不涉及与其他节点进行数据交换，Spark 可以在内存中一次性完成这些操作，也就是中间结果无须落盘，减少了磁盘 IO 的操作。

 

Spark论文

Hadoop等的容错靠数据备份，缺点是影响性能；Spark的容错主要靠按照计算关系来重新计算丢失的分区，尽量少的使用数据备份；

对于需要复用的 RDD，用户可以明确的选择一个数据存储策略（比如内存缓存）。他们也可以基于一个元素的 key 来为 RDD 所有的元素在机器节点间进行数据分区，这样非常利于数据分布优化，比如给两个数据集进行相同的 hash 分区，然后进行 join，可以提高 join 的性能。

actions 包括：count（表示返回这个数据集的元素的个数）、collect（表示返回数据集的所有元素）以及 save（表示将输出结果写入到存储系统中）

编程者可以通过调用 RDDs 的 persist 方法来缓存后续需要复用的 RDDs。Spark 默认是将缓存数据放在内存中，但是如果内存不足的话则会写入到磁盘中。用户可以通过 persist 的参数来调整缓存策略，比如只将数据存储在磁盘中或者复制备份数据到多台机器。最后，用户可以为每一个 RDDs 的缓存设置优先级，以达到哪个在内存中的 RDDs 应该首先写到磁盘中

数据是如何分区的：Hash-partition , Range-partition;

Spark 在持久化 RDDs 的时候提供了 3 种存储选：1. 存在内存中的非序列化的 java 对象、2. 存在内存中的序列化的数据、3.存储在磁盘中。第一种选择的性能是最好的，因为 java VM 可以很快的访问 RDD 的每一个元素。第二种选择是在内存有限的情况下，使的用户可以以很低的性能代价而选择的比 java 对象图更加高效的内存存储的方式。如果内存完全不够存储的下很大的 RDDs，而且计算这个 RDD 又很费时的，那么选择第三种方式。

checkpointing 对具有很长的血缘关系链且包含了宽依赖的 RDDs 是非常有用的。RDDs 天生的只读的特性使的他们比一般的共享内存系统做 checkpointing 更简单了。因为不用考虑数据的一致性，我们可以不终止程序或者 take 快照，然后在后台将 RDDs 的数据写入到存储系统中。

在迭代式机器学习和图计算中，spark 以 20 倍的速度超过了 hadoop。提速的点主要是在避免了 I / O 操作以及将数据以 java 对象的形式存在内存中从而降低了反序列化的成本。

 

理解为什么提速了：我们惊奇的发现 spark 甚至比基于内存存储二进制数据的 hadoopBinMem 还要快 20 倍。在 hadoopBinMem 中，我们使用的是 hadoop 标准的二进制文件格式（sequenceFile）和 256 m 这么大的数据块大小，以及我们强制将 hadoop 的数据目录放在一个内存的文件系统中。然而，Hadoop 仍然因为下面几点而比 spark 慢:

1. Hadoop 软件栈的最低开销。
2. HDFS 提供数据服务的开销。
3. 将二进制数据转换成有效的内存中的 java 对象的反序列化的成本开销。

我们依次来调查上面的每一个因素。为了测量第一个因素，我们跑了一些空的 hadoop 任务，我们发现单单完成 job 的设置、任务的启动以及任务的清理等工作就花掉了至少 25 秒钟。对于第二个元素，我们发现 HDFS 需要执行多份内存数据的拷贝以及为每一个数据块做 checksum 计算。

最后，为了测试第 3 个因素，我们在单机上做了一个微型的基准测试，就是针对不同文件类型的 256 M 数据来跑线性回归计算。我们特别的对比了分别从 HDFS 文件（HDFS 技术栈的耗时将会很明显）和本地内存文件（内核可以很高效的将数据传输给应用程序）中处理文本和二进制类型数据所话的时间、

图九中是我们我们测试结果的展示。从 In - memory HDFS（数据是在本地机器中的内存中）中读数据比从本地内存文件中读数据要多花费 2 秒中。解析文本文件要比解析二进制文件多花费 7 秒钟。最后，即使从本地内存文件中读数据，但是将预先解析了二进制数据转换成 java 对象也需要 3 秒钟，这个对于线性回归来说也是一个非常耗时的操作。Spark 将 RDDs 所有元素以 java 对象的形式存储在内存中，进而避免了上述说的所有的耗时

如果是基于 checkpoint 的容错机制的话，那么需要通过重跑好几个迭代才能恢复，需要重跑几个取决于 checkpoints 的频率。Spark只需要重新计算丢失的那个RDD分区即可。

只需要将报表关心的列数据存储在内存中进行共享就行，而不是所有的解压后的数据。

虽然 RDDs 只能通过批量转换而得到，但是很多的并行计算的程序都是将相同的操作应用到大量的数据条目中，这样使的 RDDs 的表达力变的丰富。