近日星环联合思科进行了TPCx-HS 10TB级别的标准测试,经过双方的通力合作,不仅通过了TPC组织官方的审核,并在同级别性能测试中排名第一。该结果反映了TDH系列对于海量数据的超强处理性能,证明其在大数据领域中的领先水平。
该性能排名中我们以12.18的HSph分数击败了MapR 5.0,CDH 5.4.2,MapR M5 4.0.1,位于第一。
本次测试里,我们利用面向大数据与分析的思科UCS 集成基础设施搭建星环一站式大数据综合平台TDH。
下面是测试报告中记录的被测试的大数据平台的各项属性:
其中Hsph是用于反映系统性能的分数,Scale Factor指处理的数据量级,Apache Hadoop Compatible Software是测试对象。
TPCx-HS介绍
TPCx-HS是TPC组织提供的Hadoop性能测试基准(http://www.tpc.org/tpcx-hs/default.asp),用于测试大数据平台硬件、软件和Hadoop文件系统API兼容软件,对它们的性能、性价比、可用性以及耗电性提供客观评估。TPCx-HS本质上是Hadoop的TeraSort benchmark,通过对TB级数据进行排序,来测试HDFS和MapReduce框架对大规模数据的处理性能。
TPCx HS由以下三部分组成:
1. TeraGen:生成大量用于排序的数据并放置在HDFS。此阶段只有Map,没有Reduce。
2. TeraSort:从HDFS上读取TeraGen生成的数据,用MapReduce框架进行排序,并把将结果放在HDFS。既有Map,也有Reduce。
3. Validate:排序结果验证,若任意文件没有按排序键正确排序,就报错。既有Map,也有Reduce。
下面和各位一起回顾下此次TPCx-HS测试中我们采用了哪些优化策略,来保证TDH 4.6在测试过程中的优异性能。
优化前的测试首先,我们在未进采用优化手段的情况下,进行了一轮TPCx-HS性能测试。结果显示,上述三项过程在测试中分别表现出以下特征:
1. TeraGen过程中,Map阶段的CPU负载较低,而网络是性能瓶颈。
2. TeraSort过程中,Map阶段的CPU以及Reduce阶段的网络都处于满负荷。
3. Validate的性能基本稳定,没有需要调优的地方。
所以我们的主要调优对象是TeraGen和TeraSort。
TeraGen的调优思路
TeraGen的性能瓶颈在于写HDFS 3副本时大量的网络吞吐。下图是运行时的网络负载情况:
根据上图,我们认为TeraGen性能调优要遵循下述基本思想:
1. 左边线的斜率要高。意味着Task要尽快启动,尽快完成任务。
2. 上面平台要平。即网络必须稳定且保持满负荷运转状态。
3. 右边线不能有拖尾。即任务量要均衡,单个Task处理的数据不能过多。
要满足这些要求,需要综合平衡各种因素和参数:
1. 通过提高各个服务间节点心跳的频率,加快Task的启动速度。
2. 基于对文件数目、TeraSort时的Map数目、以及TeraGen阶段每个Task的执行时间的考虑,选择合适的Block大小。
TeraSort的调优思路
TeraSort包含Map和Reduce两个阶段,其中Map阶段的CPU负载很高,但网络负载低;Reduce阶段的CPU负载很低,但网络负载很高。如果两个阶段顺序执行,势必有很多等待。
下图是TeraSort过程的CPU使用情况:
这是网络的使用情况:
从上图可见Map阶段基本没有网络负载,但是Reduce阶段网络负载很高,而且中间有明显下降,这说明Map和Reduce的重合度不够,且Reduce的数量较少。
基于对以上现象的观察,TeraSort性能调优的思想如下:
1. 为了减少Map到Reduce阶段的IO(数据量),中间的Shuffle过程需广播压缩后的数据。
2. 因为Map/Reduce阶段各自需要不同的资源,所以可以兼顾系统资源、Map和Reduce Task的数目,尽量让Map和Reduce重合。
3. 即使Map和Reduce重合,Map Task可能仍然占用大部分资源。为了处理更多数据,Reduce Task不能过多。
经过优化后的CPU负载情况如下:
网络负载情况如下:
Map/Reduce数目Map和Reduce数目这两个参数对TeraGen和TeraSort的性能影响都非常大,需要仔细调试。下面以10T为例来说明。
首先要理清文件数、Split数目、Block Size、MapTask数目之间的关系。
由于TeraGen过程不涉及HDFS读操作,所以设定的NUM_MAPS就是实际运行时Map Task的数目,于是最终写到HDFS上的文件个数就是Map Task数目。
如果只有一个文件,那么Split数目就等于filesize / blocksize。例如,假设我们选择采用1G的blocksize,对于数据量为10T的文件,Split的数目为:10,000, 000, 000 / 1,073,741,824 ~= 9314
此时的NUM_MAPS可为9314/3(NUM_MAPS = Split数目/N,N可以根据性能调整),约等于3105。
因为TeraSort是从HDFS上读数据的,所以Map Task数目由总的Split数目决定,和NUM_MAPS无关。Reduce Task的数目由NUM_REDUCERS决定。
硬件环境配置
下面是测试时使用的硬件拓扑结构。
source: http://www.tpc.org/results/fdr/tpcxhs/cisco~tpcxhs~cisco_ucs_integrated_infrastructure_for_big_data~fdr~2017-06-15~v01.pdf
Cisco提供的测试环境节点基本配置如下。
CPU:2路14核 Intel(R) Xeon(R) CPU E5-2680 v4@ 2.40GHz
Mem:256G
网络:2X 10G
磁盘:24 X 1.2T
为了保证以最优的性能通过测试,我们还必须确保CPU、网络、磁盘的状态满足以下要求:
CPU:为了提高性能,CPU必须处于Performance模式,而不是PowerSave。另外还需要检查/proc/cpuinfo中的CPU主频,保证即使CPU空闲,主频也为2.XGHz.
网络:网络必须能够全速运行。可以用网络工具来检测网路速度。
磁盘:必须保证足够多的磁盘,如果磁盘吞吐量不够,磁盘IO将是整个测试过程的瓶颈。
总结
除了对上面内容涉及的参数修改,实际中我们在测试时还对内存、GC等参数进行了调整。正如本文所描述的,Hadoop的调试过程要求开发者对架构底层有一定了解,需要能结合业务场景特征,理解资源图表,对不同数据集不同集群,利用不同相关参数的作用,实现性能优化。
本次的测试结果说明TDH具有优异的大数据分析处理能力以及出色的优化能力,是对TDH开发团队的极大认可。星环将以此为动力,竭力于打造更加优秀的产品。
此外,TDH 5.0作为以此为基础进化后的交付版本,将为用户提供更强大的功能与性能支持。
对此篇文章如有任何问题,欢迎以邮件形式联系我们:bigdataopenlab@transwarp.io