1.概述
其实，在从事过调优相关的工作后，会发现其实调优是一项较为复杂的工作。而对于Hadoop这样复杂且庞大的系统来说，调优更是一项巨大的工 作，由于Hadoop包含Common、HDFS、MapReduce、YARN等模块，每个模块都有可以根据自身业务进行优化的工作，本篇博客也是针对 某些模块进行调优剖析。
在进行Hadoop调优时，不仅仅只是针对其性能调优，还是涉及到更底层的硬件，OS以及JVM等的优化，如下图所示：
![]()
针对以上内容进行优化，均有可能对Hadoop的性能进行提升。
2.OS调优
由于Hadoop的设计决定，其只能用于Linux操作系统作为生产环境。在实际应用场景之中，对Linux参数进行优化，可以在一定程度上提升作业的允许效率。
在Hadoop集群当中，其内部的一些通信依赖网络，需调整Linux参数net.core.somaxconn，让其处于一个足够大的状态。
在Linux系统当中，如果一个进程的内存不足，其内存中的部分数据会暂时写到磁盘上，在需要的时候，会再将磁盘中的数据动态的置换到内存当 中，这样一来，一些不必要的流程就会显现出来。通常，这会导致进程的执行效率降低。再分布式环境当中，使用MapReduce这样的计算模型时，可以通过 控制每个Job的处理数量和每个Task运行过程使用的缓冲区的大小，避免我们去使用Swap分区。通过/etc/sysctl.conf文件中的 vm.swappiness参数来达到目的。
磁盘IO性能没有CPU和内存这样发展迅猛，因而它成为OS当中一个主要的性能瓶颈。改进磁盘IO性能也是重要的优化手段之一。可以使用Linux的blockdev命令来设置预读取的缓冲区大小，以便提高Hadoop的文件读取性能。
3.JVM
在YARN里面，可以启用JVM的重用机制来得到性能的提升。启用该功能能够让一些Task的执行效率提高2～3倍。在Hadoop2.x中，YARN的结构不同于MRV1，因而其配置有些许变化。
YARN的默认配置会禁用该组件，即不允许重用JVM。首先，我们需要明白YARN是如何执行一个MapReduce的Job。其步骤如下所示：
- RM（Resource Manager）里面的AM（Application Manager）会为每个Application（一个MR的Job）在NM（NodeManager）里面申请一个Container
- 在申请到的Container里面启动一个Application Master，Container在YARN中分配资源的容器（内存、CPU、磁盘空间等），它启动便会对应的启动一个JVM
- Application Master会持续为Application包含的每一个Task（一个Map Task或者Reduce Task）向RM申请一个Container
- 每得到一个Container，该Container所属的NM将此Container启动
- 该Container执行对应的Task
- 对应的Task执行完毕，该Container被NM回收，而Container所拥有的JVM相应的推出
通过上述的流程可以看出，这种情况下，每一个JVM仅只执行了一个Task，JVM并未被重用。
因而，用户可以通过启用ubertask属性来重用JVM，在同一个Container里面一次执行多个Task，可以在mapred-site.xml中配置对应的参数即可，内容如下所示：
<property>
<name>mapreduce.job.ubertask.enable</name>
<value>true</value>
</property>
如果启用该功能，会将一个Application中的所有子Task在同一个JVM里面执行，到达JVM重用的目的。该JVM负责Application中的Application Master中所用的JVM，即运行在Container当中。
最后，我们来看当ubertask功能被启用的时候，YARN是如何执行一个application的。首先，RM里的AM会为每一个 Application在NM里面申请一个Container，然后在该container里面启动一个Application Master。Containe启动时便会相应启动一个JVM。此时，如果ubertask功能被启用，Application Master会在JVM中按照顺序依次在Container中执行每一个Task，这样Application Master便不用再为每一个Task向RM去申请一个单独的Container，从而达到了重用JVM（资源重用）的目的。
4.Hadoop调优
在对Hadoop调优时，这是一个庞大的任务，这里进行分解来看，按Hadoop的组成模块来分，比如：我们可以安装HDFS、 MapReduce、YARN等模块去优化对应的模块。若是在细分，我们可以优化其各个组件的相关配置文件，其每个模块都有对应的XML文件，在系统启动 时，会通过Configure加载到系统当中，而对应的XML文件当中，配置的参数和属性比较多，有些参数是根据业务本身去优化，如：心跳间隔、缓冲区大 小、JVM子进程最大内存、小文件的合并数、归并map输出数据占比等等。
另外，在处理一些IO密集的应用，会在执行MapReduce时产生大量的中间输出数据（Map Task执行阶段），而产生的这些数据对于使用者来说是并不关心的（透明化）。这里，可以思考一下，有木有一种办法能够集中处理这些输出数据。答案是肯定 的，在MapReduce中支持压缩算法，我们可以在执行这部分流程时，将中间输出数据压缩存储，这样在IO性能方面有会有明显的提升。然而，万物皆有因 果，在选择压缩算法时，需考虑压缩比和压缩效率，在一些压缩算法当中，有的压缩比非常可观，然而其压缩效率却非常低下；反之，有的压缩比较差，然其压缩效 率非常理想。因为，我们需要在压缩比和压缩效率之间做一个平衡，选择合适的算法，去平衡二者的关系。
目前，存在许多的压缩格式，如：GZIP，ZIP，LZO，Snappy等等，测试表明其中LZO和Snappy较为可观（具体量化指标图不方便给出）。当然，这个也不是绝对的，是当下业务去测试，然后选择合适的压缩格式。
上面提点过预读取机制，可以通过预读取机制来有效的提升磁盘IO的读性能。通过改机制提高HDFS的读性能以及MapReduce作业的执行效率。
当然，从应用程序也是有优化的空间的，处理应用程序当中配置必要的作业参数之外，其本身的编写方式对性能也是有影响的。在执行一大批 MapReduce作业时，若是设置一个Combiner，对于提供作业的性能大有裨益。在了解MapReduce（其分两部分，其一为计算模型，其二为 运行环境，尽管Hadoop版本升级到2.x，然其计算模型不变，变得只是其运行环境。其运行环境是基于YARN的资源管理）的计算模型时，在弄明白 Combiner阶段的好处后，会发现，我们在编写相关作业时，添加Combiner可减少Map Task的中间输出结果，从而减少各个Reduce Task的远程Copy数据量，最终带来的益处是缩短了Map和Reduce两者的执行时间。
同样，我们在选择Hadoop的相关类型时，如Writeable。在MapReduce中，Map Task和Reduce Task的输入和输出的数据类型均为Writable的衍生类型，其包含IntWritable、LongWriteable、 FloatWritable等。在编写相关代码时，选择合适的类型可以大大提升其性能。例如在处理整型数据之时，直接采用IntWritable比先以 Text类型读取在通过对应的方法转化为整型来的高效。
5.总结
在对Hadoop的优化过程，是一个探索和实践的过程，有一些优化的手段和技巧也是需要平时在工作的当中去总结的，以上给出的优化点，也是有限 的，并未尽数述说，如我们也可以通过对任务的级别参数的调整，来达到有效的优化手段，对Map Task和Reduce Task阶段的调优等。还有未言之知识点有待后续去发掘，以上只是起到点拨之效。
6.结束语
这篇博客就和大家分享到这里，如果大家在研究学习的过程当中有什么问题，可以加群进行讨论或发送邮件给我，我会尽我所能为您解答，与君共勉！
