写在MapReduce问题的回复后

中午左右收到一个看我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的处理，最简化就是你去多线程或者多进程处理问题，需求决定技术选型。