隨著Hadoop應(yīng)用的不斷拓展，使很多人陷入了對它的盲目崇拜中，認為它能解決一切問題。雖然Hadoop是一個偉大的分布式大型數(shù)據(jù)計算的框架，但Hadoop不是萬能的。比如在下面這幾種場景就不適合使用Hadoop：

1、低延遲的數(shù)據(jù)訪問

Hadoop并不適用于需要實時查詢和低延遲的數(shù)據(jù)訪問。數(shù)據(jù)庫通過索引記錄可以降低延遲和快速響應(yīng)，這一點單純的用Hadoop是沒有辦法代替的。但是如果你真的想要取代一個實時數(shù)據(jù)庫，可以嘗試一下HBase來實現(xiàn)數(shù)據(jù)庫實時讀寫。

2、結(jié)構(gòu)化數(shù)據(jù)

Hadoop不適用于結(jié)構(gòu)化數(shù)據(jù)，卻非常適用于半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。Hadoop和RDBMS不同，一般采用分布式存儲，因此在查詢處理的時候?qū)�會面臨延遲問題。

3、數(shù)據(jù)量并不大的時候

Hadoop一般適用于多大的數(shù)據(jù)量呢？答案是：TB 或者PB。當你的數(shù)據(jù)只有幾十GB時，使用Hadoop是沒有任何好處的。按照企業(yè)的需求有選擇性的的使用Hadoop，不要盲目追隨潮流。Hadoop很強大。但企業(yè)在使用Hadoop或者大數(shù)據(jù)之前，首先要明確自己的目標，再確定是否選對了工具。

4、大量的小文件

小文件指的是那些size比HDFS的block size(默認64M)小得多的文件。如果在HDFS中存儲大量的小文件，每一個個文件對應(yīng)一個block，那么就將要消耗namenode大量的內(nèi)存來保存這些block的信息。如果小文件規(guī)模再大一些，那么將會超出現(xiàn)階段計算機硬件所能滿足的極限。

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

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

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

MapReduce是一個簡單的并行編程模型。是大數(shù)據(jù)并行計算的利器，但很多的計算任務(wù)、工作及算法從本質(zhì)上來說就是不適合使用MapReduce框架的。

如果你讓數(shù)據(jù)共享在MapReduce，你可以這樣做：

迭代：運行多個 MapReduce jobs ，前一個 MapReduce 的輸出結(jié)果，作為下一個 MapReduce 的輸入。
共享狀態(tài)信息：但不要分享信息在內(nèi)存中，由于每個MapReduce的工作是在單個JVM上運行。