Hadoop是個龐大的重型解決方案，它的設計目標本來就是大規模甚至超大規模的集群，面對的是上百甚至上千個節點，這樣就會帶來兩個問題：

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

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

一

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

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

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

二

為什么會這樣?

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

三

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

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

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

四

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

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

五

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

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

六

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

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

七

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

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