注：本文翻译自

 

Hadoop是一个分布式海量数据计算的伟大框架。但是，hadoop并不是万能的。比如，以下场景就不适合用hadoop：

 

1、低延迟数据访问

　　需要实时查询并在毫秒级内进行低延时访问数据就不适合用hadoop。Hadoop并不适用于数据库。

数据库的索引记录可降低延时的时间，提高响应的速度。但是，如果你在数据库这方面确实有实时

查询的需求，可以尝试一下HBase，这是一个适合随机访问和实时读写的列式数据库。

 

2、结构化的数据

　　Hadoop不适用于处理关联紧密的结构化数据，但非常适合处理半结构化和非结构化的数据。它

以文件形式存储数据，不像RDBMS使用索引来存储。因此，每一个查询都要用mapReduce作业来处理，

这样就面临着延时问题。

 

3、数据量并不大的时候

　　Hadoop到底处理多大的数据量呢？答案是TB或PB级别。当待分析的数据只有几十个G的时候，

使用hadoop并不划算。不要一味跟随潮流的去使用hadoop，而要看看你自己的需求。

 

4、大量的小文件

　　当有大量的小文件时，由于NameNode需存储block块的映射信息和元数据信息，

导致namenode面临着巨大的内存压力。为了解决nameNode的这个瓶颈，hadoop使

用了HDFS Federation（联邦）机制。

 

5、频繁的写操作和文件更新

　　HDFS使用一次写入多次读取的方式。当有太多的文件需要更新时，hadoop并

支持这种情况。

 

 

6、MapReduce或许不是最佳的选择

　　MapReduce是一个简单的并行编程模型。由于并行性，因此你需要确保每一个

MR作业所处理的数据和其他的作业相互独立开来。每个MR不应该有依赖关系。

 

　　如果你在MR中共享一些数据的话，你可以这样做：

　　　　迭代：运行多个MR作业，前一个的输出结果作为下一个作业的输入。

　　　　共享状态信息：不要在内存中共享信息，因为每个MR作业是运行在单个JVM实例上的。