Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1347913
  • 博文数量: 277
  • 博客积分: 2551
  • 博客等级: 少校
  • 技术积分: 3918
  • 用 户 组: 普通用户
  • 注册时间: 2011-02-21 22:46
文章分类

全部博文(277)

文章存档

2017年(3)

2016年(9)

2015年(65)

2014年(27)

2013年(85)

2012年(61)

2011年(27)

分类: HADOOP

2014-10-11 14:31:06

     mapreduce的缺陷
        (1)只能做简单的统计计算,很多复杂的算法没法表达
        (2)mr的过程中做了很多无效的排序,其他的计算模型获取可以省去这些无效的计算
        (3)mr启动任务需要花费时间,对于一些小当量的计算,还不如拉回数据到本地计算
        (4)mr在计算过程中会产生中间结果并写入磁盘,多次IO,不能像storm那样,将数据流出去
        (5)mr在计算过程中不可迭代,只能临时写磁盘
    mapreduce在开发者的角度看来
          需要知道计算的复杂度,多次map的考虑
          不需要数据的位置,但是要指定数据源,数据的格式
    mapreduce对比impala
           impala在计算时,需要将表转换成分区,将分区转换成文件,将文件再转换成分区,最后再转换成split,这个粒度已经很小了
           也就是说impala关心数据的位置。
           mr本质上是不关心数据的位置,但是需要知道数据源,mr中的map负责为整个计算过程产生源数据,这个过程一般都是去读文件,解析文件内容,所以mr对数据源的最小粒度是文件,最后这个reducer再去合并,这个reducer的个数如果很多,并且操作同一个文件,这个就会因reducer太多而产生竞争。
           mr不关心数据的位置,这个数据的位置最后是由jobtracker去找到数据的位置来完成。
   mapreduce计算的过程产生的疑问
          包括提交的过程,这点也是类似storm,将topology的jar提交到nimbus,mr是通过jobclient将mr的程序提交到jobtracker。
          只是不知道这个jobtracker管理taskTracker来控制任务的执行,只是使用多少个taskTracker来做,怎么建立这些mapTask和reducerTask之间的通信通道?
           storm也有类似的概念,像worker,Executor,Task。storm使用了disruptor和zeroMQ/netty来进行这些数据的通信,并且通过ack机制来达到对计算过程的跟踪。
    
阅读(1112) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~