若谷学院
互联网公司技术架构分享

关于MapReduce/Hadoop的三个问题回复

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

 

   问题:

  1. MapK,V)的方式来看,难道mapreduce只能做统计?
  2. 目前我想除了日志分析之类的功能外,还想做一个全文检索的功能,类似windows查询一下,通过关键字查询文件的位置即可(可能还要根据匹配度做排序),这个我很迷茫不知道怎么下手,痛苦ing
  3. 你的实践是一个单机模式,如果用户把一个1Glog已经上传到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的处理,最简化就是你去多线程或者多进程处理问题,需求决定技术选型。

  

原文出自:https://blog.csdn.net/cenwenchu79/article/list/3

好烂呀没啥价值凑合看看还不错很精彩 (还没有人评分)
Loading...
本站文章来自互联网一线技术博客,若有侵权,请联系我们:若谷技术学院 » 关于MapReduce/Hadoop的三个问题回复
关注若谷技术,获得个性化即时架构文章推送

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

全球互联网技术架构,前沿架构参考

联系我们博客/网站内容提交