分享

Hadoop Job Tuning

Job Tracker Related
严格来说,下面这个配置项,是决定HDFS文件block数量的多少(也就是文件个数),但是它会间接的影响Job Tracker的调度和内存的占用(其实更能影响name node内存的使用)。
dfs.block.size
这个配置项定义了在HDFS上每个block的大小,它的值是以字节为单位。可以在配置文件hadoop-site.xml(Hadoop 0.20 以前版本)定义,也可以在JobConf里定义。
mapred.map.tasks.speculative.execution=true
mapred.reduce.tasks.speculative.execution=true
这两个是推测执行的配置项,当然如果你从来不关心这两个选项也没关系,它们默认值是true。
所谓的推测执行,就是当所有task都开始运行之后,Job Tracker会统计所有任务的平均进度,如果某个task所在的task node机器配置比较低或者CPU load很高(原因很多),导致任务执行比总体任务的平均执行要慢,此时Job Tracker会启动一个新的任务(duplicate task),原有任务和新任务哪个先执行完就把另外一个kill掉,这也是我们经常在Job Tracker页面看到任务执行成功,但是总有些任务被kill,就是这个原因。
mapred.child.java.opts
一般来说,都是reduce耗费内存比较大,这个选项正是用来设置JVM堆的最大可用内存,但是也不要设置太大,如果超过2G,应该考虑从程序设计角度去优化。
Map Related
Input Split的大小,决定了一个Job拥有多少个map,默认64M每个Split,如果输入的数据量巨大,那么默认的64M的block会有几万甚至几十万的Map Task,集群的网络传输会很大,最严重的是给Job Tracker的调度、队列、内存都会带来很大压力。
mapred.min.split.size
这个配置项决定了每个 Input Split的最小值,也间接决定了一个Job的map 数目。
mapred.compress.map.output
压缩Map的输出应该作为一个习惯,这样做有两个好处:
a)      压缩是在内存中进行,所以写入map本地磁盘的数据就会变小,大大减少了本地IO次数
b)      Reduce从每个map节点copy数据,也会明显降低网络传输的时间
补充:数据序列化其实效果会更好,无论是磁盘IO还是数据大小,都会明显的降低。
io.sort.mb
以MB为单位,默认100M,通常来看,这个值太小了。
这个选项定义了map输出结果在内存占用buffer的大小,当buffer达到一定阈值,会启动一个后台线程来对buffer的内容进行排序,然后写入本地磁盘(一个spill文件)。
在内存中的buffer如下图:(kvstart,kvend,kvindex为hadoop源码中操作buffer的变量):
1.png
根据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
同时打开的文件句柄的数量,默认是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)
2.png
  
Reduce Related
提高Reduce的执行效率,除了在Hadoop框架方面的优化,重点还是在代码逻辑上的优化!比如:对Reduce接受到的value可能有重复的,此时如果用Java的Set或者STL的Set来达到去重的目的,那么这个程序不是扩展良好的(non-scalable),受到数据量的限制,当数据膨胀,内存势必会溢出?
Io.sort.mb/io.sort.factor/ io.sort.spill.percent
其作用和Map阶段的作用一样,都是控制排序时使用内存的大小、句柄数量、阈值大小
mapred.reduce.parallel.copies
Reduce copy数据的线程数量,默认值是5
Reduce到每个完成的Map Task copy数据(通过RPC调用),默认同时启动5个线程到map节点取数据。这个配置还是很关键的,如果你的map输出数据很大,有时候会发现map早就100%了,reduce一直在1% 2%。。。。。。缓慢的变化,那就是copy数据太慢了,5个线程copy 10G的数据,确实会很慢,这时就要调整这个参数了,但是调整的太大,又会事半功倍,容易造成集群拥堵,所以 Job tuning的同时,也是个权衡的过程,你要熟悉你的数据!
mapred.job.shuffle.input.buffer.percent
当指定了JVM的堆内存最大值以后,上面这个配置项就是Reduce用来存放从Map节点取过来的数据所用的内存占堆内存的比例,默认是0.7,既70%,通常这个比例是够了,但是我们讨论的还是大数据的情况,所以这个比例还是小了一些,0.8-0.9之间比较合适。(前提是你的reduce函数不会疯狂的吃掉内存)
mapred.job.shuffle.merge.percent(默认值0.66)
mapred.inmem.merge.threshold(默认值1000)
这是两个阈值的配置项,第一个指的从Map节点取数据过来,放到内存,当达到这个阈值之后,后台启动线程(通常是Linux native process)把内存中的数据merge sort,写到reduce节点的本地磁盘;
第二个指的是从map节点取过来的文件个数,当达到这个个数之后,也进行merger sort,然后写到reduce节点的本地磁盘;这两个配置项第一个优先判断,其次才判断第二个thresh-hold。
从实际经验来看,mapred.job.shuffle.merge.percent默认值确实太小了,完全可以设置到0.8左右;第二个默认值1000,完全取决于map输出数据的大小,如果map输出的数据很大,默认值1000反倒不好,应该小一些,如果map输出的数据不大(light weight),可以设置2000或者以上,都没问题。
后记
大规模数据处理是云计算平台的挑战,涉及的技术难点很多:
1: 并行优化
2: 海量存储(HDFS存在诸多限制)【NoSQL】
3: 大规模数据不仅仅是用来静态的处理,怎么样动起来?比如实时查询、实时更新、状态跟踪(数据的生命周期),目前开源社区的NoSQL技术还没有做到,或者很好的达到这些要求,这也是今后海量存储系统面临的技术难点。

没找到任何评论,期待你打破沉寂

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条