分析从管理员角度对Hadoop进行调优
Hadoop管理员负责为用户作业提供一个高效的运行环境。管理员需要从全局出发，通过调整一些关键参数值提高系统的吞吐率和性能。总体上看，管理员需从硬件选择、操作系统参数调优、JVM参数调优和Hadoop参数调优等四个方面人手，为 Hadoop 用户提供一个高效的作业运行环境。
1.硬件选择
Hadoop自身架构的基本特点决定了其硬件配置的选型。Hadoop采用了master/slave架构，其中，master（JobTracker或者NameNode）维护了全局元数据信息，重要性远远大干 slave（TaskTracker或者DataNode）。在较低Hadoop版本中，master均存在单点故障问题，因此，master的配置应远远好于各个slave（TaskTracker或者DataNode），具体可参考Eric Sammer的《Hadoop Operations》 -书。
2.操作系统参数调优
由于Hadoop自身的一些特点，它只适合用于将Linux作为操作系统的生产环境。在实际应用场景中，管理员适当对Linux内核参数进行调优，可在一定程度上提高作业的运行效率，比较有用的调整选项如下。
(1)增大同时打开的文件描述符和网络连接上限
在Hadoop集群中，由于涉及的作业和任务数目非常多，对于某个节点，由于操作系统内核在文件描述符和网络连接数目等方面的限制，大量的文件读写操作和网络连接可能导致作业运行失败，因此，管理员在启动Hadoop集群时，应使用ulimit命令将允许同时打开的文件描述符数目上限增大至一个合适的值，同时调整内核参数net.core.somaxconn至一个足够大的值。
此外，Hadoop RPC采用了epoll作为高并发库，如果你使用的Linux内核版本在2.6.28以上，你需要适当调整epoll的文件描述符上限。
(2)关闭swap分区
在Linux中，如果一个进程的内存空间不足，那么，它会将内存中的部分数据暂时写到磁盘上，当需要时，再将磁盘上的数据动态置换到内存中，通常而言，这种行为会大大降低进程的执行效率。在MapReduce分布式计算环境中，用户完全可以通过控制每个作业处理的数据量和每个任务运行过程中用到的各种缓冲区大小，避免使用swap分区。具体方法是调整/etc/sysctl．conf文件中的vm.swappiness参数。
(3)设置合理的预读取缓冲区大小
磁盘I/O性能的发展远远滞后于CPU和内存，因而成为现代计算机系统的一个主要瓶颈。预读可以有效地减少磁盘的寻道次数和应用程序的I/O等待时间，是改进磁盘读I/O性能的重要优化手段之一。管理员可使用Linux命令blockdev设置预读取缓冲区的大小，以提高Hadoop中大文件顺序读的性能。当然，也可以只为Hadoop系统本身增加预读缓冲区大小。
(4)文件系统选择与配置
Hadoop的I/O性能很大程度上依赖于Linux本地文件系统的读写性能。Linux中有多种文件系统可供选择，比如ext3和ext4，不同的文件系统性能有一定的差别。如果公司内部有自主研发的更高效的文件系统，也鼓励使用。
在Linux文件系统中，当未启用noatime属性时，每个文件读操作会触发一个额外的文件写操作以记录文件最近访问时间。该日志操作可通过将其添加到mount属性中避免。
(5) 110调度器选择
主流的Linux发行版自带了很多可供选择的I/O调度器。在数据密集型应用中，不同的I/O调度器性能表现差别较大，管理员可根据自己的应用特点启用最合适的I/O调度器，具体可参考AMD的白皮书《Hadoop Performance Tuning Guide》。
除了以上几个常见的Linux内核调优方法外，还有一些其他的方法，管理员可根据需要进行适当调整。
3.JVM参数调优
由于Hadoop中的每个服务和任务均会运行在一个单独的JVM中，因此，JVM的一些重要参数也会影响Hadoop性能。管理员可通过调整JVM FLAGS和JVM垃圾回收机制提高Hadoop性能，具体可参考AMD的白皮书《Hadoop Performance Tuning Guide》。
4. Hadoop参数调优
1）合理规划资源
(1)设置合理的槽位数目
在Hadoop中，计算资源是用槽位(slot)表示的。slot分为两种：Map slot和Reduce slot。每种slot代表了一定量的资源，且同种slot（比如Map slot）是同质的，也就是说，同种slot代表的资源量是相同的。管理员需根据实际需要为TaskTracker配置一定数目的 Map slot和Reduce slot数目，从而限制每个TaskTracker上并发执行的Map Task和Reduce Task数目。
槽位数目是在各个TaskTracker上的mapred-site.xml中配置的，具体如表9-1所示。
表9-1
设置槽位数目
设置槽位数目
(2)
编写健康监测脚本
Hadoop允许管理员为每个TaskTracker配置一个节点健康状况监测脚本@。TaskTracker中包含一个专门的线程周期性执行该脚本，并将脚本执行结果通过心跳机制汇报给 JobTracker。一旦JobTracker发现某个TaskTracker的当前状况为“不健康”（比如内存或者 CPU使用率过高），则会将其加入黑名单，从此不再为它分配新的任务（当前正在执行的任务仍会正常执行完毕），直到该脚本执行结果显示为“健康”。健康监测脚本的编写和配置的具体方法。
需要注意的是，该机制只有Hadoop 0.20.2以上版本中有。
2）调整心跳配置
(1)调整心跳间隔
TaskTracker与JobTracker之间的心跳间隔大小应该适度。如果太小，JobTracker需要处理高并发的心跳信息，势必造成不小的压力；如果太大，则空闲的资源不能及时通知 JobTracker(进而JJ之分西己新ly.J Tagk),造成资源空闲，进而降叮氐系统{军吐率。对于中JJ、规模（300个节点以下）的Hadoop集群，缩短TaskTracker与JobTracker之间的心跳间隔可明显提高系统吞吐率。
在Hadoop l.0以及更低版本中，当节点集群规模小于300个节点时，心跳间隔将一直是3秒（不能修改）。这意味着，如果你的集群有10个节点，那么JobTracker平均每秒只需处理3.3
(10/3=3.3)个心跳请求；而如果你的集群有100个节点，那么JobTracker平均每秒也只需处理33个心跳请求。对于一台普通的服务器，这样的负载过低，完全没有充分利用服务器资源。综上所述，对于中小规模的Hadoop集群，3秒的心跳间隔过大，管理员可根据需要适当减小心跳间隔@，具体配置如表9—2所示。
表9-2设置心跳间隔
通常而言，心跳是由各个TaskTracker以固定时间间隔为周期发送给JobTracker的，心跳中包含节点资源使用情况、各任务运行状态等信息。心跳机制是典型的pull-based模型。 TaskTracker周期性通过心跳向JobTracker汇报信息，同时获取新分配的任务。这种模型使得任务分配过程存在较大延时：当TaskTracker出现空闲资源时，它只能通过下一次心跳（对于不同规模的集群，心跳间隔不同，比如1 000个币点的集群，心跳间隔为10秒钟）告诉JobTracker，而不能立刻通知它。为了减少任务分配延迟，Hadoop引入了带外心跳(out- of-band heartbeat)e。带外心跳不同于常规心跳，它是任务运行结束或者任务运行失败时触发的，能够在出现空闲资源时第一时间通知JobTracker，以便它能够迅速为空闲资源分配新的任务。带外心跳的配置方法如表9-3所示。
表9-3配置带外心跳
3）磁盘块配置
Map Task中间结果要写到本地磁盘上，对于I/O密集型的任务来说，这部分数据会对本地磁盘造成很大压力，管理员可通过配置多块磁盘缓解写压力。当存在多块可用磁盘时， Hadoop将采用轮询的方式将不同Map Task的中间结果写到这些磁盘上，从而平摊负载，具体配置如表9-4所示。
表9-4配置多个磁盘块
4）设置合理的RPC Handler和HTTP线程数目
(1)配置RPC Handler数目
JobTracker需要并发处理来自各个TaskTracker的RPC请求，管理员可根据集群规模和服务器并发处理能够调整RPC Handler数目，以使JobTracker服务能力最佳，配置方法如表9-5所示。
表9-5配置RPC Handler数目
在Shuffle阶段，Reduce Task通过HTTP请求从各个TaskTracker上读取Map Task中间结果，而每个TaskTracker通过Jetty Server处理这些HTTP请求。管理员可适当调整Jetty Server的工作线程数以提高Jetty Server的并发处理能力，具体如表9-6所示。
表9-6配置HTTP线程数目
5）慎用黑名单机制
当一个作业运行结束时，它会统计在各个TaskTracker上失败的任务数目。如果一个 TaskTracker失败的任务数目超过一定值，则作业会将它加到自己的黑名单中。如果一个 TaskTracker被一定数目的作业加入黑名单，则JobTracker会将该TaskTracker加入系统黑名单，此后JobTracker不再为其分配新的任务，直到一定时间段内没有出现失败的任务。
当Hadoop集群规模较小时，如果一定数量的节点被频繁加入系统黑名单中，则会大大降低集群吞吐率和计算能力，因此建议关闭该功能，具体配置方法可参考6.5.2小节。
6）启用批量任务调度
在Hadoop中，调度器是最核心的组件之一，它负责将系统中空闲的资源分配给各个任务。当前Hadoop提供了多种调度器，包括默认的FIFO调度器、Fair Scheduler、Capacity Scheduler等，调度器的调度效率直接决定了系统的吞吐率高低。通常而言，为了将空闲资源尽可能分配给任务，Hadoop调度器均支持批量任务调度e，即一次将所有空闲任务分配下去，而不是一次只分配一个，具体配置如表9.7所示(FIFO调度器本身就是批量调度器)。
表9-7配置批量任务调度
7
）选择合适的压缩算法
Hadoop通常用于处理I/O密集型应用。对于这样的应用，Map Task会输出大量中间数据，这些数据的读写对用户是透明的，如果能够支持中间数据压缩存储，则会明显提升系统的I/O性能。当选择压缩算法时，需要考虑压缩比和压缩效率两个因素。有的压缩算法有很好的压缩比，但压缩／解压缩效率很低；反之，有一些算法的压缩／解压缩效率很高，但压缩比很低。因此，一个优秀的压缩算法需平衡压缩比和压缩效率两个因素。
当前有多种可选的压缩格式，比如gzip、zip、bzip2、LZO e、Snappy@等，其中，LZO和Snappy在压缩比和压缩效率两方面的表现都比较优秀。其中，Snappy是Google开源的数据压缩库，它的编码／解码器已经内置到Hadoop l.0以后的版本中@；LZO则不同，它是基于GPL许可的，不能通过Apache来分发许可，因此，它的Hadoop编码／解码器必须单独下载。
下面以Snappy为例介绍如何让Hadoop压缩Map Task中间输出数据结果（在mapred-
site．xml中配置）：
mapred. compresg .map. output
true
mapred. map. output. compression. codec
org. apache .hadoop .iQ. compress. SnappyCodec< /value>
其中，“mapred.compress.map.output”表示是否要压缩Map Task中间输出结果，“mapred.map.output.compression.codec”表示采用的编码／解码器。
表9-8显示了Hadoop各版本是否内置了Snappy压缩算法。
表9-8配置Snappy压缩算法
8 ）启用预读取机制
前面提到，预读取机制可以有效提高磁盘的I/O读性能。由于Hadoop是典型的顺序读系统，采用预读取机制可明显提高HDFS读性能和MapReduce作业执行效率。管理员可为 MapReduce的数据拷贝和IFile文件读取启用预读取功能，具体如表9—9所示。
表9-9配置预读取功能
