中午左右收到一個看我blog的朋友的郵件，最近他在研究mapreduce，然后想用hadoop來做一些工作，不過遇到了一些問題，我這邊也貼一下他的幾個問題，同時覺得自己把自己的一些看法分享一下，當然只是自己的一些想法，也許對新學習的同學有幫助。
問題：
- 從Map（K,V）的方式來看，難道mapreduce只能做統計？
- 目前我想除了日志分析之類的功能外，還想做一個全文檢索的功能，類似windows查詢一下，通過關鍵字查詢文件的位置即可（可能還要根據匹配度做排序），這個我很迷茫不知道怎么下手，痛苦ing
- 你的實踐是一個單機模式，如果用戶把一個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的處理，最簡化就是你去多線程或者多進程處理問題，需求決定技術選型。