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