Hadoop在大数据环境下的性能优化.docx
- 文档编号:5405073
- 上传时间:2023-05-08
- 格式:DOCX
- 页数:14
- 大小:27.67KB
Hadoop在大数据环境下的性能优化.docx
《Hadoop在大数据环境下的性能优化.docx》由会员分享,可在线阅读,更多相关《Hadoop在大数据环境下的性能优化.docx(14页珍藏版)》请在冰点文库上搜索。
Hadoop在大数据环境下的性能优化
Hadoop大数据环境下的性能优化
陈庆敬,M201372867
(华中科技大学计算机科学与技术学院武汉市430074)
摘要随着互联网的快速发展,数据量以前所未有的势头呈现出爆炸式增长,人类由此进入大数据时代。
海量数据的产生必将推动互联网的演进,对海量数据的充分挖掘将催生更多的新业态,给我们带来更多的惊喜和便利。
但数据大多是结构化和半结构化的,传统的关系型数据库很难胜任对非结构化的分析工作,而Hadoop则是解决上述问题最好的实现框架。
以Hadoop为代表的非关系数据分析方法,以其适合大规模并行处理、简单易用等突出优势,在互联网信息搜索和其他大数据分析领域取得重大进展,已成为目前大数据分析的主流技术。
但Hadoop在小文件问题以及数据处理性能等方面尚有很大的提升空间,因此从不同角度对Hadoop性能瓶颈进行分析,进而提出相应的优化方案,在大数据时代具有重大意义。
关键词大数据;数据挖掘;Hadoop;性能瓶颈;优化方案。
中图法分类号TP391
TheperformanceoptimizationofHadoopinthebackgroundofBigData
ChenQing-Jing
(DepartmentofComputerScienceandTechnology,HuazhongUniversityofScienceandTechnology,Wuhan,430074)
AbstractAstherapiddevelopmentofInternet,theamountofdatagrowsfasterthananytimeinthepast,thenpeoplestepintotheageofBigData.MassivedatawillpromotethedevelopmentofInternetundoubtedly,theminingofmassivedatawillhelptoproducemoreformsofindustriesandthusfacilitateourlives.Butmostofdataisunstructuredorhalf-structured,traditionalrelationaldatabasesarenotgoodatanalyzingthesekindsofdata,Hadoopisnowthebesttooltosolvetheseproblems.Hadoopisquitegoodatmassivelyparalleldataprocessingandisveryeasytouse,soitbecomesthemaintechnologyinthefieldofBigDataanalyzation.ButtherearestillsomeshortcomingsinHadoopsuchashandlingsmallfilesandtheperformanceofdataprocessing,sothereisstillroomtooptimizetheperformanceofHadoop.AnalyzingthebottleneckofHadoopandcomingupwithsolutionsisverysignificantintheageofBigData.
KeywordsBigData;DataMining;Hadoop;PerformanceBottleneck;OptimizationSolution
1,研究背景
伴随着Web2.0的快速发展,网络搜索、电子商务、在线视频、社交网络等的飞速普及,互联网数据量呈现出前所未有的爆炸式的增长势头。
全球互联网一分钟之内会发生些什么?
Qmee最近做了一份统计,向我们展示一分钟之内互联网的变化,每一分钟:
Google执行200万次搜索,Youtube上传72小时视频,诞生571个新网站,发送邮件2.04亿,新发布27.8万推特信息,更新24.6万个Facebook动态,使用Skype通话140万分钟。
计算机行业在其它领域的广泛应用也促使数据的产生。
天文学中,前2000年,整个数据收集已经积累到140兆兆字节的信息,然而斯隆数字巡天在短短的几个星期内收集到了多于140兆兆字节的信息。
近几年数据以每年50%左右的速度增长,这标志着我们已经进入大数据时代。
大数据时代带来的不仅仅是信息的爆炸式增长,毫无疑问,大数据将加快推动互联网的演进。
大数据催生的新业态还会让我们工作更轻松、经济更活跃、生活更便利。
大数据可以提供宏观经济分析服务:
日本公司的经济指标预测系统,从互联网新闻中搜索影响制造业的480项经济数据,计算出采购经理人指数的PMI预测值。
大数据可以有力的支撑信息消费:
中国的网购60%是对实体店购物的替代,40%是因为方便和品种多等原因而新增的购买量,电子商务有利于手机用户需求,大数据将进一步促进其销售。
大数据还能提供咨询服务:
硅谷有个气候公司,从美国气象局等数据库中获得几十年的天气数据,将各地的降雨、气温、土壤状况做成精密图表,从而预测各个农场的来年产量,向用户出售个性化保险。
大数据的应用还体现在我们生活中:
北京公交一卡通每年产生4000万条刷卡记录,分析这些数据可以优化设计城市公交路线,这是大数据对交通服务的改进。
互联网的快速发展产生大数据,大数据反过来驱动互联网各类应用的加速演进。
在可以遇见的未来,通过对大数据的充分挖掘将产生更多新的应用,将催生更多的新业态出现,将会为我们带来更多的便利和惊喜。
但大数据在带来巨大机遇的同时也为我们带来了极大的挑战,要想充分从大数据中获益,需要解决下面一系列问题:
①,IT基础设施的挑战:
大数据的数据量太过庞大,Google每天的处理的数据量达到20PB,淘宝每天因为交易产生的数据就多达20TB。
现有的数据中心很难满足大数据的要求,需要考虑对整个IT架构进行革命性的重构。
存储能力的增长远远赶不上数据的增长,设计最合理的分层存储架构已成为信息系统的关键。
②,数据非结构化:
企业中80%的数据都是非结构化或者半结构化的数据,只有20%的数据是结构化的。
当今世界结构化数据增长率大概是32%,而非结构化数据增长则是63%,至2012年,非结构化的数据占有比例将达到互联网整个数据量的75%以上。
大数据的技术挑战主要是指非结构化的数据。
传统的关系数据库无法胜任大数据分析的任务,因为并行关系数据库系统的出发点是追求高度的数据一致性和容错性。
根据CAP理论(consistency、availability,tolerancetonetworkpartitions),在分布式系统中,一致性、可用性、分区容错性三者不可兼得,因而并行关系数据库必然无法获得较强的扩展性和良好的系统可用性。
系统的高扩展性是大数据分析最重要的需求,必须寻找高可扩展性的数据分析技术。
③,大数据的挖掘和分析:
数据无处不在,但许多数据是重复的或者没有价值,未来的任务主要不是获取越来越多的数据,而是数据的去冗分类、去粗取精、从数据中挖掘知识,变大数据为小数据。
数据的分类可能是大数据研究的基本科学问题,如同分类在生物学中的地位一样,各种各样的大数据如何按照不同性质分类需要认真研究,分类清楚了,知识标识问题也就解决了,许多数据分析问题也会迎刃而解。
伴随着技术的不断更新,用于处理大数据的Hadoop技术诞生了,Hadoop是对上述解决方案最好的实现框架。
Hadoop平台是Apache开源设计的,它是部署在廉价的计算机集群之上的一个分布式计算框架。
与PC机类似,Hadoop也为应用程序提供一组稳定、灵活、可靠的接口。
Hadoop包括许多子项目,如HDFS、HBase、MapReduce等。
其中,分布式文件系统(HDFS)主要用来存储非结构化数据的;HBase主要用来存储半结构化数据的;Hadoop中的DBInputFormat接口是用来读取关系数据库中的数据;MapReduce作为一种并行编程模型,可以很好的实现大数据时代数据的计算任务;Pig作为大数据分析平台,可以为用户提供多种接口。
以MapReduce和Hadoop为代表的非关系数据分析技术,以其适合大规模并行处理、简单易用等突出优势,在互联网信息搜索和其他大数据分析领域取得重大进展,已成为目前大数据分析的主流技术。
2.研究现状
在大数据时代,海量数据存储技术具有重大的研究意义和市场价值,随着数据量的增长和数据结构复杂度的提高,存储技术不断更新换代,存储产品也层出不穷。
存储产品从最早的网络文件系统、Andrew文件系统、分布式档案系统等,到后来的XFS、GFS等集群文件系统,在存储模式和存储量等方面发生了巨大的变化。
为了降低使用成本,目前的分布式系统趋于建立在廉价的服务器、PC或者普通存储设备之上,由于海量数据存储系统的规模巨大和系统设计复杂,服务器故障、设备故障、软件出错的频率较高,因此如何构建自组织能力强、可靠性高、可伸缩性好的系统成为存储系统设计的关键任务。
经过近几十年的探索、实践和研究,人们发现基于智能存储设备的存储技术符合上述条件,所以该技术也成为了目前存储技术研究的焦点。
以下是针对不同数据结构类型的具有代表性的智能存储设备系统。
分布式文件系统:
它是用于存储海量非结构化数据的系统,最具有代表性是HDFS,HDFS将大规模数据分割为多个数据块,然后将这些数据块存储在分布式集群的子节点中,供MapReduce并行读取。
该集群具有较高的可扩展性、较高的容错性。
分布式Key/Value存储引擎:
它是用于存储海量半结构化数据的系统,最具代表性的是HBase。
HBase也是一种分布式存储系统,具有高性能、高可靠性、可伸缩性、面向列等特点,它与关系型数据库系统的存储内容不同,HBase存储的是无模式的数据表。
分布式并行数据库系统:
它是用于存储海量结构化数据的系统,Greenplum是海量并行数据处理架构,是一种无共享的分布式并行数据库系统。
Greenplum采用了主从架构,主节点用于存储元数据信息,要被存储的数据散列存储在多台从服务器上,并且这些数据在其它从节点上存有备份,从而提高了系统的容错性。
从以上三种不同结构的智能存储系统可以看出,这些存储系统具有的共同特点是:
采用主从式的分布式集群;对数据进行副本备份。
Hadoop实现了不同数据类型的智能存储系统的集成,解决了大数据时代的数据存储问题。
3.Hadoop存在的缺陷
Hadoop作为一个基础数据处理平台,虽然其应用价值已得到大家认可,但仍存在很多问题,以下是主要几个:
①.Namenode/jobtracker单点故障。
Hadoop采用的是master/slaves架构,该架构管理起来比较简单,但存在致命的单点故障和空间容量不足等缺点,这已经严重影响了Hadoop的可扩展性。
②.HDFS小文件问题。
在HDFS中,任何block,文件或者目录在内存中均以对象的形式存储,每个对象约占150byte,如果有10000000个小文件,每个文件占用一个block,则namenode需要2G空间。
如果存储1亿个文件,则namenode需要20G空间。
这样namenode内存容量严重制约了集群的扩展。
③.jobtracker同时进行监控和调度,负载过大。
为了解决该问题,yahoo已经开始着手设计下一代HadoopMapReduce[1]。
他们的主要思路是将监控和调度分离,独立出一个专门的组件进行监控,而jobtracker只负责总体调度,至于局部调度,交给作业所在的client。
④.数据处理性能。
很多实验表明,其处理性能有很大的提升空间。
Hadoop类似于数据库,可能需要专门的优化工程师根据实际的应用需要对Hadoop进行调优,有人称之为“HadoopPerformanceOptimization”(HPO)。
4.Hadoop的优化方法
对于Hadoop,主要有下面几个优化思路:
①从应用程序角度进行优化。
由于mapreduce是迭代逐行解析数据文件的,怎样在迭代的情况下,编写高效率的应用程序,是一种优化思路。
②对Hadoop参数进行调优。
当前hadoop系统有190多个配置参数,怎样调整这些参数,使hadoop作业运行尽可能的快,也是一种优化思路[2]。
③从系统实现角度进行优化。
这种优化难度最大,它是从hadoop实现机制角度,发现当前Hadoop设计和实现上的缺点,然后进行源码级地修改。
该方法虽难度大,但往往效果明显。
4.1:
从应用程序角度进行优化
①避免不必要的reduce任务。
如果要处理的数据是排序且已经分区的,或者对于一份数据,需要多次处理,可以先排序分区;然后自定义InputSplit,将单个分区作为单个mapred的输入;在map中处理数据,Reducer设置为空。
这样,既重用了已有的“排序”,也避免了多余的reduce任务。
②外部文件引入。
有些应用程序要使用外部文件,如字典,配置文件等,这些文件需要在所有task之间共享,可以放到分布式缓存DistributedCache中(或直接采用-files选项,机制相同)。
更多的这方面的优化方法,还需要在实践中不断积累。
③为job添加一个Combiner。
为job添加一个combiner可以大大减少shuffle阶段从maptask拷贝给远程reducetask的数据量。
一般而言,combiner与reducer相同。
④根据处理数据特征使用最适合和简洁的Writable类型。
Text对象使用起来很方便,但它在由数值转换到文本或是由UTF8字符串转换到文本时都是低效的,且会消耗大量的CPU时间。
当处理那些非文本的数据时,可以使用二进制的Writable类型,如IntWritable,FloatWritable等。
二进制writable好处:
避免文件转换的消耗;使maptask中间结果占用更少的空间。
⑤使用StringBuffer而不是String。
当需要对字符串进行操作时,使用StringBuffer而不是String,String是read-only的,如果对它进行修改,会产生临时对象,而StringBuffer是可修改的,不会产生临时对象。
⑥调试。
最重要,也是最基本的,是要掌握MapReduce程序调试方法,跟踪程序的瓶颈。
4.2:
对参数进行调优
4.2.1:
参数自动调优
Hadoop目前有190多个配置参数,其中大约有25个对hadoop应用程序效率有显著的影响。
首先分析database优化思路。
Database根据用户输入的SQL建立一个代价模型:
,其中y表示查询q优化目标(如运行时间),p表示q的查询计划,r表示为执行计划p而申请的资源量,d表示一些统计信息。
数据库会根据该代价模型评估不同的查询计划,并选择一个最优的执行查询。
这种数据库模型很难扩展应用到mapreduce环境中,主要是因为:
①mapreduce作业一般是采用C,C++或java编写,与声明性语言SQL有明显不同。
②缺少有关输入数据的统计信息。
Mapreduce作业通常是运行时解析动态输入文件的,因而运行之前schema或者统计信息均是未知的。
③它们的优化空间不同。
数据库的查询优化空间(主要是选择最优的plan)与mapreduce的优化空间(主要是配置参数调优)不同。
我们提出三种可行的方案:
第一种是基于采样的方法,借鉴Terasort作业的思路,先对输入数据进行采样,然后通过样本估算不同配置下作业的执行时间,最后选择一种最优的配置。
该方法需要解决的一个问题是,由于reduce阶段和map阶段存在数据依赖,因而map完成之前,reduce的所有信息均是未知的。
有一种也是可行的思路是,执行作业之前,先采样选择一个样本组成一个小作业,然后执行该小作业以估算大作业性能。
该方法也存在一个需要解决的问题,怎样采样才能使样本最能代表总体?
第二种是LateBinding,即延迟绑定,其思想是延迟设置其中的一个或多个参数,直到job已经部分执行,且这些参数可以确定。
比如hadoop中的combiner操作实际就是采用的这一机制,作业在执行完map()之前不知道要不要进行combine。
第三种是Competition-basedApproaches,其思想是,首先,同时执行多个配置有不同参数的task,然后,尽快决定哪种配置的task执行速度快,最后,杀掉其它task。
4.2.2:
参数手动设置
4.2.2.1:
Linux文件系统参数调整
①noatime和nodiratime属性。
文件挂载时设置这两个属性可以明显提高性能。
。
默认情况下,Linuxext2/ext3文件系统在文件被访问、创建、修改时会记录下文件的时间戳,比如:
文件创建时间、最近一次修改时间和最近一次访问时间。
如果系统运行时要访问大量文件,关闭这些操作,可提升文件系统的性能。
Linux提供了noatime这个参数来禁止记录最近一次访问时间戳。
②readaheadbuffer。
调整linux文件系统中预读缓冲区地大小,可以明显提高顺序读文件的性能。
默认buffer大小为256sectors,可以增大为1024或者2408sectors(注意,并不是越大越好)。
可使用blockdev命令进行调整。
③避免RAID和LVM操作。
避免在TaskTracker和DataNode的机器上执行RAID和LVM操作,这通常会降低性能。
4.2.2.2:
Hadoop通用参数调整
①dfs.namenode.handler.count或mapred.job.tracker.handler.count。
namenode或者jobtracker中用于处理RPC的线程数,默认是10,较大集群,可调大些,比如64。
②dfs.datanode.handler.count。
datanode上用于处理RPC的线程数。
默认为3,较大集群,可适当调大些,比如8。
需要注意的是,每添加一个线程,需要的内存增加。
③tasktracker.http.threads。
HTTPserver上的线程数。
运行在每个TaskTracker上,用于处理maptask输出。
大集群,可以将其设为40~50。
4.2.2.3:
HDFS相关参数设置
①dfs.replication。
文件副本数,通常设为3,不推荐修改。
②dfs.block.size。
HDFS中数据block大小,默认为64M,对于较大集群,可设为128MB或者256MB。
(也可以通过参数mapred.min.split.size配置)
③mapred.local.dir和dfs.data.dir。
这两个参数mapred.local.dir和dfs.data.dir配置的值应当是分布在各个磁盘上目录,这样可以充分利用节点的IO读写能力。
运行Linuxsysstat包下的iostat-dx5命令可以让每个磁盘都显示它的利用率。
4.2.2.4:
MapReduce相关配置
①{map/reduce}.tasks.maximum。
同时运行在TaskTracker上的最大map/reducetask数,一般设为(core_per_node)/2~2*(cores_per_node)。
②io.sort.factor。
当一个maptask执行完之后,本地磁盘上(mapred.local.dir)有若干个spill文件,maptask最后做的一件事就是执行mergesort,把这些spill文件合成一个文件(partition)。
执行mergesort的时候,每次同时打开多少个spill文件由该参数决定。
打开的文件越多,不一定mergesort就越快,所以要根据数据情况适当的调整。
③mapred.child.java.opts。
设置JVM堆的最大可用内存,需从应用程序角度进行配置。
4.2.2.5:
MapTask相关配置
①io.sort.mb。
Maptask的输出结果和元数据在内存中所占的buffer总大小。
默认为100M,对于大集群,可设为200M。
当buffer达到一定阈值,会启动一个后台线程来对buffer的内容进行排序,然后写入本地磁盘(一个spill文件)。
②io.sort.spill.percent。
这个值就是上述buffer的阈值,默认是0.8,即80%,当buffer中的数据达到这个阈值,后台线程会起来对buffer中已有的数据进行排序,然后写入磁盘。
③io.sort.record。
Io.sort.mb中分配给元数据的内存百分比,默认是0.05。
这个需要根据应用程序进行调整。
④press.map.output/
Mpress。
中间结果和最终结果是否要进行压缩,如果是,指定压缩式(Mpress.map.output.codec/
Mpress.codec)。
推荐使用LZO压缩。
Intel内部测试表明,相比未压缩,使用LZO压缩的TeraSort作业运行时间减少60%,且明显快于Zlib压缩。
4.2.2.6:
ReduceTask相关配置
①Mapred.reduce.parallel。
Reduceshuffle阶段copier线程数。
默认是5,对于较大集群,可调整为16~25。
4.3:
从系统实现角度进行优化
4.3.1:
在可移植性和性能之间进行权衡
下面主要针对HDFS进行优化,我们分析可知HDFS性能低下的两个原因:
调度延迟和可移植性假设[3]。
①调度延迟。
Hadoop采用的是动态调度算法,即:
当某个tasktracker上出现空slot时,它会通过HEARBEAT(默认时间间隔为3s,当集群变大时,会适当调大)告诉jobtracker,之后jobtracker采用某种调度策略从待选task中选择一个,再通过HEARBEAT告诉tasktracker。
从整个过程看,HDFS在获取下一个task之前,一直处于等待状态,这造成了资源利用率不高。
此外,由于tasktracker获取新task后,其数据读取过程是完全串行化的,即:
tasktracker获取task后,依次连接namenode,连接datanode并读取数据,处理数据。
在此过程中,当tasktracker连接namenode和datanode时,HDFS仍在处于等待状态。
为了解决调度延迟问题,可以考虑的解决方案有:
重叠I/O和CPU阶段(pipelining),task预取(taskprefetching),数据预取(dataprefetching)等
②可移植性假设。
为了增加Hadoop的可移植性,它采用java语言编写,这实际上也潜在的造成了HDFS低效。
Java尽管可以让Hadoop的可移植性增强,但是它屏蔽了底层文件系统,这使它没法利用一些底层的API对数据存储和读写进行优化。
首先,在共享集群环境下,大量并发读写会增加随机寻道,这大大降低读写效率;另外,并发写会增加磁盘碎片,这将增加读取代价(HDFS适合文件顺序读取)。
为了解决该问题,可以考虑的解决方案有:
修改tasktracker上的线程模型,现在Hadoop上的采用的模
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Hadoop 数据 环境 性能 优化
![提示](https://static.bingdoc.com/images/bang_tan.gif)