HCE Benchmark

1. 項目背景
Hadoop C++ Extension（HCE）由百度開發的Hadoop MapReduce C++擴展框架，其誕生源於baidu/dpf組對Hadoop MapReduce穩定性、擴展性和高效率的追求。HCE將MapReduce任務的執行遷移到C++環境，從而能夠避免java虛擬機因爲GC機制以及JNI調用所產生的沒必要要內存和性能開銷，提供更加精確的內存控制。同時，HCE提供了可與hadoop原生java接口想媲美的API，使得用戶能夠方便的編寫HCE的Map和Reduce任務。
以前，咱們已經對HCE進行了一系列性能測試，數據代表，比起Streaming框架的管道式數據交互處理和純Java MapReduce的Java空間數據處理效率，HCE框架直接基於C++空間的數據處理具有先天優點。框架測試HCE對比純Java框架約有21 – 41%的性能提高，對比streaming框架的性能提高更高。
可是，到目前爲止，咱們的性能測試還不夠完善，並無造成一套完整的測試和評價標準。隨着HCE的不斷完善，HCE也會被更多的線上應用所使用，如何準確的評估系統、線上應用甚至集羣硬件配置的優劣，都會成爲實際的問題。基於以上的考慮，本項目應運而生：爲HCE，或者說Hadoop設計一套完善的benchmark，從而用於實現如下目標（包含但不限於）：
（1） 對比Hadoop 其餘接口和HCE接口的性能，體現HCE的性能優點。
（2） 對HCE的不一樣版本間進行性能基準測試，從而知道HCE的進一步開發和完善。
（3） 指導服務器選型。經過不一樣的硬件搭配，測試Hadoop應用的性能，肯定哪些硬件配置更適合Hadoop集羣。

2. 相關工做
爲了實現一套更加貼切實際的benchmark，咱們進行了一系列調研工做，對目前存在的幾個benchmark，如gridmix以及Intel HiBench作了詳細的研究，同時，做爲hadoop自帶的benchmark gridmix，咱們對其進行了更加深刻的研究，並將其所包含的用例所有遷移至HCE，並進行了性能對比。
Intel HiBench 調研
Intel在Hadoop benchmark作了一些重要工做，提供了一套Benchmark suite – HiBench來對其Hadoop集羣作benchmark，並經過HiTune進行性能數據採集。
HiBench選取的計算模型較爲全面和綜合，既包含Micro Benchmarks，又包含web search，machine learning等應用，以下表所示：

 

這些Benchmark程序表明的計算模型，實現方式和輸入數據以下表所示：

 

這些benchmark程序負載的特色以下表所示：

 

HiBench並無和通常的benchmark同樣，給出一組性能指標，在論文中，HiBench作性能分析時用到了以下指標：
 ※完成時間（在作不一樣版本hadoop性能比較時使用）
 *任務完成總時間
 *各個Task的map，shuffle，sort，reduce 時間 （經過統計JobHistory得到）
 ※CPU使用率
 *System，User，I/O wait
 ※內存
 *Used，Cached，Swapped
 ※Disk I/O 吞吐率
Gridmix調研
Gridmix是hadoop自帶的一個benchmark，這套benchmark實現的比較簡單，僅僅使用hadoop examples包中的GenericMRLoader來產生負載，固然Gridmix使用GenericMRLoader進行不一樣參數以及不一樣迭代層次的組合，產生了幾個具備必定表明性的負載：

 

如下是每一類負載所使用輸入數據的特徵，所用數據使用RandomTextWriter來生成

 

這些benchmark程序負載的都比較簡單，沒有任何複雜計算，準確的說，沒有任何計算。
Gridmix並無和通常的benchmark同樣，給出一組性能指標，也沒有指定任何須要獲得的任何性能數據，它僅僅提供了一組典型用例。
Gridmix的HCE遷移和測試
Gridmix做爲hadoop自帶的一個benchmark，若是用於HCE與java原生接口以及bistreaming接口的性能比較，得到的性能結果更容易獲得社區的認可，所以，咱們將gridmix的全部用例都是用HCE實現了一遍，並對其進行java原生接口與HCE進行了性能評測，測試結果顯示，在大數據量下（gridmix所使用的大數據量是2T），HCE相比java性能提高了接近10%，內存使用也因爲java。
不過，gridmix所使用的用例並不能表明全部的hadoop使用場景，通過咱們分析，gridmix的用例中，並無明顯的CPU-Bound的用例，不存在比較複雜的計算。而現實應用中，不只存在不少I/O密集型的應用，也存在不少的CPU密集型的應用，如聚類算法，倒排索引等等。所以,gridmix並不徹底符合咱們的預期。

3. Benchmark設計
一個完整的benchmark應該由三部分組成：輸入數據集，計算模型以及性能指標。其中最重要的是計算模型，考慮到咱們的benchmark必須集專用和通用於一身的特色，咱們選擇了以下一些用例：

 

其次，根據實際的應用須要，並非每一個用例都會實現java、bistreaming、HCE三個版本，下表中給出了目前計劃的每一個用例的實現版本（打鉤的均爲計劃實現，其中紅色鉤表示還未實現，藍色鉤表示目前有實現，但還須要進一步抽取和完善）：

 

 

4. 進展
在咱們選擇的計算模型中，有一部分已經有現成的實現，稍加改動就可使用，有一部分須要徹底從頭實現，有一部在於公司產品中已經實現，但須要抽取出來，成爲benchmark的一部分，目前已經計劃的主要工做以下：

 

5. Benchmark初步實驗數據
咱們對目前已實現的部分（Java和Hce版的kmeans, terasort, sort, wordcount）的部分進行了屢次實驗，並對實驗結果進行了簡單分析。
實驗環境
Hadoop/HCE版本

集羣信息

實驗內容
在集羣上分別對運行java以及HCE版的kmeans、terasort、sort、wordcount，並對其做業完成時間、做業各階段完成時間、集羣資源使用狀況的進行統計和分析。考慮到做業完成時間有必定偶然性，每一個做業均重複運行三次，統計數據取平均。
數據量

實驗結果

做業完成時間比較

 

 

 

以上數據是全部做業執行時間的比較，從平均時間上來看，除了Sort以外，HCE的執行效率均比原生Java接口要高，特別是Kmeans的兩個做業，性能分別提高了32%和43%，固然，考慮到Kmeans的HCE和Java實現有細微差異（Vector的實現方式有些不一樣，由於找不到mahout的Vector底層實現，所以沒法作到實現細節徹底相同），因此Kmeans的實驗結果並非最具說服力的。Kmeans的HCE實現有待後期改善。
性能提高最不明顯的是Sort，在三次執行中，其中有兩次HCE的執行時間比Java短，但平均時間上來看，HCE比Java慢0.5%。考慮到Sort的三次執行中做業完成時間太不穩定，所以，其實驗結果也不具備太大說服力。
在全部四個用力中，最具說服力的可能應該是Terasort了。HCE的執行時間比Java塊20%左右。且三次執行結果比較也相對穩定。此外，WordCount性能提高也至關顯著（30%）。

做業各階段(平均)時間比較

 

 

 

 

以上表格中給出了做業各個階段的平均完成時間。從表中能夠發現，在執行時間很短的一些步驟中（如各個做業的Sort，以及WordCount的Reduce階段），Java的執行效率比HCE要高，從這個現象能夠看出，HCE在數據量較少的狀況下優點並不明顯，而JNI之類的調用開銷成了決定其執行時間較長的因素。而在數據量比較大時（好比出WordCount以外其餘做業的Reduce階段，以及全部做業的Map和Shuffle階段）HCE的優點就逐漸展示出來了。
這裏咱們還要特別關注Sort用力，在上一節的做業執行時間比較中，咱們發現Sort的Java和HCE版本並無什麼差距，但當咱們關注各階段時間時會發現，HCE的四個階段均比Java快。

集羣資源使用狀況
如下集羣資源使用圖，只採集了benchmark某一次運行的數據，「HCE做業執行期間」表示Benchmark中四個用例的Hce版本所有運行的時間段，一樣，「Java做業執行期間」表示全部四個做業的Java版本執行的時間段。

以上兩個曲線圖分別展現了Java和Hce版本的用例在執行期間集羣CPU的使用狀況。相比之下，Java版用例執行期間花費了更多的CPU（Java 77.06% vs HCE 70.86%）。此外，考慮到Java版用例執行時間比HCE的執行時間還要長，更加可以體現出HCE可以更加有效的利用CPU資源這一特性。

 

 

以上兩個曲線圖分別展現了Java和Hce版本的用例在執行期間集羣內存的使用狀況。從中能夠看出，HCE所使用的內存量比Java略大（Java 2.21G vs HCE 2.62G）。這能夠看出，雖然HCE的C++環境下，手動內存管理相比Java的GC機制能夠節省一些因爲內存回收不及時帶來的內存開銷，但HCE環境畢竟比Java環境多開了一些進程。這些方面致使了HCE會比Java多一些內存開銷。固然，這僅僅是一次做業執行的資源使用狀況，不能太說明問題。

 

網絡設備使用率方面，考慮到Java和HCE都是使用HDFS，且做業調度機制是同樣的，因此網絡數據流量應該相差不大，但綜合考慮時間和平均網絡使用率，Java版的網絡流量相比更多一些，經過分析做業日誌發現，Java版的Sort程序執行期間出現了比較嚴重的異常，致使部分做業從新執行的次數比較多，因此流量也更多一些。

 

(做者：xuyinfei)

 

【 本文首發於： 百度測試技術空間】 http://hi.baidu.com/baiduqa/blog/item/6419902b8b4c5ded99250ab2.html

【 關注百度技術沙龍】