Hadoop集群測試報告

1、測試報告集群設置1. 服務器配置CPU24內存128G帶寬1024M磁盤44T磁盤吞吐預計100M/S2. Hadoop服務部署HADOOP-12-151NameNode Balancer、Hive Gateway、Spark Gateway> ResourceManager、Zk ServerHADOOP-12-152DataNode、SNN HFS Hive Gateway、WebHCat Hue> Impala Deamon CMServerMonitor、CM Activity Monitor 、CM Host Monitor、CM Event Server、CM Aler

2、tPublisher、Oozie Server、Spark History Server、Spark Gateway> NodeManagenJobHistory Server 、Zk ServerHADOOP-12-153DataNode、Hive Gateway、HiveMetastore、HiveServer2、Impala Catalog、ImpalaStateStore 、Impala Deamon、Spark Gateway > NodeManagen Zk ServerHADOOP-12-154DataNode、Hive Gateway、Impala Deamon S

3、park Gateway、NodeManagec Sqoop2HADOOP-12-155DataNode、Hive Gateway、Impala Deamon Spark Gateway、NodeManager、Zk ServerHADOOP-12-156DataNode、Hive Gateway、Impala Deamon Spark Gateway、NodeManager、Zk Server3. hadoop參數設置yarn-mb108544-allocation-mb4096-allocation-mb32768-allocation-mb4096-vcores24-pmem-ratio

4、mapreduce40968192307261441536100151555dfs3534096二、基準測試1. HDFSW寫的吞吐性能連續(xù)10次執(zhí)行如下寫操作，其性能見圖示：cd /opt/clouderahdfsadmin hadoopTestDFSIO -write -nrFiles 10 -fileSize 1000 -resFile /tmp/其具體數據見表格：123456789 10均值HDFS寫文件吞吐均值：/ S平均執(zhí)行時間：占用帶寬：/ S結論：HDFSf,其磁盤吞吐基本上處于理想狀態(tài)，且在此吞吐水平上其網絡帶寬占用較少，沒有造成明顯的帶寬負載。連續(xù)10次執(zhí)行如下讀操作，其性

5、能見圖示：hdfsadmin hadoopTestDFSIO -read -nrFiles 10 -fileSize 1000 -resFile /tmp/Map Task平均吞吐：S 。文件的平均IO速度：S,基本符合理想狀態(tài)。附：I.帶寬計算過程：10000/=6, 10個文件則10個進程并發(fā)，復本數為 2,則有1份網絡彳輸，10個進程并發(fā)在5臺機器上，基本上每臺機器有2個寫進程，則網絡流量大約為：S* 1*2=,遠遠低于千兆網絡的帶寬。II.清除測試數據：dfsadmin hadoopTestDFSIO - clean208192寫性能：基本上與之前相當。讀性能：Map Task平均吞吐

6、：S 。文件的平均IO速度：So2. mrbench基準測試重復執(zhí)行小作業(yè)50次，檢查平均執(zhí)行時間hdfsadmin hadoopmrbench -numRuns 50基本情況，上述操作完全來自默認值：inputlines : 1mapper： 2reducer : 1完成時間：17986ms,即17秒。修改上述各參數的設置，inputlines : 100000mapper： 1000reducer : 200 hdfsadmin hadoopmrbench -numRuns 10 -inputLines 100000 -maps 1000 -reduces 200 完成時間：190131m

7、s,即190秒。在此參數設置下，集群負載很重，mapper&reducer總數明顯超過了集群一般可以承受的水平繼續(xù)調整參數設置，inputlines : 100000mapper： 100reducer : 5 hdfsadmin hadoopmrbench -numRuns 10 -inputLines 100000 -maps 100 -reduces 5完成時間：28682ms,即28秒。在此參數設置下，基本上符合集群負載的一般水平，mapper&reducer數設置較為合理，完成時間比較理想，即數據量越大，Hadoop越能夠體現其優(yōu)勢。208192hdfsadmin h

8、adoopmrbench -numRuns 5015996ms,16shdfsadmin hadoopmrbench -numRuns 10 -inputLines 100000 -maps 100 -reduces 528975ms,29s3. 利用全局排序Terasort測試MapReduce行性能cd /opt/cloudera生成10G數據：hdfsadmin hadoop jar teragen -=100 /home/songuanglei/gen10G排序：hdfsadmin hadoop jar terasort -=100/60/10/5 /home/songuanglei/

9、gen10G /home/songuanglei/output10Gmap數目為2,不斷調整reducer數目為100、60、10、5,其執(zhí)行時間趨勢如下圖：結論：reducer數越接近集群節(jié)點數目，其執(zhí)行速度越快。生成100G數據：hdfsadmin hadoop jar teragen -=100 /home/songuanglei/gen100G排序：hdfsadmin hadoop jar terasort -=100/6010/5 /home/songuanglei/gen100G /home/songuanglei/output100Gmap數目為800,不斷調整reducer數目

10、為100、60、10、5,其執(zhí)行時間趨勢如下圖：結論：隨著處理數據的增大，map階段耗時顯著增加，成為整個 Job執(zhí)行的重點，reducer數越接近集群節(jié)點數目，其執(zhí)行速度越快。附：I.驗證是否有序hdfsadmin hadoop jar teravalidate /home/songuanglei/output100G /home/songuanglei/validate100G4. 利用wordcount測試MR執(zhí)行性能wordcount是CPU資源消耗型的 操作如下：hdfsadmin hadoop jar wordcount -=10 /user/songguanglei/ /user/songguanglei/output基本情況：輸入文件：622MB默認 mapper數：5分別設置 reducer 數據為 60、10、5,分別得出 CPU time spent (ms)值：218340、130900