因為項目的需要，學習使用了Hadoop，和所有過熱的技術一樣，“大數(shù)據(jù)”、“海量”這類詞語在互聯(lián)網(wǎng)上滿天亂飛。Hadoop是一個非常優(yōu)秀的分布式編程框架，設計精巧而且目前沒有同級別同重量的替代品。另外也接觸到一個內(nèi)部使用的框架，對于Hadoop做了封裝和定制，使得更滿足業(yè)務需求。我最近也想寫一些Hadoop的學習和使用心得，但是看到網(wǎng)上那么泛濫的文章，我覺得再寫點筆記一樣的東西實在是沒有價值。倒不如在漫天頌歌的時候冷靜下來看看，有哪些不適合Hadoop解決的難題呢？

這張圖就是Hadoop的架構圖，Map和Reduce是兩個最基本的處理階段，之前有輸入數(shù)據(jù)格式定義和數(shù)據(jù)分片，之后有輸出數(shù)據(jù)格式定義，二者中間還可以實現(xiàn)combine這個本地reduce操作和partition這個重定向mapper輸出的策略行為?？梢栽黾拥亩ㄖ坪驮鰪姲ǎ?/p>

• 輸入數(shù)據(jù)和輸出數(shù)據(jù)的強化，例如通過數(shù)據(jù)集管理起來，可以統(tǒng)一、合并各式數(shù)據(jù)集，甚至也可以給數(shù)據(jù)增加過濾操作作為初篩，事實上業(yè)務上的核心數(shù)據(jù)源是種類繁多的；
• 數(shù)據(jù)分片策略的擴展，我們經(jīng)常需要把具備某些業(yè)務共性的數(shù)據(jù)放到一起處理；
• combine和partition的擴展，主要是有一些策略實現(xiàn)是在很多Hadoop的job中都是通用的；
• 監(jiān)控工具的擴展，這方面我也見過別的公司內(nèi)部定制的工具；
• 通訊協(xié)議和文件系統(tǒng)的增強，尤其是文件系統(tǒng)，最好能用起來像接近本地命令一樣，這樣的定制在互聯(lián)網(wǎng)上也能找得到；
• 數(shù)據(jù)訪問的編程接口的進一步封裝，主要也是為了更切合業(yè)務，用著方便；
• ……

這些定制從某種程度上也反應了Hadoop在實際使用中略感局限或者設計時無暇顧及的地方，但是這些都是小問題，都是通過定制和擴展能夠修復的。但是有一些問題，是Hadoop天生無法解決的，或者說，是不適合使用Hadoop來解決的問題。

1、最最重要一點，Hadoop能解決的問題必須是可以MapReduce的。這里有兩個特別的含義，一個是問題必須可以拆分，有的問題看起來很大，但是拆分很困難；第二個是子問題必須獨立——很多Hadoop的教材上面都舉了一個斐波那契數(shù)列的例子，每一步數(shù)據(jù)的運算都不是獨立的，都必須依賴于前一步、前二步的結果，換言之，無法把大問題劃分成獨立的小問題，這樣的場景是根本沒有辦法使用Hadoop的。

2、數(shù)據(jù)結構不滿足key-value這樣的模式的。在Hadoop In Action中，作者把Hadoop和關系數(shù)據(jù)庫做了比較，結構化數(shù)據(jù)查詢是不適合用Hadoop來實現(xiàn)的（雖然像Hive這樣的東西模擬了ANSI SQL的語法）。即便如此，性能開銷不是一般關系數(shù)據(jù)庫可以比擬的，而如果是復雜一點的組合條件的查詢，還是不如SQL的威力強大。編寫代碼調(diào)用也是很花費時間的。

3、Hadoop不適合用來處理大批量的小文件。其實這是由namenode的局限性所決定的，如果文件過小，namenode存儲的元信息相對來說就會占用過大比例的空間，內(nèi)存還是磁盤開銷都非常大。如果一次task的文件處理較大，那么虛擬機啟動、初始化等等準備時間和任務完成后的清理時間，甚至shuffle等等框架消耗時間所占的比例就小得多；反之，處理的吞吐量就掉下來了。（有人做了一個實驗，參閱：鏈接）

4、Hadoop不適合用來處理需要及時響應的任務，高并發(fā)請求的任務。這也很容易理解，上面已經(jīng)說了虛擬機開銷、初始化準備時間等等，即使task里面什么都不做完整地跑一遍job也要花費幾分鐘時間。

5、Hadoop要處理真正的“大數(shù)據(jù)”，把scale up真正變成scale out，兩臺小破機器，或者幾、十幾GB這種數(shù)據(jù)量，用Hadoop就顯得粗笨了。異步系統(tǒng)本身的直觀性并不像那些同步系統(tǒng)來得好，這是顯而易見的。所以基本上來說，維護成本不會低。

原文來自：《四火的嘮叨》