博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
hadoop作业map过程调优使用到的参数笔记
阅读量:5977 次
发布时间:2019-06-20

本文共 2446 字,大约阅读时间需要 8 分钟。

hot3.png

参数:io.sort.mb(default 100)

当map task开始运算,并产生中间数据时,其产生的中间结果并非直接就简单的写入磁盘。

而是会利用到了内存buffer来进行已经产生的部分结果的缓存,

并在内存buffer中进行一些预排序来优化整个map的性能。

每一个map都会对应存在一个内存buffer,map会将已经产生的部分结果先写入到该buffer中,

这个buffer默认是100MB大小,

但是这个大小是可以根据job提交时的参数设定来调整的,

当map的产生数据非常大时,并且把io.sort.mb调大,

那么map在整个计算过程中spill的次数就势必会降低,

map task对磁盘的操作就会变少,

如果map tasks的瓶颈在磁盘上,这样调整就会大大提高map的计算性能。

 

参数:o.sort.spill.percent(default 0.80,也就是80%)

map在运行过程中,不停的向该buffer中写入已有的计算结果,

但是该buffer并不一定能将全部的map输出缓存下来,

当map输出超出一定阈值(比如100M),那么map就必须将该buffer中的数据写入到磁盘中去,

这个过程在mapreduce中叫做spill。

map并不是要等到将该buffer全部写满时才进行spill,

因为如果全部写满了再去写spill,势必会造成map的计算部分等待buffer释放空间的情况。

所以,map其实是当buffer被写满到一定程度(比如80%)时,就开始进行spill。

这个阈值也是由一个job的配置参数来控制,

这个参数同样也是影响spill频繁程度,进而影响map task运行周期对磁盘的读写频率的。

但非特殊情况下,通常不需要人为的调整。调整io.sort.mb对用户来说更加方便。

 

参数:io.sort.factor

当map task的计算部分全部完成后,如果map有输出,就会生成一个或者多个spill文件,这些文件就是map的输出结果。

map在正常退出之前,需要将这些spill合并(merge)成一个,所以map在结束之前还有一个merge的过程。

merge的过程中,有一个参数可以调整这个过程的行为,该参数为:io.sort.factor。

该参数默认为10。它表示当merge spill文件时,最多能有多少并行的stream向merge文件中写入。

比如如果map产生的数据非常的大,产生的spill文件大于10,而io.sort.factor使用的是默认的10,

那么当map计算完成做merge时,就没有办法一次将所有的spill文件merge成一个,而是会分多次,每次最多10个stream。

这也就是说,当map的中间结果非常大,调大io.sort.factor,

有利于减少merge次数,进而减少map对磁盘的读写频率,有可能达到优化作业的目的。

 

参数:min.num.spill.for.combine(default 3)

当job指定了combiner的时候,我们都知道map介绍后会在map端根据combiner定义的函数将map结果进行合并。

运行combiner函数的时机有可能会是merge完成之前,或者之后,这个时机可以由一个参数控制,

即min.num.spill.for.combine(default 3),当job中设定了combiner,并且spill数最少有3个的时候,

那么combiner函数就会在merge产生结果文件之前运行。

通过这样的方式,就可以在spill非常多需要merge,并且很多数据需要做conbine的时候,

减少写入到磁盘文件的数据数量,同样是为了减少对磁盘的读写频率,有可能达到优化作业的目的。

 

参数:mapred.compress.map.output(default false)

减少中间结果读写进出磁盘的方法不止这些,还有就是压缩。

也就是说map的中间,无论是spill的时候,还是最后merge产生的结果文件,都是可以压缩的。

压缩的好处在于,通过压缩减少写入读出磁盘的数据量。

对中间结果非常大,磁盘速度成为map执行瓶颈的job,尤其有用。

控制map中间结果是否使用压缩的参数为:mapred.compress.map.output(true/false)。

将这个参数设置为true时,那么map在写中间结果时,就会将数据压缩后再写入磁盘,读结果时也会采用先解压后读取数据。

这样做的后果就是:写入磁盘的中间结果数据量会变少,但是cpu会消耗一些用来压缩和解压。

所以这种方式通常适合job中间结果非常大,瓶颈不在cpu,而是在磁盘的读写的情况。

说的直白一些就是用cpu换IO。

根据观察,通常大部分的作业cpu都不是瓶颈,除非运算逻辑异常复杂。所以对中间结果采用压缩通常来说是有收益的。

 

参数:mapred.map.output.compression.codec( default org.apache.hadoop.io.compress.DefaultCodec)

当采用map中间结果压缩的情况下,用户还可以选择压缩时采用哪种压缩格式进行压缩,

现在hadoop支持的压缩格式有:GzipCodec,LzoCodec,BZip2Codec,LzmaCodec等压缩格式。

通常来说,想要达到比较平衡的cpu和磁盘压缩比,LzoCodec比较适合。但也要取决于job的具体情况。

用户若想要自行选择中间结果的压缩算法,

可以设置配置参数:mapred.map.output.compression.codec=org.apache.hadoop.io.compress.DefaultCodec或者其他用户自行选择的压缩方式

转载于:https://my.oschina.net/osenlin/blog/500562

你可能感兴趣的文章
在DigitalOcean玩Kubernetes(K8S)
查看>>
双机概念
查看>>
php excel
查看>>
一些设计思想的汇集(2)
查看>>
GRUB and LVM and EVMS
查看>>
List集合的迭代器方法
查看>>
ECShop替换FCKeditor编辑器为KindEditor
查看>>
oracle 11g EM停止后无法启动
查看>>
面向对象是软件开发范式的根本性颠覆: 主体建模, 非目标导向, 松耦合, 非逻辑分解, 软件进化...
查看>>
OSI七层模型和TCP/IP四层模型
查看>>
ceph学习笔记之七 数据平衡
查看>>
windows下的php的memcache扩展的安装及memcache最新下载地址
查看>>
YOLOv3: 训练自己的数据(绝对经典版本1)
查看>>
POJ 1150 The Last Non-zero Digit 《挑战程序设计竞赛》
查看>>
Could not find artifact com.sun:tools:jar:1.5.0 解决办法
查看>>
神经网络---Hessian矩阵
查看>>
TreeMap之floorKey
查看>>
phpstorm xdebug remote配置
查看>>
STL札记3-2(hashtable关联容器set、map)
查看>>
Android 打开屏幕旋转
查看>>