放翁(文初)的一亩三分地

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  112 随笔 :: 1 文章 :: 320 评论 :: 0 Trackbacks

    中午左右收到一个看我blog的朋友的邮件,最近他在研究mapreduce,然后想用hadoop来做一些工作,不过遇到了一些问题,我这边也贴一下他的几个问题,同时觉得自己把自己的一些看法分享一下,当然只是自己的一些想法,也许对新学习的同学有帮助。

   问题:

  1. 从Map(K,V)的方式来看,难道mapreduce只能做统计?
  2. 目前我想除了日志分析之类的功能外,还想做一个全文检索的功能,类似windows查询一下,通过关键字查询文件的位置即可(可能还要根据匹配度做排序),这个我很迷茫不知道怎么下手,痛苦ing
  3. 你的实践是一个单机模式,如果用户把一个1G的log已经上传到hdfs了,此时分割工作已经完成,只需要从client那里得到文件基本信息和块的location就可以了,那mapreduce怎么进行下去呢?

   我给回复的邮件内容:

   首先,MapReduce的思想和Hadoop的MapReduce的架构不是一个概念,说的具体一点也就是Hadoop的架构设计只是MapReduce的一个子集思想的实现。每个人都可以根据自己对MapReduce的理解去实现业务处理,简单来说多线程处理就是MapReduce的一种最简单的实现,复杂来说多机协调工作就是一种复杂的实现。

   MapReduce的思想里面最值得借鉴的:

   a.问题分而治之。(找到流程的关键路径,优化可以并行处理的工作)

   b.计算靠近数据。(这也是hdfs存在的最重要的特点,计算的转移往往要比数据转移廉价,特别是对海量数据的处理)

   c.数据规模化随着并行处理成数量级递减。

   剩下的内容就是各个框架对于非业务性需求的处理,例如容灾,如何尽量少穿数据协调处理等等。

   针对他提出的三个问题:

    1. Hadoop的mapreduce从架构上来说最适合的就是统计分析计算。做其他方面的工作需要考虑是否适合,而不是为了技术而技术,先有需求再有技术选型。
    2.  对于你这个需求直接用搜索技术实现就可以了,不一定要硬套在mapreduce上。
    3. 对于海量数据是否一定要到hdsf上,或者就简单得数据物理或者逻辑切割来直接处理,根据自己业务场景选择。hdfs的特点就是对文件切割,容灾,数据逻辑存储和物理存储无关性(便于扩容管理,同时也是计算靠近数据的技术保证)。

    是否使用MapReduce框架,HDFS存储关键还是看你是否真的需要,当现有框架对自己来说并不合适的时候可以对小规模问题定制MapReduce的处理,最简化就是你去多线程或者多进程处理问题,需求决定技术选型。

  

posted on 2009-12-09 13:09 岑文初 阅读(2526) 评论(1)  编辑  收藏

评论

# re: 写在MapReduce问题的回复后[未登录] 2009-12-09 13:55 wz
以下是我自己的一点见解,

MapReduce的思想是最重要的,基于这个思想会有很多的实现,大问题有大问题的实现,小问题有小问题的实现。前段时间碰到一个很小的问题,非常复杂的转化(两类object之间的转化),如果用普通的方法N多循环,但是如果用MapReduce思想的话就会变的更容易 (不会用到多线程,也不会有大task的split,就是一个纯粹的小实现而已)。

对于一般的应用log肯定是不变的道理,可以非常好的应用(一般的系统多线程实现就应该够了);除此之外,利用MapReduce的思想,如果一件事情可以分为4步来做,step by step是一种方案(COR),但是我们如果MapReduce,就可以在第一步做一个split,后面分为多个线程(大的应用可以多台server)去做,最后Master节点(或者server)再去做一个规约(Reduce)就好了。

基于以上思想,如果多台server能共享内存,这样的话,我们能够在没有过多copy(IO)的情况下去做一些business的事情。 JVM level cluster(terracotta是其中一种解决方案)的master/worker其实在某种意义上也算是一个MapReduce了。

写的比较乱,不好意思。  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航: