hibench作为一个测试hadoop的基准测试框架,提供了对于hive:(aggregation,scan,join),排序(sort,TeraSort),大数据基本算法(wordcount,pagerank,nutchindex),机器学习算法(kmeans,bayes),集群调度(sleep),吞吐(dfsio),以及新加入5.0版本的流测试:
we provide following streaming workloads for SparkStreaming, Storm .
一个完整的TeraSort测试需要按以下三步执行:
- 用TeraGen生成随机数据
- 对输入数据运行TeraSort
- 用TeraValidate验证排好序的输出数据
所有hibench测试基本都是这样的流程,生成数据,运行,输出结果。
3.2 配置并编译HiBench
从GitHub下载HiBench开源包,本篇会基于HiBench-5.0为例。https://github.com/intel-hadoop/HiBench。如果是基于CDH 5.5测试,建议使用HiBench-5.0,其中包含了Spark 1.5的编译包。
编译
- 添加JAVA_HOME 环境变量
- 注释掉${HIBENCH_HOME} /src/streambench/pom.xml中两行
<!-- <module>stormbench</module> -->
<!-- <module>samzabench</module> -->
- 1
- 2
- 调用编译脚本:${HIBENCH_HOME}/bin/build-all.sh
配置
-
编辑 HiBench Configuration File:
cd ${HIBENCH_HOME}/conf
cp 99-user_defined_properties.conf.template 99-user_defined_properties.conf
编译配置文件,如下修改一些参数:
hibench.hadoop.home /opt/cloudera/parcels/CDH/lib/hadoop
hibench.hadoop.mapreduce.home /opt/cloudera/parcels/CDH/lib/hadoop-mapreduce
hibench.spark.home /opt/cloudera/parcels/CDH/lib/spark
hibench.hdfs.master hdfs://cdh-node-11.cdhtest.com
hibench.hadoop.configure.dir /etc/hadoop/conf
hibench.masters.hostnames master # Resource Manager addresses
hibench.slaves.hostnames hostname…# Node Manager addresses
hibench.spark.master yarn-client
hibench.spark.version spark1.6
spark.kryoserializer.buffer 2000m # 否则会出现大量spark.kryoserializer.buffer.mb被启用的警告
hibench.streamingbench.zookeeper.host zookeeper-hostnames
hibench.streamingbench.brokerList all-hostnames
hibench.streamingbench.kafka.home /opt/cloudera/parcels/KAFKA -
修改benchmarks.lst文件,只运行有必要的测试集,例:
#aggregation
#join
#kmeans
#pagerank
#scan
#sleep
sort
wordcount
#bayes
terasort
#nutchindexing
dfsioe -
修改language.lst文件,只运行有必要的语言
cd ${HIBENCH_HOME}/conf
在language.lst文件中,将以下两行删除
spark/java
spark/python -
修改load-config.py文件,确保Bench在运行时能找到唯一的包:
$HiBench-Home/bin/functions/load-config.py
将hadoop-mapreduce-client-jobclient*-tests.jar改为hadoop-mapreduce-client-jobclient-tests.jar
-
Bench在运行时有一些固化的目录和CDH不一致,需要建立目录引用
建立目录引用
mkdir -p /opt/cloudera/parcels/CDH/lib/hadoop-mapreduce/share/hadoop
cd /opt/cloudera/parcels/CDH/lib/hadoop-mapreduce/share/hadoop
ln -sf /opt/cloudera/parcels/CDH/lib/hadoop-mapreduce mapreduce2 -
Bench会在HDFS根目录下生成文件,将HDFS的根目录权限修改为777:
sudo -u hdfs hadoop fs -chmod 777 /
-
(可选)如果在Kerberos启用的状况下,请增加以下步骤:
# 设置环境变量
export HIBENCH_HOME=/root/Downloads/HiBench-master
export JAVA_HOME=/usr/java/jdk1.7.0_67-cloudera
export JAVA_LIBRARY_PATH=$JAVA_LIBRARY_PATH:/opt/cloudera/parcels/CDH/lib/hadoop/lib/native
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/cloudera/parcels/CDH/lib/hadoop/lib/native
export SPARK_YARN_USER_ENV=”JAVA_LIBRARY_PATH=$JAVA_LIBRARY_PATH,LD_LIBRARY_PATH=$LD_LIBRARY_PATH”# 重新登录Kerberos
kdestroy
kinit -k -t
运行
- 命令行输入
${HIBENCH_HOME}/bin/run-all.sh
3.3 HiBench基本优化配置
**优化基本原则** 在固定数据量的前提下,一般设置成让MapReduce作业在一轮Map、Reduce内结束,否则会增加MapReduce进程的调度开销。但如果输入的数据量过大,有可能会因为单个Map或者Reduce的内存消耗过大而到时严重的GC问题,这个需要在运行时对Map或者Reduce任务进程需要监测。 **YARN基本配置**
– | – |
---|---|
NodeManager | Container vCores数量就是系统的virtual core的数量 Container Memory配置成节点上可用内存的75%到80%之间(如128GB的机器,可以设置96GB) |
ResourceManager | Fair Scheduler调度器 最小容器内存1GB 最小容器CPU 1个核 最大容器内存=NodeManager Container内存的75%~80% 最大容器CPU=NodeManager Container CPU的75%~80% 增量内存512MB 增量CPU 1个核 |
Gateway | mapreduce.map/reduce.max.mb = 2GB mapreduce.map/reduce.java.opts = max.mb * 0.8 |
附录(CDH 相关目录结构功能简介)
**1.相关目录**
/var/log/cloudera-scm-installer : 安装日志目录。
/var/log/* : 相关日志文件(相关服务的及CM的)。
/usr/lib64/cmf/ : Agent程序代码。
/var/lib/cloudera-scm-server-db/data : 内嵌数据库目录。
/usr/bin/postgres : 内嵌数据库程序。
/etc/cloudera-scm-agent/ : agent的配置目录。
/etc/cloudera-scm-server/ : server的配置目录。
/etc/clouder-scm-server/db.properties 默认元数据库用户名密码配置
/opt/cloudera/parcels/ : Hadoop相关服务安装目录。
/opt/cloudera/parcel-repo/ : 下载的服务软件包数据,数据格式为parcels。
/opt/cloudera/parcel-cache/ : 下载的服务软件包缓存数据。
/etc/hadoop/* : 客户端配置文件目录。
**2.配置**
- Hadoop配置文件:
配置文件放置于/var/run/cloudera-scm-agent/process/目录下。如:
/var/run/cloudera-scm-agent/process/193-hdfs-NAMENODE/core-site.xml
这些配置文件是通过Cloudera Manager启动相应服务(如HDFS)时生成的,内容从数据库中获得(即通过界面配置的参数)。
在CM界面上更改配置是不会立即反映到配置文件中,这些信息会存储于数据库中,等下次重启服务时才会生成配置文件。且每次启动时都会产生新的配置文件。
CM Server主要数据库为scm基中放置配置的数据表为configs。里面包含了服务的配置信息,每一次配置的更改会把当前页面的所有配置内容添加到数据库中,以此保存配置修改历史。
scm数据库被配置成只能从localhost访问,如果需要从外部连接此数据库,修改
vim /var/lib/cloudera-scm-server-db/data/pg_hba.conf
文件,之后重启数据库。运行数据库的用户为cloudera-scm。
- 查看配置内容
直接查询scm数据库的configs数据表的内容。
访问REST API: http://hostname:7180/api/v4/cm/deployment,返回JSON格式部署配置信息。
- 配置生成方式
CM为每个服务进程生成独立的配置目录(文件)。所有配置统一在服务端查询数据库生成(因为scm数据库只能在localhost下访问)生成配置文件,再由agent通过网络下载包含配置文件的zip包到本地解压到指定的目录。
-
配置修改
CM对于需要修改的配置预先定义,对于没有预先定义的配置,则通过在高级配置项中使用xml配置片段的方式进行配置。而对于/etc/hadoop/下的配置文件是客户端的配置,可以在CM通过部署客户端生成客户端配置。-
数据库
Cloudera manager主要的数据库为scm,存储Cloudera manager运行所需要的信息:配置,主机,用户等。 -
CM结构
CM分为Server与Agent两部分及数据库(自带更改过的嵌入Postgresql)。它主要做三件事件:
管理监控集群主机。
统一管理配置。
管理维护Hadoop平台系统。
实现采用C/S结构,Agent为客户端负责执行服务端发来的命令,执行方式一般为使用python调用相应的服务shell脚本。Server端为Java REST服务,提供REST API,Web管理端通过REST API调用Server端功能,Web界面使用富客户端技术(Knockout)。
Server端主体使用Java实现。
Agent端主体使用Python, 服务的启动通过调用相应的shell脚本进行启动,如果启动失败会重复4次调用启动脚本。
Agent与Server保持心跳,使用Thrift RPC框架。 -
升级
在CM中可以通过界面向导升级相关服务。升级过程为三步:
1.下载服务软件包。
2.把所下载的服务软件包分发到集群中受管的机器上。
3.安装服务软件包,使用软链接的方式把服务程序目录链接到新安装的软件包目录上。 -
卸载
sudo /usr/share/cmf/uninstall-scm-express.sh, 然后删除/var/lib/cloudera-scm-server-db/目录,不然下次安装可能不成功。 -
开启postgresql远程访问
CM内嵌数据库被配置成只能从localhost访问,如果需要从外部查看数据,数据修改vim /var/lib/cloudera-scm-server-db/data/pg_hba.conf文件,之后重启数据库。运行数据库的用户为cloudera-scm。
-
参考文献
1.CDH官方文档
2.http://www.cloudera.com/documentation.html
3.CDH5.8官方文档 http://www.cloudera.com/documentation/enterprise/latest.html
4.http://blog.selfup.cn/1631.html#comment-403
5.https://github.com/intel-hadoop/HiBench
--------------------- 作者:shiter 来源:CSDN 原文:https://blog.csdn.net/wangyaninglm/article/details/52729682?utm_source=copy 版权声明:本文为博主原创文章,转载请附上博文链接!