hadoop生态性能测试

本文基于intel的开源框架HiBench来分析hadoop集群性能测试的思路以及案例

介绍

Hadoop集群的性能测试是一个很复杂并且耗时的过程,正常情况是边测试,边调整配置,然后再测试。而测试的目的大致可以分为两部分,计算能力以及存储能力。计算能力可以简单的理解为单位时间下某个算法的速度,比如排序,求和这些常见操作。而存储能力一般指的是hdfs,通常namenode会是最先到达瓶颈的组件,常见的测试namde最大可以支持多少小文件这类性能测试。
HiBench是针对hadoop生态诞生的性能测试框架,包括了多种性能测试项,除了hadoop自带的Sort,TeraSort,TestDFSIO等重要性能测试方法,还提供了针对Spark,Hive以及流计算的flink,storm等相关的性能测试。比如Spark的TeraSort,Spark sql的join等。此外关于机器学习,也提供了一系列性能策略入口,包括Kmeans,贝叶斯等常见算法。HiBench将结构分为workload/engine/script,workload就是测试项,其中对应不同的workload都会搭配一个prepare脚本来做一些准备工作,比如数据模拟,并且可以通过配置选择模拟的数据量,配置在conf路径下,hibench.conf是全局配置。

安装使用

HiBench安装比较简单,是基于maven的编译方式,但是比较慢,毕竟集成了很多大数据组件,需要下载依赖。完整的教程参考HiBench安装,需要注意的是,在编译的时候可以选择某个组件,防止编译了很多用不到的模块。
比如只需要hadoop和spark两个组件

1
mvn -Phadoopbench -Psparkbench -Dspark=2.1 -Dscala=2.11 clean package

安装完后,执行一个spark的bench验证一下,完成文档参考HiBench的run spark,下面是本人验证古的命令

1
2
3
4
5
6
7
8
9
10
11
cd $HiBench_HOME
cp conf/hadoop.conf.template conf/hadoop.conf
// 这里需要修改hadoop的配置,hadoop home和hdfs的头是必须要改的

cp conf/spark.conf.template conf/spark.conf
// 这里需要修改spark的配置,spark home是必须要修改的,其他视情况而定

// prepare是通过MR任务生成数据文件
bin/workloads/micro/wordcount/prepare/prepare.sh
// 启动spark任务来读取生成的数据文件,完成wordcount
bin/workloads/micro/wordcount/spark/run.sh

执行完后,可以在$HiBench_HOME/report目录下看到执行报告和执行日志,hibench.report是spark的wordcount的执行报告
样例

详细解释一下TeraSort

因为这个名字的特殊性,可能会出现疑惑,TeraSort不是一种排序算法,而是一种排序规范,将待排序的数据长度,数据的值都做了标准化,这样才能使结果更有说服力。其他和普通排序没啥区别,思路类似快排,先将所有数据分成区,使得区与区之间有序,再对区内的数据进行排序,这样最终得到的就是全局有序的数据。对应到hadoop里,有3个可执行的MR任务,分别是生成数据,数据排序,校验数据,下面针对数据排序的代码进行深入分析。数据排序的核心类有3个,TeraSort,TeraInputFormat,TeraSchedulerTeraSort是入口类,也就是提交MR任务的地方,除此之外,还包括对Partitioner的定义TotalOrderPartitioner,MR自带的Partitioner是基于hash的,这就导致了数据在shuffle的时候是无序的,输出的文件与文件之间无法确保顺序,这就不符合TeraSort的要求。那么如何让shuffle输出的文件有序呢,由于在map阶段,单个map无法获取全局的数据分布情况,所以只能借助外力,在提交MR任务之前,对待排序的数据抽样,这里hadoop采用了对split进行随机抽样,取split的前N个样本,样本数可以配置,然后将样本写入hdfs,在map的task启动后,初始化加载这个采样文件,这样就能让每个map感知到数据大概的分布情况,然后再对样本数据排序预分区,从而可以通过实际数据对比已分区的上下限来确定实际的分区号。TeraInputFormat包括了如何读取采样数据,字典树预分区以及读取实际数据的功能。TeraScheduler是一个优化项,用于控制不同的FileSplit的host选择,避免在一个机器上读取多个split的场景,也就是对IO做负责均衡。

hadoop自带性能测试案例

Hdfs的写入性能

写10个文件,每个文件1GB,这样会创建一个有10个map的mr任务,每个map分配1C4GB资源,执行结束后,会打印出如下信息,也可以在本地磁盘中的/tmp/writeres.txt找到相同信息,压测的中间结果文件在hdfs的路径conf.get(“test.build.data”,”/benchmarks/TestDFSIO”)

1
yarn jar /usr/hdp/2.6.3.0-235/hadoop-mapreduce/hadoop-mapreduce-client-jobclient-tests.jar TestDFSIO -write -nrFiles 10 -size 1GB -resFile /tmp/writeres.txt

输出样例

Total MBytes processed:总共需要写入的数据量,也就是总文件数*单个文件的大小,单位MB
Throughput mb/sec:总共需要写入的数据量/每个map任务实际写入数据的执行时间之和,这个值可以看做是hdfs的美妙写入性能
Average IO rate mb/sec:(每个map需要写入的数据量/每个map任务实际写入数据的执行时间)之和/任务数。Throughput mb/se和这个值的区别在于,前者更能反应总体的吞吐量,后者更照顾每个map的状况,并可以通过IO rate std deviation来反映出不同map之间的写入性能的波动
IO rate std deviation:Average IO rate mb/sec的标准差
Test exec time sec:整个job的执行时间

Hdfs读文件性能

和写文件流程一样

1
yarn jar /usr/hdp/2.6.3.0-235/hadoop-mapreduce/hadoop-mapreduce-client-jobclient-tests.jar TestDFSIO -read-nrFiles 10 -size 1GB -resFile /tmp/readres.txt

输出样例

Namenode性能测试

目前支持4种多hdfs操作的性能测试,包括create_write open_read rename delete。先看create_write,通过使用hdfs client创建文件,并写少量数据来模拟小文件场景,观察namenode情况

1
yarn jar /usr/hdp/2.6.3.0-235/hadoop-mapreduce/hadoop-mapreduce-client-jobclient-tests.jar nnbench -maps 10 -numberOfFiles 10 -operation create_write

输出样例

MR的TeraSort

  1. 生成用于TeraSort排序的数据
    下面生成100行用于测试

    1
    yarn jar /usr/hdp/2.6.3.0-235/hadoop-mapreduce/hadoop-mapreduce-examples.jar teragen 100 /tmp/Teradata
  2. 排序

    1
    yarn jar /usr/hdp/2.6.3.0-235/hadoop-mapreduce/hadoop-mapreduce-examples.jar terasort /tmp/teradata /tmp/res24.txt

参考

HiBeanch的github
TestDFSIO,NNBench位于MapReduce工程下的jobClient模块test包
TeraSort位于MapReduce工程example模块

ulysses wechat
订阅+