一、測試目的
主要是測試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都並行計算。提高效率。