注：写这篇文章的初衷是因为Hadoop炒得有点太热，很多用户现有数据规模并不适用于Hadoop，但迫于扩容压力和去IOE（Hadoop的廉价扩展的确非常有吸引力）而尝试。尝试永远是件正确的事儿，但有时候不用太突进，可以调优或调需求，发挥现有系统的最大效用为上策。
--------------------------------------------------------------------------------------
Hadoop在实际使用中，很多用户会发现Hadoop性能较差、结构复杂、开发困难，并不如想像中的那么好。这是因为Hadoop的并行计算框架是重量级的MapReduce，其设计目标是支持几百或上千台的大集群，为了有效地利用大集群的资源和保证容错性，MapReduce的体系结构设计得很复杂，而大多数用户的数据规模是十几台、几十台的中小集群，在这种环境中应用Hadoop会带来很多不便，无法体会Hadoop的优势也就可以理解。
任务拆分过碎，调度成本过高。集群计算会有一定的故障率，比如网络故障或节点机的故障，出了故障就需要重新计算，就会重新消耗资源。因此每台节点机上的任务越小，重复计算所消耗的资源就会越小。但将大任务拆分为小任务本身也需要消耗资源，拆分得越多越小，调度的成本也就越高，实时性也就越差。这是天平的两头，不可兼顾。
MapReduce是为大集群所设计的，大集群的故障率会非常高，而调度成本就显得不那么重要了。因此MapReduce被设计为一次处理尽量少的数据，默认是一条。假如有几十亿条数据，那这些数据就会被拆分成几十亿条，每个节点机分配一条。但是中小集群用户的节点少，发生故障的概率很低，往往能正常运行很久，他们更希望可以自由定制任务的拆分规模，比如把一亿条数据分成一百份，每个节点处理一百万条，从而降低调度成本。
MapReduce难以提供这种灵活自由的任务拆分手段，因此中小集群用户会感觉Hadoop的实时性较差。
用文件交换数据，性能低。计算中的节点故障可以用细分任务的办法解决，但如果节点计算后、在向汇总机提交结果前发生故障怎么办？MapReduce的办法很简单：写入HDFS，用文件来交换数据，这种做法明，显不如将内存中的数据直接发回节点机快，但在高故障率的大集群环境下，这种做法就相当有效了。
中小集群用户的故障率很低，他们更希望灵活的数据交换方式：大部分情况下直接交换，确有必要的时候再用文件交换，这样可以大大减少数据交换的时间。
MapReduce无法提供这种灵活的数据交换方式，因此中小集群用户会感觉Hadoop的性能较差。
架构复杂，管理成本高。为了使大集群高效地利用资源、应对不可靠的计算环境、稳定有效地执行计算任务，MapReduce的架构被设计的非常复杂。这种复杂在几百，几千台的集群环境中是非常有必要的。但这也带来了部署的复杂性，不仅维护和管理的工作量大，学习难度和开发难度也大大提高，而且复杂的结构会导致整体的性能下降，各种组件出现错误的概率增多，错误排查困难，也束缚了用户的自由度，使开发成本变大。例如，MapRreduce默认是一次处理一条数据，但经过改写后也可以一次处理多条数据，只是这种改写比较困难，需要较高的技术能力和较多的开发时间。
中小集群用户的节点机少，机器类型没有那么多样，计算环境也比较可靠，因此不需要如此复杂的架构就能保证计算任务稳定有效的执行。他们更希望MapRreduce的架构简单些，这样才能降低管理成本低，提高运算效率高。
中小集群用户无法改变MapReduce的底层架构设计，因此常会感觉Hadoop的管理成本太高。