應用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