Hadoop集群的配置调优

一、背景
HADOOP的配置优化，涉及到多方面，本部分主要针对HADOOP集群的配置优化进行汇总，以供参考。

二、配置
1、hdfs-site.xml配置文件
1)、dfs.block.size：块大小的设置，也就是说文件按照多大的size 来切分块。
一般来说，块的大小也决定了你map 的数量。举个例子：我现在有一个1T 的文件，如果我的块size 设置是默认的64M，那么在HDFS 上产生的块将有1024000/64=16000 块。
如果我们以TextInputFormat 来处理该1T 的文件，那么将会产生16000 个map 来处理。这样的多的map 明显是不合理的。所以，如果我们将block 的size 设置成512M，那么，将1T 的文件作为输入文件，将产生2000 个map，计算的时候效率将提升不少。
[b]因此，block size 的大小是需要根据输入文件的大小以及计算时产生的map 来综合考量的。一般来说，文件大，集群数量少，还是建议将block size 设置大一些的好。[/b]

2）、dfs.replication：存放数据文件的份数。
设置为1，就是在集群中存一份。如果设置为2，即做一份备份，也就是说数据在集群中有2
份。还是以1T 的数据为例，如果设置1，集群中就存在1T 的文件，如果设置为2，那么集群占用空间为2T。
当然，这个备份还有个基于机架感知的备份机制（本地存放、同机架存放、异机架存放）如果
不配置机架，默认都在一个机架上，之所以做机架感知的备份就是为了做到异地容灾。因为我现在的集群都在一个机房，就是做了机架配置，也不能做异地容灾。要是机房断电，谁也不能容灾谁。
但是如果你的集群分别存放在2 个机房，还是可以考虑做机架配置，然后将备份数量设置为3。
备份数量有利有弊，备份数量多，节点挂个几个没影响，数据依然完整。但是你的冗余数据会
增加。如果只设置为1，那就是节点一旦有挂掉的，就是block miss。
[b]一般来说，测试情况下建议设置为1，如果实际使用，所有机器都在一个机房，建议配置为2，如果集群分布在不同机房，还是试试配置为3 吧。[/b]

2、mapred-site.xml配置文件
1）、mapred.tasktracker.map.tasks.maximum和mapred.tasktracker.reduce.tasks.maximum：
这个2 个参数分别是用来设置的map 和reduce 的并发数量。实际作用就是控制同时运行的task的数量。这2 个参数实际上在配置的时候是需要结合计算节点的硬件配置以及任务调度模式来配置的。
举个例子吧。我现在有5 台机器，1 台master，4 台slave，配置都是2 个4 核CPU，8G 内存，1T 硬盘。我配置任务调度模式是默认的FIFO 模式。在这样的模式下，我配置并发map 为6，并发的reduce 为2。其实这样配置不难看出，map 和reduce 的并发数就等于CPU 的总核数。
网上有牛人建议：[b]如果使用fair 的调度模式，设置成相同，应该是可以的，但是如果是FIFO 模式，建议在map或是reduce 阶段，CPU 的核数没有得到充分的利用，有些可惜，所以，FIFO 模式下，还是尽量配置的map 并发数量多于redcue 并发数量。[/b]因此，我说这个参数的配置不仅仅要考虑硬件配置，还需要考虑到Job 的调度模式。需要说明的是，这个配置参数不同的节点可以配置不同。适用于硬件异构的集群。

2）、mapred.child.java.opts
这个参数是配置每个map 或reduce 使用的内存数量。默认的是200M。对于这个参数，我个人认为，如果内存是8G，CPU 有8 个核，那么就设置成1G 就可以了。实际上，在map 和reduce 的过程中对内存的消耗并不大，但是如果配置的太小，则有可能出现”无可分配内存”的错误。所以，Hadoop 开发者第四期Hadoop 集群的配置调优对于这个配置我总结了一个简单的公式：map/reduce 的并发数量(总和不大于CPU 核数)×
mapred.child.java.opts < 该节点机器的总内存。当然也可以等于，不过有点风险而已。

3）、mapred.reduce.tasks
设置reduce 的数量。一般来说在job 里面都会通过conf 来设置reduce 的数量，不采用这个参数。至于reduce 的数量，可以根据自己的reduce 业务逻辑复杂度以及输出的数据量来调整。

3、core-sit.xml配置文件
1）webinterface.private.actions
这个参数实际上就是为了方便测试用。允许在web 页面上对任务设置优先级以及kill 任务。需要注意的是，kill 任务是个缓慢的过程，它需要杀掉所有的任务task 然后才是任务结束。如果task数量多，可能有点慢，需要一些耐心等待。

三、配置信息加载顺序
需要说明一下，配置文件的加载顺序是：先加载默认的配置项（看看default 文件就知道默认配置项了），然后加载site 文件里的配置项，最后加载MR 代码里的配置项。所以，个性化的配置还是放在MR 代码中通过config.set 方法来设置比较合适。