Hadoop無法解決的問題
因?yàn)轫?xiàng)目的需要，學(xué)習(xí)使用了Hadoop，和所有過熱的技術(shù)一樣，“大數(shù)據(jù)”、“海量”這類詞語在互聯(lián)網(wǎng)上滿天亂飛。Hadoop是一個(gè)非常優(yōu)秀的分布式編程框架，設(shè)計(jì)精巧而且目前沒有同級(jí)別同重量的替代品。另外也接觸到一個(gè)內(nèi)部使用的框架，對于Hadoop做了封裝和定制，使得更滿足業(yè)務(wù)需求。我最近也想寫一些Hadoop的學(xué)習(xí)和使用心得，但是看到網(wǎng)上那么泛濫的文章，我覺得再寫點(diǎn)筆記一樣的東西實(shí)在是沒有價(jià)值。倒不如在漫天頌歌的時(shí)候冷靜下來看看，有哪些不適合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)化，例如通過數(shù)據(jù)集管理起來，可以統(tǒng)一、合并各式數(shù)據(jù)集，甚至也可以給數(shù)據(jù)增加過濾操作作為初篩，事實(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ò)展，這方面我也見過別的公司內(nèi)部定制的工具；
- 通訊協(xié)議和文件系統(tǒng)的增強(qiáng)，尤其是文件系統(tǒng)，***能用起來像接近本地命令一樣，這樣的定制在互聯(lián)網(wǎng)上也能找得到；
- 數(shù)據(jù)訪問的編程接口的進(jìn)一步封裝，主要也是為了更切合業(yè)務(wù)，用著方便；
- ……
這些定制從某種程度上也反應(yīng)了Hadoop在實(shí)際使用中略感局限或者設(shè)計(jì)時(shí)無暇顧及的地方，但是這些都是小問題，都是通過定制和擴(kuò)展能夠修復(fù)的。但是有一些問題，是Hadoop天生無法解決的，或者說，是不適合使用Hadoop來解決的問題。
1、最最重要一點(diǎn)，Hadoop能解決的問題必須是可以MapReduce的。這里有兩個(gè)特別的含義，一個(gè)是問題必須可以拆分，有的問題看起來很大，但是拆分很困難；第二個(gè)是子問題必須獨(dú)立——很多Hadoop的教材上面都舉了一個(gè)斐波那契數(shù)列的例子，每一步數(shù)據(jù)的運(yùn)算都不是獨(dú)立的，都必須依賴于前一步、前二步的結(jié)果，換言之，無法把大問題劃分成獨(dú)立的小問題，這樣的場景是根本沒有辦法使用Hadoop的。
2、數(shù)據(jù)結(jié)構(gòu)不滿足key-value這樣的模式的。在Hadoop In Action中，作者把Hadoop和關(guān)系數(shù)據(jù)庫做了比較，結(jié)構(gòu)化數(shù)據(jù)查詢是不適合用Hadoop來實(shí)現(xiàn)的（雖然像Hive這樣的東西模擬了ANSI SQL的語法）。即便如此，性能開銷不是一般關(guān)系數(shù)據(jù)庫可以比擬的，而如果是復(fù)雜一點(diǎn)的組合條件的查詢，還是不如SQL的威力強(qiáng)大。編寫代碼調(diào)用也是很花費(fèi)時(shí)間的。
3、Hadoop不適合用來處理大批量的小文件。其實(shí)這是由namenode的局限性所決定的，如果文件過小，namenode存儲(chǔ)的元信息相對來說就會(huì)占用過大比例的空間，內(nèi)存還是磁盤開銷都非常大。如果一次task的文件處理較大，那么虛擬機(jī)啟動(dòng)、初始化等等準(zhǔn)備時(shí)間和任務(wù)完成后的清理時(shí)間，甚至shuffle等等框架消耗時(shí)間所占的比例就小得多；反之，處理的吞吐量就掉下來了。（有人做了一個(gè)實(shí)驗(yàn)，參閱：鏈接）
4、Hadoop不適合用來處理需要及時(shí)響應(yīng)的任務(wù)，高并發(fā)請求的任務(wù)。這也很容易理解，上面已經(jīng)說了虛擬機(jī)開銷、初始化準(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)來得好，這是顯而易見的。所以基本上來說，維護(hù)成本不會(huì)低。
