hadoop的性能调优是个比较艰难的事情,由于这个系统的整个环境比较复杂,对于接触时间不长的人来说,配置都很难,更别说找出性能优化的点了。
性能优化涉及的方面很广,操作系统,网络配置,配置文件,调度器等等,抓出几点来说,但不敢说这几点就是别人所遇到的性能瓶颈,抛砖引玉而已。应用场景不同,优化配置肯定是各不相同的。
对于操作系统和网络环境的调优,这个需要讲的东西就太多了,无法在一篇文章里赘述。集中于几个关键词:sysctl,ulimit,hosts文件,内网配置。
尽量把hadoop集群配置在内网地址上,这就不用多说了吧。
下面主要探讨hadoop的配置文件和调度器的选择和开发。
以我公司的hadoop集群举例来说,主要是用了数据压缩和索引和对调度器策略的优化。
使用压缩是一个不错的选择,比如我们自己的集群用的是LZO的压缩方式,压缩比大概是原始数据的1/3,也就是说,1G的原始日志大概能压缩成300Mb左右,一方面压缩比不错,另一方面,读取速度也很不错,配合的是Native的lzo库。一个叫hadoop-gpl的东西。前一阵子泰国水灾,硬盘难买,以压缩的方式也可以多撑一阵子。
如果给lzo建立索引,效果就更好了
当然你需要先安装hadoopgpl。
core-site.xml
<
property
>
< name >io.compression.codecs </ name >
< value >org.apache.hadoop.io.compress.DefaultCodec,com.hadoop.compression.lzo.LzoCodec,com.hadoop.compression.lzo.LzopCodec,org.apache.hadoop.io.compress.GzipCodec,org.apache
.hadoop.io.compress.BZip2Codec </ value >
</ property >
< property >
< name >io.compression.codec.lzo.class </ name >
< value >com.hadoop.compression.lzo.LzoCodec </ value >
</ property >
< name >io.compression.codecs </ name >
< value >org.apache.hadoop.io.compress.DefaultCodec,com.hadoop.compression.lzo.LzoCodec,com.hadoop.compression.lzo.LzopCodec,org.apache.hadoop.io.compress.GzipCodec,org.apache
.hadoop.io.compress.BZip2Codec </ value >
</ property >
< property >
< name >io.compression.codec.lzo.class </ name >
< value >com.hadoop.compression.lzo.LzoCodec </ value >
</ property >
mapred-site.xml
<
property
>
< name >mapred.compress.map.output </ name >
< value >true </ value >
</ property >
< property >
< name >mapred.map.output.compression.codec </ name >
< value >com.hadoop.compression.lzo.LzoCodec </ value >
</ property >
< property >
< name >mapred.child.java.opts </ name >
< value >-Djava.library.path=/opt/hadoopgpl/native/Linux-amd64-64 </ value >
</ property >
< name >mapred.compress.map.output </ name >
< value >true </ value >
</ property >
< property >
< name >mapred.map.output.compression.codec </ name >
< value >com.hadoop.compression.lzo.LzoCodec </ value >
</ property >
< property >
< name >mapred.child.java.opts </ name >
< value >-Djava.library.path=/opt/hadoopgpl/native/Linux-amd64-64 </ value >
</ property >
当然每台服务器都需要定义这个才可以。
还有一个很重要的优化是槽位的设置和调度器的选择,这个直接关系到hadoop的计算能力。相同硬件情况下,配置好的集群的在计算相同任务的情况下,要比配置糟糕的集群快几倍乃至几十倍。
对于map/reduce槽位的配置还有job对java虚拟机的配置,我目前总结的规律大概是这样,namenode的槽位总数相加和等于CPU数量,同时map槽位数大概是reduce槽位的3倍,也就是这样,如果你有一个8核的服务器,map数量就应该是6,reduce数量是2。对于datanode,我们需要他的计算能力强一些,就把map和reduce槽位总和设置成cpu数量的2倍,同时map数是reduce数量的3倍,同样是8核的datanode,map数就是12,reduce数就是4。对于内存的使用,还是拿配置文件举例说明吧。
mapred-site on namenode:
<
property
>
< name >mapred.tasktracker.map.tasks.maximum </ name >
< value >6 </ value >
< final >true </ final >
</ property >
< property >
< name >mapred.tasktracker.reduce.tasks.maximum </ name >
< value >2 </ value >
< final >true </ final >
</ property >
< property >
< name >mapred.child.java.opts </ name >
< value >-Xmx1536M </ value >
</ property >
< name >mapred.tasktracker.map.tasks.maximum </ name >
< value >6 </ value >
< final >true </ final >
</ property >
< property >
< name >mapred.tasktracker.reduce.tasks.maximum </ name >
< value >2 </ value >
< final >true </ final >
</ property >
< property >
< name >mapred.child.java.opts </ name >
< value >-Xmx1536M </ value >
</ property >
mapred-site on datanode:
<
property
>
< name >mapred.tasktracker.map.tasks.maximum </ name >
< value >12 </ value >
< final >true </ final >
</ property >
< property >
< name >mapred.tasktracker.reduce.tasks.maximum </ name >
< value >4 </ value >
< final >true </ final >
</ property >
< property >
< name >mapred.map.child.java.opts </ name >
< value >-Xmx1224M </ value >
</ property >
< property >
< name >mapred.reduce.child.java.opts </ name >
< value >-Xmx2048M </ value >
</ property >
< name >mapred.tasktracker.map.tasks.maximum </ name >
< value >12 </ value >
< final >true </ final >
</ property >
< property >
< name >mapred.tasktracker.reduce.tasks.maximum </ name >
< value >4 </ value >
< final >true </ final >
</ property >
< property >
< name >mapred.map.child.java.opts </ name >
< value >-Xmx1224M </ value >
</ property >
< property >
< name >mapred.reduce.child.java.opts </ name >
< value >-Xmx2048M </ value >
</ property >
对于map槽位的内存占用,我的理解是这样,内存总数/CPU核数/4,上下可以浮动几百兆。
对于reduce槽位是内存总数/cpu核数/2。
然后简单说下调度器的问题,hadoop默认的调度器是FIFO,就是先入先出,通常来说,这就比较够用了。但是如果集群规模较小,计算任务又比较多,还需要细分不同任务的槽位分配,就还是配置其他的调度器比较好。
常用的有两种第三方调度器,yahoo开发的Capacity Scheduler和Facebook贡献的Fair Scheduler。翻译过来叫计算能力调度器和公平调度器,可能大家听公平调度器听的比较多,不过目前我们公司主要是用计算能力调度器。
因为配置的XML太长,我就不贴了,需要了解计算能力调度器的配置方法,可以访问我的同事老赵的技术博客。
在我们的应用场景里,计算能力被分为了3类,每个分类的map/reudce槽位数是不同的,根据统计平时的计算量来固定分配的槽位数。default,rush,和hive,其中普通的streaming的计算方式放入default的分类中执行,日志清洗和入库单独使用rush分类,hive,顾名思义,就是给hive数据库单独使用的。这个分配的map/reduce是最多的。平时定时任务的70%左右都是用hive跑的,临时数据查询95%依赖hive。
这样做的好处是计算任务的计算能力被隔离,互不干扰。可根据业务需求进行分类。避免任务抢占造成的资源大量消耗。