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

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

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

一

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

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

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

二

為什么會這樣?

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

三

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

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

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

四

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

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

五

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

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

六

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

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

七

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

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