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

這張圖就是Hadoop的架構(gòu)圖，Map和Reduce是兩個(gè)最基本的處理階段，之前有輸入數(shù)據(jù)格式定義和數(shù)據(jù)分片，之后有輸出數(shù)據(jù)格式定義，二者中間還可以實(shí)現(xiàn)combine這個(gè)本地reduce操作和partition這個(gè)重定向mapper輸出的策略行為。可以增加的定制和增強(qiáng)包括：

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

這些定制從某種程度上也反應(yīng)了Hadoop在實(shí)際使用中略感局限或者設(shè)計(jì)時(shí)無(wú)暇顧及的地方，但是這些都是小問(wèn)題，都是通過(guò)定制和擴(kuò)展能夠修復(fù)的。但是有一些問(wèn)題，是Hadoop天生無(wú)法解決的，或者說(shuō)，是不適合使用Hadoop來(lái)解決的問(wèn)題。

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

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

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

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

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

原文來(lái)自：《四火的嘮叨》