欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Hadoop中小规模集群的并行计算缺陷

程序员文章站 2022-05-22 18:05:50
...
注:写这篇文章的初衷是因为Hadoop炒得有点太热,很多用户现有数据规模并不适用于Hadoop,但迫于扩容压力和去IOE(Hadoop的廉价扩展的确非常有吸引力)而尝试。尝试永远是件正确的事儿,但有时候不用太突进,可以调优或调需求,发挥现有系统的最大效用为上策。

--------------------------------------------------------------------------------------

    Hadoop在实际使用中,很多用户会发现Hadoop性能较差、结构复杂、开发困难,并不如想像中的那么好。这是因为Hadoop的并行计算框架是重量级的MapReduce,其设计目标是支持几百或上千台的大集群,为了有效地利用大集群的资源和保证容错性,MapReduce的体系结构设计得很复杂,而大多数用户的数据规模是十几台、几十台的中小集群,在这种环境中应用Hadoop会带来很多不便,无法体会Hadoop的优势也就可以理解。

    任务拆分过碎,调度成本过高。集群计算会有一定的故障率,比如网络故障或节点机的故障,出了故障就需要重新计算,就会重新消耗资源。因此每台节点机上的任务越小,重复计算所消耗的资源就会越小。但将大任务拆分为小任务本身也需要消耗资源,拆分得越多越小,调度的成本也就越高,实时性也就越差。这是天平的两头,不可兼顾。

    MapReduce是为大集群所设计的,大集群的故障率会非常高,而调度成本就显得不那么重要了。因此MapReduce被设计为一次处理尽量少的数据,默认是一条。假如有几十亿条数据,那这些数据就会被拆分成几十亿条,每个节点机分配一条。但是中小集群用户的节点少,发生故障的概率很低,往往能正常运行很久,他们更希望可以*定制任务的拆分规模,比如把一亿条数据分成一百份,每个节点处理一百万条,从而降低调度成本。

    MapReduce难以提供这种灵活*的任务拆分手段,因此中小集群用户会感觉Hadoop的实时性较差。

    用文件交换数据,性能低。计算中的节点故障可以用细分任务的办法解决,但如果节点计算后、在向汇总机提交结果前发生故障怎么办?MapReduce的办法很简单:写入HDFS,用文件来交换数据,这种做法明,显不如将内存中的数据直接发回节点机快,但在高故障率的大集群环境下,这种做法就相当有效了。

    中小集群用户的故障率很低,他们更希望灵活的数据交换方式:大部分情况下直接交换,确有必要的时候再用文件交换,这样可以大大减少数据交换的时间。

    MapReduce无法提供这种灵活的数据交换方式,因此中小集群用户会感觉Hadoop的性能较差。

    架构复杂,管理成本高。为了使大集群高效地利用资源、应对不可靠的计算环境、稳定有效地执行计算任务,MapReduce的架构被设计的非常复杂。这种复杂在几百,几千台的集群环境中是非常有必要的。但这也带来了部署的复杂性,不仅维护和管理的工作量大,学习难度和开发难度也大大提高,而且复杂的结构会导致整体的性能下降,各种组件出现错误的概率增多,错误排查困难,也束缚了用户的*度,使开发成本变大。例如,MapRreduce默认是一次处理一条数据,但经过改写后也可以一次处理多条数据,只是这种改写比较困难,需要较高的技术能力和较多的开发时间。

    中小集群用户的节点机少,机器类型没有那么多样,计算环境也比较可靠,因此不需要如此复杂的架构就能保证计算任务稳定有效的执行。他们更希望MapRreduce的架构简单些,这样才能降低管理成本低,提高运算效率高。

    中小集群用户无法改变MapReduce的底层架构设计,因此常会感觉Hadoop的管理成本太高。