Hadoop雖然強大，但不是萬能的(CSDN)

Hadoop很強大，但企業在使用Hadoop或者大數據以前，首先要明確本身的目標，再肯定是否選對了工具，畢竟Hadoop不是萬能的！本文中列舉了幾種不適合使用Hadoop的場景。

隨着 Hadoop 應用的不斷拓展，使不少人陷入了對它的盲目崇拜中，認爲它能解決一切問題。雖然Hadoop是一個偉大的分佈式大型數據計算的框架，但Hadoop不是萬能的。好比在下面這幾種場景就不適合使用Hadoop：

一、低延遲的數據訪問

Hadoop並不適用於須要實時查詢和低延遲的數據訪問。數據庫經過索引記錄能夠下降延遲和快速響應，這一點單純的用Hadoop是沒有辦法代替的。可是若是你真的想要取代一個實時數據庫，能夠嘗試一下HBase來實現數據庫實時讀寫。

二、結構化數據

Hadoop不適用於結構化數據，卻很是適用於半結構化和非結構化數據。Hadoop和RDBMS不一樣，通常採用分佈式存儲，所以在查詢處理的時候將會面臨延遲問題。

三、數據量並不大的時候

Hadoop通常適用於多大的數據量呢？答案是：TB 或者PB。當你的數據只有幾十GB時，使用Hadoop是沒有任何好處的。按照企業的需求有選擇性的的使用Hadoop，不要盲目追隨潮流。Hadoop很強大。但企業在使用Hadoop或者大數據以前，首先要明確本身的目標，再肯定是否選對了工具。

四、大量的小文件

小文件指的是那些size比HDFS的block size(默認64M)小得多的文件。若是在HDFS中存儲大量的小文件，每個個文件對應一個block，那麼就將要消耗namenode大量的內存來保存這些block的信息。若是小文件規模再大一些，那麼將會超出現階段計算機硬件所能知足的極限。

五、太多的寫入和文件更新

HDFS是採用的一些多讀方式。當有太多文件更新需求，Hadoop沒有辦法支持。

六、MapReduce可能不是最好的選擇

MapReduce是一個簡單的並行編程模型。是大數據並行計算的利器，但不少的計算任務、工做及算法從本質上來講就是不適合使用MapReduce框架的。

若是你讓數據共享在MapReduce，你能夠這樣作：

• 迭代：運行多個 MapReduce jobs ，前一個 MapReduce 的輸出結果，做爲下一個 MapReduce 的輸入。
• 共享狀態信息：但不要分享信息在內存中，因爲每一個MapReduce的工做是在單個JVM上運行。

 

原文連接：Hadoop isn’t Silver Bullet