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

【 关注百度技术沙龙】