Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1377607
  • 博文数量: 209
  • 博客积分: 464
  • 博客等级: 下士
  • 技术积分: 3762
  • 用 户 组: 普通用户
  • 注册时间: 2011-01-24 18:25
  • 认证徽章:
个人简介

阿弥陀佛

文章分类

全部博文(209)

文章存档

2019年(3)

2018年(5)

2017年(6)

2016年(10)

2015年(9)

2014年(73)

2013年(90)

2012年(13)

分类: 架构设计与优化

2014-12-18 14:45:30

读了RDD的这篇论文,Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computering.
伯克利写论文更注重思想,google的论文给人感觉更加注重工程上的实现。
这篇论文将RDD与共享内存的方式进行了对比。表明RDD更加适合迭代计算环境,不用像mapreduce那样不断的持久化保存中间的计算结果落地的时间。
将其中的数据抽象成RDD,一个一个的dataset,每个dataset有可能分布到不同的机器上,这些机器共同构成一个dataset。
RDD在spark里面是只读的不会修改的,只能够通过spark提供的操作,将一种RDD转换成为另一种RDD。
同一个job的RDD之间会存在血缘关系。
1. RDD之间的关系
     血缘关系分为两种:wide dependency和narrow dependency。提出这两种方式非常有利于spark性能的提升。因为narrow dependency的RDD如果发生了某个节点的down机现象,可以通过其他的机器将该分片重新计算一下就行了,而宽依赖却不得不将他的所有的parent都计算一遍,这样将非常耗时。
2. RDD实现上的优化
     spark也就是给用户提供更加丰富语义。为使用RDD的用户提供了两种接口,persist 和partition。persist 可以让用户自己决定是否将其存储到持久化设备上,因为有些RDD是在计算中产生的,没有必要进行存储,这样提供了persist可以提高了存储的效率,避免了存储时所引起的开销。
     

    相比mapreduce而言,要想榨取分布式计算的性能,提供用户丰富的控制接口是非常好的一种选择。上层接口不改,已有系统很难有大的提升了。
阅读(1192) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册