一、测试目的
主要是测试hadoop集群分布式计算的速率跟数据大小和计算节点数量的关系。
二、环境
硬件：浪潮NF5220。
系统：CentOS 6.1
Master节点在母机CentOS上，分配4CPU，13G内存。
其余三个slave节点在母机的KVM虚拟机上，系统一样是CentOS6.1。硬件配置：内存1G，4 CPU，每个100G容量大小的硬盘。
三、步骤及测试结果
首先将原始数据大小为260M的txt文件放入hdfs。并配置了Hive环境做数据查询测试。由于原始数据太小，要做GB以上的文件测试。所以并且分别拷贝10、50、100、200、300、400、500份原始数据做成对应的大数据文件。（即：例如复制100份的数据集形成一份大数据，其中有个字段是id，分别为1——100，对应原始数据的100份）
分别对这些数据使用hiveQL查询相同的数据，然后记录不同大小的数据查询的结果。做成一个图表。然后再添加一个slave计算节点，负载均衡后再使用相同的hiveQL语言查询相同的数据集，记录对应的结果。做出下图：
其中，红色是4个计算节点的趋势线，黑色是三个节点。X轴是任务完成时间，Y轴是对应的数据大小，即拷贝原始数据的副本数。图像表明，1、随着数据集的容量增大，mapreduce效率会提高，但是当过了一直值，效率会再次下降。2、4个计算节点时随着数据量的增大mapreduce效率增加的更明显，但是也有一个峰值。3、对应相同大小的数据，4个计算节点的效率要高于3个计算节点的。
当然，这些数据存在着较大的误差，由于条件有限，最后加入的节点与之前三个配置不一样。例如，最后加入的节点硬盘容量比较大，并且本人格式化的hdfs空间也相对大点。这就意味着这个节点会有更多的block，当执行mapreduce时也就会产生更多的mapper。但是CPU和其他硬件没有提高，会拖带本节点的性能，所以这个节点的增加不对应线性的速率增加。但是总会比三节点的要好。
另外，通过分析mapreduce节点工作情况，也验证了task的mapper的数量与性能的关系。
在hadoop中，一个tast作为一个调度时间片。任何时候，只要有空闲的CPU CORE，而且有待调度的Task，那么Task就可以被分配到空闲的CPU CORE上。将一个节点划分为N个Slots，N等于该节点的CPU CORE个数，也就是一个节点最多可以运行与CPU CORE个数相等的Task。
Slots有点像资源池，每个任务必须要获得一个slots才可以运行。Slots可以理解为能并发执行多少个任务。Slots分为mapper slots和 reduce slots，分别对应最大可并行执行的mapper数和reducer数。
Mapper总数不会变，因为查询同样的数据，对应相同数量的spilts。当开始我将mapper slots设置为4时，对应19个task。当mapper slots设置为8时，对应10个task。如图：
19个Task
10个Task
对应19个task。前18个的mapper slots都是满的4个。第十九个就不满。所以mapper slots改为8的时候，需要10个task，第十个还是不满。通过下图也可以看出，虽然task数量少了，但是每个task运行的时间多了，因为对于每个task，所有mapper不可能同时获得CPU资源做到并行计算，需要等待调度，总效率还是没有提高。所以要想提高效率还是要多增加计算节点，降低每个task的最大并行mapper数量（这个数量应该等于CPU核的数量，做到并行调度），从而增加task的数量，使task被均匀分配到每个节点，让所有mapper都并行计算。提高效率。