system: [SYSTEM]

user: 4. 实验结果及性能分析 4.1. 实验目的 本文实验目的主要有两个： 1) 通过实验验证按照本文提出的方案实现的系统是否运行正常； 2) 修改集群节点数目，运行同一个功能，比较不同数据量的处理时间，对集群平台的性能做出总结。 为验证本文提出的平台构建方案的可行性，搭建了7台节点的Hadoop集群。实验时1台主机作为master，参与运算的slave数量可根据实验需求灵活调整。所有主机的硬件配置完全相同，排除无关因素对实验的影响，保证实验严谨性。试验环境如下： 主机配置：CPU为Intel Core 2 Duo CPU E7300 @ 2.66GHz×2，内存1.9 GB，155，3 GB硬盘。 操作系统：采用Ubuntu 14.04.3 LTS(64Bit)，客户机为桌面版，集群中的主机为服务器版。 软件及相应版本：Java环境为jdk1.8+，Hadoop 2.7.1。 因为实验主要验证方案可行性，实验采用了相对简单的算法和数据。 采用算法为WordCount，被称为单词计数或词频统计，是Hadoop编程中最基本也最常见的算法。算法包含Map和Reduce两个阶段。Map被称为“映射”，按行读取数据，根据空格将数据拆分为处理单元(单词)，再保存成数据对“处理单元，1”的形式，供后续处理使用；Reduce被称为“规约”，处理单元相同的数据对被分配给同一个Reduce，对其附带的数值进行累加，就得到了处理单元在整个数据集中出现的频数。 选择英文Bible语料库作为测试数据。该语料库文件大小仅为4.4 MB，不能发挥集群运算的速度优势，故对其进行了重复复制。为验证集群数量对集群调度和通信时间的影响，特设置一个数据量极小的特殊数据，仅包含一个文本，文本中只有一个单词。可以预见，处理该数据时，文件传输和处理时间极短，程序的总运行时间大体可以作为集群调度时间的基准。最终确定了5组测试数据，除极小数据外，其余4组的大小分别为512 MB、1024 MB、2048 MB、4096 MB。集群规模有4种，参与运算的slave节点数量分别为：1、2、4、6。 为解决单一实验的偶然因素对实验结果造成影响，使用控制变量和均值思想，本试验采用6种不同节点数量的集群，分别测试5组数据执行同一算法。每次处理时，分别统计系统准备时间、数据上传时间、MapReduce处理时间和结果下载时间。 4.2. 实时性分析 为验证集群响应任务请求的实时性，统计了从提交任务到开始向集群上传数据的时间，作为集群的响应时间。在4个规模不同的集群下处理5组数据，每组实验重复3次取平均值。在不同集群规模和不同数据量情况下，集群响应时间如表1所示。 由表1得，8组实验的平均响应时间均在58 ms到144 ms之间。集群的响应时间随数据量增大和集群规模减小有增加的趋势，超过100 ms的几个结果集中出现在集群规模较小且数据量较大的情况下。 4.3. 数据传输时间分析 为验证客户机与不同规模的集群间传递数据速度的差异，选取5组数据，对4个集群分别进行数据上传和下载操作，记录传输时间。每组实验同样进行3次，结果取平均值。在不同集群规模和不同数据量情况下，数据传输时间如表2所示。 由表2得，极小数据量相应的上传和下载时间都远小于其他几组数据，因为上传和下载的文件都极小。 Table 1 Cluster response time (ms 数据量(MB) 1 2 4 6 均值 极小 58 69 65 67 65 512 84 76 61 87 77 1024 108 86 82 97 93 2048 144 107 64 69 96 4096 127 100 74 114 104 表1. 集群响应时间(ms) Table 2 Data transfer time (ms 数据量(MB) 传输类型 1 2 4 6 平均值 极小 上传 69 79 83 88 80 下载 20 15 14 13 16 512 上传 63，333 57，276 60，050 57，141 59，450 下载 105 96 100 101 101 1024 上传 133，939 160，328 179，701 199，982 168，488 下载 179 116 106 81 121 2048 上传 226，321 275，834 319，555 333，674 288，846 下载 178 191 157 99 156 4096 上传 441，329 517，547 571，201 573，108 525，796 下载 97 81 128 181 122 表2. 数据传输时间(ms) 其余4组数据相应的上传时间都较长，基本与数据量大小呈正相关。下载时间相差不大，因为处理结果的文件大小基本相同。实验中运行的是WordCount程序，且被处理的各组数据是由同一文件复制得来，可以推断输出文件行数相同，区别仅在于处理结果中每个单词的数量不同，所以文件大小相差不大。所以得出结论，文件传输时间基本与要传输的文件大小呈正相关关系。 针对同一组数据，文件传输时间随集群规模扩大有增加的趋势。因为数据按块的形式在客户机和集群各个节点间进行传输，传输时间长短取决于最后完成传输的节点。在不能排除各节点主机性能有差异的情况下，集群规模扩大导致总的传输时间延长。 4.4. 性能分析 比较不同大小的数据在不同集群规模情况下的处理时间。实验选取了5组数据，在4个集群中分别进行3次处理，处理时间取平均值。不同集群规模下的数据处理时间如表3所示。 由表3得，随处理的数据量增大，处理时间相对增长。随集群规模增加，处理时间相对缩短。以slave数为1的处理时间作标准，计算集群加速比，如图3所示。 由图3所示，当处理的数据量较小时，集群不能对运算产生加速效果。因为集群节点间通讯开销等负面因素，集群处理用时甚至比单机处理用时更长。当处理数据的大小为512 MB及以上时，集群运算加速比随集群规模增加有明显提升。在本实验中，当集群slave数为6，数据量为2048 MB时，计算加速比达到最大值。 6节点的理论最高加速比为6，实验中最大加速比与之相比仍有较大差距。分析原因：一是实验所用机器比较老旧，单机性能有限；二是运算中reduce数太少。实验中对map数和reduce数采用默认设定。通过查看运行日志，发现执行时系统自动为每个数据块分配了1个map，但每次任务都只有1个reduce，形成了处理瓶颈。为验证reduce数对处理速度的影响，设置如下实验：使用6节点集群处理1024 MB数据，分别设置reduce数为分别为slave数的1、2、3倍，另设1组对照。不同reduce数集群处理时间如表4所示。 实验结果与reduce数和slave数都为1的集群，对1024 MB数据的处理时间对比，得到的加速比如图4所示。 由图4得，随集群reduce数增加，集群运算加速比又有提高。当reduce数为slave数的2倍时，加速比达到最大值。可见reduce数的设定确实影响集群处理效率。在本实验中，reduce数设为slave数2倍时，集群加速效果最好。 Table 3 Data processing time (ms 数据量(MB) 1 2 4 6 极小 25，388 26，690 26，775 25，486 512 2，135，665 1，497，060 1，175，610 732，215 1024 4，288，210 3，247，376 2，140，819 1，556，942 2048 9，410，533 6，530，532 3，865，268 2，963，231 4096 18，787，454 11，406，213 8，040，599 5，943，141 表3. 数据处理时间(ms) Table 4 Data processing time (ms reduce数 1 6 12 18 处理时间 1，556，942 1，356，639 1，166，978 1，422，078 加速比 2.754 3.161 3.675 3.015 表4. 数据处理时间(ms) 图3. 不同规模集群加速比 图4. 不同reduce数集群加速比