应用MapReduce制作压测利器(3)

6

configure

传入参数信息给map和reduce task

7

Mapper

定义map task

8

Reducer

定义reduce task

9

Collector

收集map/reduce task的输出数据

10

Reporter

计数器，用于汇报job执行过程一些特定事件的发生次数

　　类似hive这样的应用，拿到用户一句简单sql查询(假设无需二次执行的简单sql)后，将hdfs上的海量数据进行切分，然后每个map task分别对自己负责的那部分数据执行相同的sql查询，最后将各自获得的结果汇总输出给用户，这便可以保证在海量数据中以较快的速度获得查询结果。

　　简单介绍完MR编程框架后，我们再来谈谈常规压力测试的特点和需求。

　　以LoadRunner和JMeter为例，这两种工具都可以对web应用进行大并发访问，模拟线上的高并发压力测试，并且也都相应的提供了多机联合产生负载这样的方式进一步模拟现实情况增大被测对象的压力。这是为了解决“如果一台测试机器模拟的虚拟用户数过多，他本身性能的下降也会直接影响到测试效果”这个问题。分析LR和JMeter的多机联合产生负载这种测试方式，我们不难发现类似MR框架的一些特点，即测试分作如下几步(以LR为例)：

　　1. 设置测试机，即在多台用于测试的机器上安装Load Generator

　　2. 设置测试任务，即各种configure

　　3. 同时调度测试任务，通过agent执行对web应用的访问

　　4. Controller负责统一调度运行场景并收集测试信息和执行结果

　　无论是LR还是JMeter都是优秀的压测工具，但是总有一些非常规的压力测试场景无法通过LR或JMeter方便的实现，例如对分布式系统做数据读写压力测试，被测目标并非一个单独的节点，而是由很多节点组成的，这样的压力测试场景意味着多机联合对单一节点产生的负载被分担到了很多个节点上。LR和JMeter针对这样的场景往往在设置上就很复杂。

　　此外，对很多特定的压测目标，测试人员在设计了专属测试工具之后，往往也需要有一个类似上述LR测试步骤的过程，即工具分发、调度执行、收集结果和过程信息这样一个测试执行框架，如果自己去实现这一套框架，耗费的人月数都是相当可观的，且复用程度有限。于是在云梯项目中我通过自己的实践，想到了将MR编程框架体系与压力测试需求相结合。

原文转自：http://www.taobaotest.com/blogs/2515