Hadoop的几个缺陷

最近几个项目都在分布式存储上有些需求，集万千宠爱于一身的Hadoop自然是热门候选，不过对于其自身的缺陷也一直在纠结。因为Hadoop被过于赞美了，就在网上找了介绍Hadoop短处的文章，MapR先做了一番批判：

/*******以下来自http://qing.weibo.com/tag/hadoop*******/

1) 性能。 一系列测试（比如论文 《A Comparison of Approaches to Large-Scale Data Analysis》 ，http://database.cs.brown.edu/projects/mapreduce-vs-dbms/ ）发现，Hadoop在性能上可以提高的空间，尤其是和硬件的理论性能比较，还很多。造成这个的原因主要有： 在当前Hadoop的设计中，所有的meta data操作都要通过集中式的Namenode来进行，Namenode有可能是性能的瓶颈；M/R 应用程序需要通过DataNode来访问HDFS, 这就涉及到格外的进程切换和网络传输开销（请参阅着名的HDFS-347，https://issues.apache.org/jira/browse/HDFS-347，题外话，通读关于这个issue的讨论绝对会让你受益匪浅）；还有在M/R 应用程序端的开销也有值得改进的地方（http://developer.yahoo.com/blogs/hadoop/posts/2009/08/the_anatomy_of_hadoop_io_pipel/ ）。

2) 可扩展性和可靠性。当前Hadoop单一Namenode，单一Jobtracker的设计严重制约了整个Hadoop 可扩展性和可靠性。首先，Namenode和Jobtracker是整个系统中明显的单点故障源（SPOF）。再次单一Namenode的内存容量有限，使得Hadoop集群的节点数量被限制到2000个左右，能支持的文件系统大小被限制在10-50PB, 最多能支持的文件数量大约为1.5亿 左右（注，实际数量取决于Namenode的内存大小）。 又，在集中式的Namenode造成DataNode的blocks report也会对Namenode的性能造成严重的影响。例如系统有1800个Datanode, 每个Datanode有3T存储，整个集群大约有1.8P有效存储（1800*3T/3，假设每个数据块有3份replica）。那么每个Datanode上有大约50000个左右的block （假设block 大小是64M，然后有的block并没有达到64M大小），假设Datanode每小时会发送一次block report， 那么Namenode每两秒会收到一次block report，每个block report包含50000条数据，处理这些数据无疑会占用相当资源。 实际上，有用户抱怨其集群的Namenode重启需要数小时，这大大降低了系统的可用性 （HDFS-273， https://issues.apache.org/jira/browse/HDFS-273 ）

3) 各种企业特性。随着Hadoop被广泛使用，面对各式各样的需求，人们期望Hadoop能提供更多特性，比如完全可读写的文件系统，snapshot，mirror等等。这些都是当前版本的Hadoop不支持，但是用户又有强烈需求的。
Hadoop的这些缺点也带来了巨大的机会，Cloudera的目光最为敏锐，最早看到这一点。Cloudera的商业模式和一般Open Source创业公司无异：网罗Hadoop的contributor，积极的回馈Hadoop社区，在此基础上发布自己的Hadoop发行版CDH（Cloudera's Distribution including Apache Hadoop），提供各种增值服务。实际上，CDH版Hadoop具有相当高的知名度。

/*******截止*******/