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

hadoop JOB的性能优化实践 博客分类: 数据挖掘&机器学习

程序员文章站 2024-02-18 22:18:22
...

使用了几个月的hadoopMR,对遇到过的性能问题做点笔记,这里只涉及job的性能优化,没有接触到

hadoop集群,操作系统,任务调度策略这些方面的问题。

hadoop MR在做大数据量分析时候有限的计算资源情况下只能不断的优化程序。

优化可以从两个方面进行:

1.hadoop配置

2.程序代码

程序代码包括的方面很多:job设计,算法,数据结构,代码编写。

hadoop配置优化

hadoop配置可分为mapp配置,reducer配置和hdfs配置。关于hadoop mapper和reducer阶段

处理流程和参数意义可以看这个帖子,说的比较详细hadoop mr 参数意义

这里再补充几个配置:

hadoop JOB的性能优化实践
            
    
    博客分类: 数据挖掘&机器学习

dfs.block.size

这个配置项定义了在HDFS上每个block的大小,它的值是以字节为单位。

可以在配置文件hadoop-site.xml(Hadoop 0.20 以前版本)定义,

也可以在JobConf里定义。hdfs中block size定义是以文件为粒度的。

 hadoop的mapper数基本由输入文件的block数决定,如果输入的block

size不够大,导致mapper处理时间很短(不到一分钟),大量这样的mapper

会严重降低计算性能。但是如果输入文件都是小文件,就算blocksize再大,每个

文件也会占一个block,这时候要通过合并小文件来减少mapper数,设置blocksize

是没用的。命令行设置块大小可以加参数,0.20以后的用

hadoop fs -D dfs.block.size=134217728 -put local_name remote_location

之前的可以用fs.local.block.size 参数

 

除了blocksize hadoop的inputformat也提供了在block的基础上更细粒度控制mapper

输入块大小,比如当前输入块128M,设置了最大分割size为64,则原先一个块被切分

成两个spliter了,也就产生了两个mapper。用这种方法可以有效增加mapper数,但对减少

mapper数好像没用。

FileInputFormat.setMaxInputSplitSize(job, size)

FileInputFormat.setMinInputSplitSize(job, size)

 

mapred.min.split.size这个参数也可以起到同样效果

 

mapred.map.tasks.speculative.execution 和 

mapred.reduce.tasks.speculative.execution

这两个选项是设置推测执行的任务,当所有task都开始运行之后,Job Tracker会统计所有任务的平均进度,

如果某个task所在的task node机器配置比较低或者CPU load很高(原因很多),导致任务执行比总体任务的平均执行要慢,

此时Job Tracker会启动一个新的任务(duplicate task),这个新任务就是推测任务,原有任务和新任务哪个先执行完就把另外一个kill掉,

这也是我们经常在Job Tracker页面看到任务执行成功,但是总有些任务被kill,就是这个原因。推测任务也是要占用计算资源,

因此计算资源紧张,任务执行本身很耗资源情况下可以考虑设置成false,禁止执行。

 

io.sort.mb

 

以MB为单位,默认100M,通常来看,这个值太小了,这个选项定义了map输出结果在内存占用buffer的大小,当buffer达到一定阈值,

会启动一个后台线程来对buffer的内容进行排序,然后写入本地磁盘(一个spill文件)。可以观察hadoop的日志,如果spill次数比较多说明

这个缓存大小设置太低,特别是那种mapper中处理数据会增多的逻辑尤其可以关注下。

 

根据map输出数据量的大小,可以适当的调整buffer的大小,注意是适当的调整,不是越大越好,假设内存无限大,io.sort.mb=1024(1G),

和io.sort.mb=300 (300M),前者未必比后者快,因为1G的数据排序一次和排序3次,每次300MB,一定是后者快(分而治之的思想)。

 

io.sort.spill.percent

 

这个值就是上述buffer的阈值,默认是0.8,既80%,当buffer中的数据达到这个阈值,后台线程会起来对buffer中已有的数据进行排序,

然后写入磁盘,此时map输出的数据继续往剩余的20% buffer写数据,如果buffer的剩余20%写满,排序还没结束,map task被block等待。

如果你确认map输出的数据基本有序(很少见),排序时间很短,可以将这个阈值适当调高,更理想的,如果你的map输出是有序的数据(基本不可能吧?),

那么可以把buffer设的更大,阈值设置为1.

 

Io.sort.factor

 

同时打开磁盘spill进行并行合并的文件数,默认是10。

当一个map task执行完之后,本地磁盘上(mapred.local.dir)有若干个spill文件,map task最后做的一件事就是执行merge sort,

把这些spill文件合成一个文件(partition),有时候我们会自定义partition函数,就是在这个时候被调用的。

执行merge sort的时候,每次同时打开多少个spill文件,就是由io.sort.factor决定的。打开的文件越多,不一定merge sort就越快,所以也要根据数据情况适当的调整。

补充:merge排序的结果是两个文件,一个是index,另一个是数据文件,index文件记录了每个不同的key在数据文件中的偏移量(这就是partition)

hadoop JOB的性能优化实践
            
    
    博客分类: 数据挖掘&机器学习

 

代码优化

有空再写

 

 

 

 

 

 

 

各种配置

Mapper端配置

 

 

 

 


1.Map逻辑处理后数据被展开,写磁盘次数剧增,可以观察日志中的spill次数,调整各个参数


2.中间结果能不展开就不展开,尽量缩小Mapper和reducer之间的数据传递


3.distribute cache中加载的数据能不用hashmap就尽量不要用,hashmap会使得内存占用量是原数据的5-10倍,其中

引用占了大量空间


4.distribute cache中加载的数据要尽可能简单,如果有复杂的处理逻辑可以单独开辟Mapper Reducer进行一轮处理,

避免每次mapper都要处理一遍,尽可能减少distribute cache的数据量


5.观察GC的情况,有时候是因为内存占用量高,频繁GC,严重影响处理速度


6.当逻辑本身很简单,但是处理速度很慢时候首先要怀疑Mapper和Reducer之间传输数据量过大,其次是GC情况


7.适当控制mapper的数量,特别是有distribute cache的场景