FreeBSD下安装配置Hadoop集群(性能调优)

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 >

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 >

当然每台服务器都需要定义这个才可以。

还有一个很重要的优化是槽位的设置和调度器的选择，这个直接关系到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 >

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 >

对于map槽位的内存占用，我的理解是这样，内存总数/CPU核数/4，上下可以浮动几百兆。

对于reduce槽位是内存总数/cpu核数/2。

然后简单说下调度器的问题，hadoop默认的调度器是FIFO，就是先入先出，通常来说，这就比较够用了。但是如果集群规模较小，计算任务又比较多，还需要细分不同任务的槽位分配，就还是配置其他的调度器比较好。

常用的有两种第三方调度器，yahoo开发的Capacity Scheduler和Facebook贡献的Fair Scheduler。翻译过来叫计算能力调度器和公平调度器，可能大家听公平调度器听的比较多，不过目前我们公司主要是用计算能力调度器。

因为配置的XML太长，我就不贴了，需要了解计算能力调度器的配置方法，可以访问我的同事老赵的技术博客。

http://blog.csdn.net/azhao_dn/article/details/7070327

在我们的应用场景里，计算能力被分为了3类，每个分类的map/reudce槽位数是不同的，根据统计平时的计算量来固定分配的槽位数。default，rush，和hive，其中普通的streaming的计算方式放入default的分类中执行，日志清洗和入库单独使用rush分类，hive，顾名思义，就是给hive数据库单独使用的。这个分配的map/reduce是最多的。平时定时任务的70%左右都是用hive跑的，临时数据查询95%依赖hive。

这样做的好处是计算任务的计算能力被隔离，互不干扰。可根据业务需求进行分类。避免任务抢占造成的资源大量消耗。