使用Alluxio高效存储Spark RDD

  • 时间:
  • 浏览:1
  • 来源:大发5分快乐8_极速5分11选5

为了验证采用Alluxio共享内存的优势,亲戚亲戚朋友 应用相同的配置运行另另一个简单实验。应用500GB大小的数据集,亲戚亲戚朋友 在RDD上执行不同Spark job,要是记录count()操作的耗时。那末使用Alluxio时,Spark应用需要每次都从数据源读取数据(在本次实验中是另另一个本地SSD)。在使用Alluxio时,数据可不还还可以直接从Alluxio内存中读取。下图展示了守护线程池池在这并不是情況下,运行count()函数完成时间性能对比。

Spark RDD可不还还可以使用persist() API存储到Spark缓存中。persist()可不还还可以缓存RDD数据到不同的存储媒介。本次实验使用了以下Spark缓存存储级别(StorageLevel)

除了persist()API,另并不是存储RDD的土办法是将RDD写入Alluxio中。常见的API是:

在本次实验中,亲戚亲戚朋友 使用Spark内置的不同缓存级别存储RDD对比测试使用Alluxio存储RDD,要是整理分析性能测试结果。一齐通过改变RDD的大小来展示存储的RDD的规模对性能的影响。

RDD被保存后(无论存储在Spark内存还是Alluxio中),应用可不还还可以读取RDD以进行后续的计算任务。本次实验利用缓存RDD机会以文件形式存储的RDD运行count()函数,并分别统计运行时间。下图展示了在不同存储土办法下操作的完成时间。

下面是一段将RDD以文件土办法存储在Alluxio中的代码示例:

太少的公司和组织然后刚现在开始将Alluxio和Spark一齐部署从而复杂化数据管理,提升数据访问性能。Qunar最近将Alluxio部署在亲戚亲戚朋友 的生产环境中,从而将Spark streaming作业的平均性能提升了15倍,峰值甚至达到500倍左右。在未使用Alluxio然后,亲戚亲戚朋友 发现生产环境中的這個Spark作业会迅速了 甚至无法完成。而在采用Alluxio后哪几种作业可不还还可以迅速了 地完成。在这篇文章中,亲戚亲戚朋友 将介绍怎样使用Alluxio帮助Spark变得更高效,介绍多种将Alluxio应用在Spark上的土办法。Alluxio可不还还可以使Spark执行得迅速了 ,使多个Spark job以内存级时延共享相同的数据。具体地,亲戚亲戚朋友 将展示怎样使用Alluxio高效存储Spark RDD,并在Spark和Alluxio上做這個性能测试。

2. 存储RDD

用户使用Alluxio存储Spark RDD非常简单:将RDD以文件形式存储在Alluxio中。将RDD文件存储有并不是土办法:saveAsTextFilesaveAsObjectFile。在RDD对应的文件被写入Alluxio后,在Spark中可不还还可以使用sc.textFile机会sc.objectFile (从内存中)读取。为了分析理解使用Alluxio存储RDD和使用Spark内置缓存存储RDD在性能上差异,亲戚亲戚朋友 进行了如下的這個实验。

在這個情況下,RDD数据集远离计算守护线程池池,读取数据花费更多时间,当应用Alluxio时,数据仍然在Alluxio内存中,所以有计算可不还还可以快速完成。在這個情況下,应用Alluxio可不还还可以加速16倍。

3. 查询存储在Alluxio上的RDDs

使用Alluxio存储RDD的另一大优势是可不还还可以在不同Spark应用或作业之间共享存储在Alluxio中的数据。当另另一个DataFrame文件被写入Alluxio后,它可不还还可以被不同的作业、SparkContext、甚至不同的计算框架共享。要是,机会另另一个存储在Alluxio中的RDD被多个应用频繁地访问,那末所有的应用均可不还还可以从Alluxio内存中直接读取数据,并非需要重新计算机会从另外的底层内部管理数据源中读取数据。

Alluxio可不还还可以在多个方面帮助Spark变得更高效。这篇文章介绍了怎样使用Alluxio存储Spark RDD,要是实验验证了采用Alluxio带来的优势:

4. 使用Alluxio共享存储的RDD

Spark用户通常调用Spark RDD cache() API来提高计算性能。cache() API将RDD数据存储在Spark Executor中,下一次调用相同RDD时,RDD数据可不还还可以直接从内存载入。然而,RDD数据容量机会会非常大,为数据分配的内存总量会计算得不准确,所以有在Spark Executor上存储RDD数据会原应计算所需内存不够。然后的博客提到,去哪儿网在生产环境中遇到了以下疑问:Spark job所需的数据总是 不在 内存中,所以有Spark job只有及时完成。另外,机会job崩溃,Spark中的数据将太少被持久化到内存中,下次job恢复,再次访问相同数据,将无法从内存中获取。

版权申明:本文由南京大学顾荣、黄志翻译整理自Alluxio公司技术博客,由Alluxio公司授权云栖社区及CSDN首发(联合),版权归Alluxio公司所有,未经版权所有者同意请勿转载。

6. 总结

下面是一段应用persist()API存储RDD的代码示例。

這個实验证明了通过Alluxio共享RDD這個土办法,可不还还可以在多个Spark应用读取相同数据时提升性能。

从上图可不还还可以看出,读取存储在alluxio中的RDD数据具有比较稳定的执行性能。对于从Spark缓存中读取持久化数据,在数据集规模较小时执行性能具有一定优势,要是随着数据集规模的增长,性能急剧下降。类事,Spark守护线程池池在配了61GB内存的节点上调用persist(MEMORY_ONLY) API,当数据集超过10GB时,Spark内存无法删改存放job所需数据,执行时间会下降。

该疑问的处置方案是将RDD数据存储在Alluxio中,Spark job需要配置存储数据所需的额外内存,只需配置数据计算所需的内存大小。Alluxio提供了数据存储所需内存,所以有RDD数据仍然在内存中。机会Spark job崩溃,数据将仍然存储在Alluxio的内存中,可不还还可以被接下来的任务调用。

1. Alluxio 和Spark RDD缓存

实验相关设置如下:

结果显示了Spark守护线程池池机会不使用Alluxio,需要从数据源处重新读取RDD,本例中是本地SSD。然而,将Alluxio和Spark一齐使用时,数据机会存储在Alluxio内存中,所以有Spark可不还还可以快速地读取RDD。当Spark从Alluxio中读取RDD时,读取时延可不还还可以提升4倍。机会RDD来自访问起来迅速了 或不稳定的数据源,Alluxio的优势就更加明显了。下图显示了RDD存在某公有云存储时守护线程池池的执行时间。

当事人面,相比使用Spark内置缓存,使用Alluxio存储RDD并执行count()函数,其性能在小规模数据上略有劣势。然而,随着数据规模的增长,从Alluxio中读取文件性能更好,机会這個土办法耗时几乎始终随着数据规模线性增长。要是,对于另另一个给定内存大小的节点,Alluxio可不还还可以使应用以读取内存的时延处置更多数据。