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

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

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

一

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

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

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

二

為什么會(huì)這樣?

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

三

那么，選用Hadoop有什么不好呢?牛刀就牛刀，牛刀也可以用來(lái)殺雞，反正它開(kāi)源不要錢(qián)，

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

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

四

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

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

五

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

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

六

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

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

七

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

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