Hadoop是個(gè)龐大的重型解決方案，它的設(shè)計(jì)目標(biāo)本來就是大規(guī)模甚至超大規(guī)模的集群，面對的是上百甚至上千個(gè)節(jié)點(diǎn)，這樣就會帶來兩個(gè)問題：

• 自動化管理管任務(wù)分配機(jī)制：這樣規(guī)模的集群，顯然不大可能針對每個(gè)節(jié)點(diǎn)提供個(gè)性化的管理控制，否則工作量會大到累死人，必須采用自動化的管理和任務(wù)分配手段，而這并不是件簡單的事情。
• 強(qiáng)容錯(cuò)能力：大規(guī)模集群在某個(gè)任務(wù)執(zhí)行周期內(nèi)，也就是幾小時(shí)之內(nèi)，都有可能發(fā)生設(shè)備故障。如果沒有強(qiáng)容錯(cuò)能力可能任何任務(wù)都無法執(zhí)行出來。而容錯(cuò)同樣并不容易實(shí)現(xiàn)，同樣非常消耗計(jì)算和存儲資源。

而且，Hadoop的產(chǎn)品線豐富，這本來是好事情，但要把這些模塊都放在一個(gè)平臺上運(yùn)行，還要梳理好各個(gè)模塊之間的相互依賴性，就需要一個(gè)包羅萬象的復(fù)雜框架，這也使得Hadoop體系顯得很沉重。

一

但是，很多情況下，用戶的數(shù)據(jù)并不總會有那么多。除了一些互聯(lián)網(wǎng)巨頭企業(yè)和***通信運(yùn)營商及銀行外，大多數(shù)用戶的數(shù)據(jù)量并沒有大到需要幾百上千個(gè)節(jié)點(diǎn)才能處理的地步。而且，很多用戶也只是為了常規(guī)的結(jié)構(gòu)化數(shù)據(jù)運(yùn)算(主要也就是SQL)，用不著那么完整的產(chǎn)品線。

結(jié)果，我們經(jīng)常看到的現(xiàn)象是：用戶上了Hadoop，只有四個(gè)或八個(gè)節(jié)點(diǎn)，多的也就十來個(gè)，而且也只是安裝個(gè)Hive(或別的類似解決方案)來跑跑SQL。

這就是“殺雞用牛刀了”!

二

為什么會這樣?

道理很簡單。現(xiàn)在大數(shù)據(jù)平臺是個(gè)業(yè)界趨勢，而經(jīng)過幾年的宣傳，用戶都覺得傳統(tǒng)關(guān)系數(shù)據(jù)庫不再是未來的方向，即使現(xiàn)在還能用，但總覺得繼續(xù)投資在關(guān)系數(shù)據(jù)庫上就有被時(shí)代甩下的風(fēng)險(xiǎn)，于是都想去嘗試新技術(shù)。但找來找去，也只有Hadoop勉強(qiáng)可用了，選擇Hadoop變成一個(gè)政治正確的事情了。

三

那么，選用Hadoop有什么不好呢?牛刀就牛刀，牛刀也可以用來殺雞，反正它開源不要錢，

不是這樣的。雖然Hadoop軟件本身是開源免費(fèi)的(其實(shí)很多用戶上的是商業(yè)公司的產(chǎn)品，本來也并不便宜)，但因?yàn)樗膹?fù)雜性，想配置用好它并不容易，維護(hù)支持的成本一點(diǎn)也不低。Hadoop事實(shí)上是個(gè)高端產(chǎn)品，并不很適合數(shù)據(jù)量規(guī)模沒有大到需要上百節(jié)點(diǎn)的中小用戶。

大集群和小集群的實(shí)現(xiàn)技術(shù)是完全不一樣的，Hadoop為了解決大集群問題而付出的努力并不是沒有成本的。

四

統(tǒng)一的自動化管理機(jī)制固然讓管理工作變簡單了，但也限制了程序員的靈活性。開發(fā)人員只能去適應(yīng)，難以寫出適合業(yè)務(wù)和數(shù)據(jù)特征的代碼，這樣無法發(fā)揮機(jī)器的***效能。比如想控制HDFS的文件冗余方案，讓不同文件的冗余數(shù)不同，而特定的冗余方案能有效地減少網(wǎng)絡(luò)傳輸量從而提高性能。這也許能夠通過修改Hadoop源碼來實(shí)現(xiàn)，但并不輕松，而且隨意修改底層源碼又會影響升級。

對于小規(guī)模的集群，則沒有必要采用統(tǒng)一管理方式，可以針對每個(gè)節(jié)點(diǎn)進(jìn)行個(gè)性化配置，程序員也可以自由決定每個(gè)節(jié)點(diǎn)的計(jì)算任務(wù)和數(shù)據(jù)分布，這樣可以更有效地利用硬件資源，獲得***的性能，雖然會需要更細(xì)致的工作，但對于小規(guī)模集群，這增加的工作量仍然是可以接受的。

五

Hadoop投入了相當(dāng)多資源來實(shí)現(xiàn)超強(qiáng)的容錯(cuò)，這對于大集群當(dāng)然也非常必要的。比如MapReduce為了容錯(cuò)把任務(wù)拆得太碎，而且每次執(zhí)行結(jié)果都會寫盤，以保證任務(wù)過程中有節(jié)點(diǎn)故障時(shí)仍然可以執(zhí)行下去，這會嚴(yán)重影響性能。而且，這種體系也難以直接控制執(zhí)行次序，在編寫有序有關(guān)聯(lián)運(yùn)算時(shí)就很困難，需要費(fèi)勁去繞(這個(gè)問題以后還會再談到)。

而對于幾個(gè)到十幾個(gè)節(jié)點(diǎn)的小集群，就不需要這么強(qiáng)的容錯(cuò)能力了。在幾小時(shí)的任務(wù)周期內(nèi)，整個(gè)集群所有節(jié)點(diǎn)都能正常工作是個(gè)大概率事件。對于小集群，我們只要保證有少數(shù)節(jié)點(diǎn)故障時(shí)整個(gè)集群還能繼續(xù)工作以接受新任務(wù)，而讓當(dāng)前正在執(zhí)行的任務(wù)失敗也是可以容忍的，畢竟這并不會經(jīng)常發(fā)生。

六

復(fù)雜的框架本身也會消耗很多資源。小集群本來就沒有幾個(gè)節(jié)點(diǎn)，還要把有限的資源花費(fèi)在這些不實(shí)際計(jì)算的事情上，顯然是不劃算的。在目標(biāo)任務(wù)類型較為單一時(shí)，應(yīng)當(dāng)選擇更適合的框架，沒必要去追求大而全的東西。

“牛刀”應(yīng)當(dāng)去做它適合做的事，也就數(shù)據(jù)量大但運(yùn)算簡單的任務(wù)，用俗話說就是“傻大笨粗”。真到了幾百個(gè)節(jié)點(diǎn)的集群，那還只有Hadoop能做了，而精細(xì)的活兒真不合適它來干。

七

對于小集群，我們需要更輕量級的大數(shù)據(jù)解決方案。

大數(shù)據(jù)的技術(shù)本質(zhì)是高性能，而提高性能的需求無處不在，并不是只有那種規(guī)模的大數(shù)據(jù)。比即時(shí)查詢設(shè)計(jì)的數(shù)據(jù)量就不會也不可能太大(否則不可能即時(shí))，這種場景會要求有很好的集成性，但Hadoop基本上不可能被嵌到應(yīng)用程序里面，它只能在邊上作為一個(gè)數(shù)據(jù)源工作;有些臨時(shí)性數(shù)據(jù)處理時(shí)需要隨時(shí)使用，也不可能再為之專門建設(shè)大數(shù)據(jù)平臺，比如為了處理一批日志而搭建一個(gè)Hadoop，等環(huán)境搭好時(shí)任務(wù)已經(jīng)過期了。