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太长，我就不贴了，需要了解计算能力调度器的配置方法，可以访问我的同事老赵的技术博客。
在我们的应用场景里，计算能力被分为了3类，每个分类的map/reudce槽位数是不同的，根据统计平时的计算量来固定分配的槽位数。default，rush，和hive，其中普通的streaming的计算方式放入default的分类中执行，日志清洗和入库单独使用rush分类，hive，顾名思义，就是给hive数据库单独使用的。这个分配的map/reduce是最多的。平时定时任务的70%左右都是用hive跑的，临时数据查询95%依赖hive。
这样做的好处是计算任务的计算能力被隔离，互不干扰。可根据业务需求进行分类。避免任务抢占造成的资源大量消耗。
