7.1.4

其他Benchmark

在⼤数据领域还有⼀些针对特定负载的⼤数据Benchmark，读者感兴趣可以深⼊研究。

下⾯介绍⼏个典型的Benchmark。

1）Malstone：针对数据密集型计算和分析的⼯作负载的Benchmark⼯具。

它基于⼤规模并⾏计算，也具有云计算的属性。

2）Cloud

Harmony：使⽤⿊盒⽅式度量云服务提供商的性能。

它基于⼤规模并⾏计算，并且⾯向硬件架构，评测复杂数据的⼤数据运算。

3）YCSB：度量和对⽐云数据库的框架。

基于⼤规模并⾏计算，⾯向⼤数据和云计算。

4）SWIM：⼀个针对MapReduce的统计⼯作负载。

基于MapReduce⾯向⼤数据的复杂数据集的分析测试。

5）LinkBench：针对图数据库的Bechmark，在Facebook数据库⼯程团队，通过分析Facebook的数据库⼯作负载（workload）并开发了这款称为LinkBench的数据库性能测试⼯具。

LinkBench已经开源并发布到了Github。

6）DFSIO：是⼀个分布式⽂件系统的Benchmark，针对Hadoop测试HDFS的读写性能。

7）Hive

performance

Benchmark（Pavlo）：这是由Palvo最早提出的测试⼯具。

这个Hive性能测试⼯具⽤于⽐较Hadoop和并⾏分析型数据库。

它拥有5个⼯作负载，第⼀个是Grep（源于MapReduce的论⽂），其他4个典型的查询设计为代表传统的结构化分析⼯作负载，包括选择、聚集、连接、⽤户⾃定义函数的⼯作负载。

Berkeley

Big

Bench就是借鉴Pavlo的Benchmark思想⽽进⼀步开发和实现的。

7.2

Benchmark的组成

Benchmark的核⼼由3部分组成：数据集、⼯作负载、度量指标。

理解了这3个部分，就可以宏观了解Benchmark。

下⾯从以下⼏点介绍Benchmark。

7.2.1

数据集

数据类型分为结构化数据、半结构化数据和⾮结构化数据。

由于⼤数据环境下的数据类型复杂，负载多样，所以⼤数据Benchmark需要⽣成3种类型的数据和对应负载。

1）结构化数据：传统的关系数据模型、⾏数据，存储于数据库，可⽤⼆维表结构表⽰。

典型场景为互联⽹电商交易数据、企业ERP系统、财务系统、医疗HIS数据库、政务信息化系统、其他核⼼数据库等。

结构规整，处理⽅案较为成熟。

使⽤关系数据库进⾏存储和处理。

2）半结构化数据：类似XML、HTML之类，⾃描述，数据结构和内容混杂在⼀起。

典型应⽤场景为邮件系统、Web搜索引擎存储、教学资源库、档案系统，等等。

可以考虑使⽤Hbase等典型的Key-Value存储系统存储。

在互联⽹公司中存在⼤量的半结构化数据。

3）⾮结构化数据：各种⽂档、图⽚、视频/⾳频等。

典型应⽤场景为视频⽹站、图⽚相册、医疗影像系统、教育视频点播、交通视频监控、⽂件服务器（PDM/FTP）等具体应⽤。

可以考虑使⽤HDFS等⽂件系统存储。

在互联⽹公司同样存在⼤规模的⾮结构化数据。

7.2.2

⼯作负载

1.⼯作负载的维度

对⼯作负载的理解和设计可以分为以下⼏个维度。

（1）密集型计算类型

①CPU密集型计算。

②I/O密集型计算。

③⽹络密集型计算。

（2）计算范式

①SQL。

②批处理。

③流计算。

④图计算。

⑤机器学习。

（3）计算延迟

①在线计算。

②离线计算。

③实时计算。

（4）应⽤领域

①搜索引擎。

②社交⽹络。

③电⼦商务。

④地理位置服务。

⑤媒体，游戏。

由于互联⽹领域数据庞⼤，⽤户量⼤，成为⼤数据问题产⽣的天然⼟壤。

⼤数据Benchmark的很多⼯作负载都是根据互联⽹领域的典型应⽤场景产⽣的。

从图7-5中可以看到，BAT三巨头分别规划了⾃⼰的互联⽹布局，涉及电⼦商务、媒体游戏、社交媒体、搜索门户以及基于地理位置服务等多个领域。

每个巨头旗下都有数家⼩公司与其有着紧密的联系，正是互联⽹应⽤中产⽣了⼤量的典型⼤数据⼯作负载。

由于Spark兴起的时间较Hadoop晚很多，其相应的Benchmark也不如Hadoop可⽤的多。

但是我们也看到，Spark兼容和利⽤Hadoop存储的数据，这就使⽤户可以利⽤以往Hadoop的Benchmark的数据⽣成器⽣成数据，使⽤Hadoop存储数据，然后根据特定的负载重写Spark的⼯作负载。

因为Spark的编程表现⼒要远远超过Hadoop，所以Hadoop的⼯作负载完全能⽤Spark重写，⽽且Benchmark的负载⽬的只是突出在特定的计算密集型计算下暴露系统性能瓶颈，⼀般逻辑简单，所以改写⼯作量并不⼤。

/>下⾯从计算范式⾓度介绍典型的⼤数据⼯作负载。

（1）基本负载

/>1）Word

/>WordCount是CPU密集型的操作负载，WordCount已经在前⾯有所

/>排序算法的实现如下。

object
Sort
"Spark：//127.0.0.1：7077"
var
SparkContext（host，
SPARK_HOME，
List（JARS））
val
spark.textFile（filename，
splits）
/*这⾥进⾏映射是为了使⽤sortByKey的算⼦，因为sortByKey只能处理key-value
pair类型
mapData.sortByKey（）.map{line
=>
result.saveAsTextFile（save_file）
Sort
在运⾏的过程中，map映射和Shuffle阶段是CPU密集型的（CPU
intensive），I/O程度中等，在reduce阶段是I/O密集型的（I/Ointensive），CPU计算中等。
算法实现思想：当把传统的串⾏排序算法设计成并⾏的排序算法时，通常会想到分⽽治之的策略。
排序并⾏化的⼀般做法是：把要排序的数据划成M个数据块（可以⽤Hash的⽅法做到），然后每个map
task对⼀个数据块进⾏局部排序，之后，⼀个reduce
task对所有数据进⾏全排序。
这种设计思路可以保证在map阶段并⾏度很⾼，但在reduce阶段完全没有并⾏。
为了提⾼reduce阶段的并⾏度，TeraSort作业对以上算法进⾏改进：在map阶段，每个map
task都会将数据划分成R个数据块（R为reduce
task个数），其中第i（i>0）个数据块的所有数据都会⽐第i+1个数据块中的数据⼤；在reduce阶段，第i个reduce
task处理（进⾏排序）所有map
task产⽣的结果均会⽐第i+1个⼤，最后将1~R个reduce
task的排序结果顺序输出，即为最终的排序结果。
（2）机器学习
下⾯以K-Means聚类算法为例介绍机器学习计算范式
在计算中⼼点时，K-Means是CPU密集型的计算。
在聚类时，KMeans进⾏I/O密集型运算。
K-Means算法是最为经典的基于划分的聚类⽅法，是⼗⼤经典数据挖掘算法之⼀。
K-Means算法的基本思想是：以空间中k个点为中⼼
进⾏聚类，对最靠近它们的对象归类。
通过迭代的⽅法，逐次更新各聚类中⼼点的值，直⾄得到最好的聚类结果。
假设要把样本集分为c个类别，算法描述如下。
1）适当选择k个类的初始中⼼。
2）在第n次迭代中，对于任意⼀个样本，求其到k各中⼼的距离，将该样本归到距离最短的中⼼所在的类。
3）利⽤均值等⽅法更新该类的中⼼值。
4）对于所有的k个聚类中⼼，如果利⽤2）、3）的迭代法更新后，值保持不变。
或者达到指定的迭代次数，则迭代结束，否则继续迭代。
该算法的最⼤优势在于简洁和快速。
算法的关键在于初始中⼼的选择和距离公式。
（3）图计算
下⾯以PageRank图计算算法为例介绍图计算的计算范式。
PageRank⼴泛⽤于搜索引擎，对⽹⻚图谱进⾏分析。
1）算法介绍。
PageRank⽤于衡量特定⽹⻚相对于搜索引擎索引中其他⽹⻚⽽⾔的重要程度，是Google的专有算法。
20世纪90年代后期由Larry
Page和Sergey
Brin开发。
PageRank将链接价值概念作为排名因素。
2）算法思想。
⼀个⻚⾯的PageRank由所有链向它的⻚⾯（链⼊⻚⾯）的重要性经过递归算法得到。
⼀个⻚⾯的权重由所有链向它的⻚⾯的重要性决定，到⼀个⻚⾯的超链接相当于为该⻚投⼀票。
⼀个有较多链⼊的⻚⾯会有较⾼的权重，反之，⼀个⻚⾯链⼊⻚⾯越少，权重越低。
简⽽⾔之，从许多的权重⾼⽹⻚链接过来的⽹⻚，必定还是权重⾼的⽹⻚。
PageRank计算基于以下两个基本假设。
·质量假设：指向⻚⾯A的⼊链质量不同，质量⾼的⻚⾯会通过链接向其他⻚⾯传递更多的权重。
因此，质量越⾼的⻚⾯指向⻚⾯A，则⻚⾯A也越重要。
·数量假设：若⼀个⻚⾯节点接收到的其他⽹⻚指向的⼊链数量越多，则该⻚⾯越重要。
3）算法原理。
初始阶段：⽹⻚通过链接关系构建有向图，每个⻚⾯设置相同的PageRank值，通过若⼲轮的迭代计算，得到每个⻚⾯最终获得的PageRank值。
在每轮迭代中，⽹⻚当前的PageRank值不断更新。
迭代：在更新⻚⾯PageRank得分的每轮计算中，各⻚⾯将其当前的PageRank值平均分配到本⻚⾯包含的出链上，每个链接即获得了相应的权值。
⽽每个⻚⾯将所有指向本⻚⾯的⼊链所传⼊的权值进⾏求和，即可得到新的PageRank得分。
且每个⻚⾯都获得了更新后的PageRank值时，⼀轮PageRank计算完成。
（4）计算公式
/>
d：阻尼系数，任意时刻，⽤户到达某⻚⾯后并继续向后浏览的概率。
（1-d=0.15）：表⽰⽤户停⽌点击，随机跳到新URL的概率。
取值范围：0＜d≤1，Google设为0.85。
通过链接关系，就构造出了“转移矩阵”。
（5）SQL
结构化查询语⾔（structured
query
language，SQL）是⼀种数据库查询和程序设计语⾔，⽤于存取数据以及查询、更新和管理关系数据库系统。
SQL可以⼤致分为以下⼏个类型：席查询（Ad-hoc
query）、报表查询（Reporting
query）、迭代查询（Iterative
query）等，感兴趣的⽤户可以查看TPC-DS的介绍进⾏了解。
7.2.3
度量指标
性能调优的两⼤利器就是Benchmark和Profile⼯具，读者可以结合Spark性能调优章节，通过Benchmark和Profile⼯具，及相应的调优⽅法对Spark性能调优。
Benchmark⽤压⼒测试挖掘整个系统的性能状况，⽽Profile⼯具最⼤限度地呈现系统的运⾏时状态和性能指标，⽅便⽤户诊断性能问题和进⾏调优。
⽤户在实战中可以采⽤⼀些原⽣的Profile⼯具，通过以下⼏个⽅⾯对系统性能指标进⾏度量。
1.⼯具使⽤
1）在架构层⾯：perf、nmon等⼯具和命令。
2）在JVM层⾯：btrace、Jconsole、JVisualVM、JMap，JStack等⼯具和命令。
3）在Spark层⾯：web
ui、console
log，也可以通过修改Spark源码打印⽇志进⾏性能监控。
2.度量指标
（1）从架构⾓度进⾏度量
·浮点型操作密度。
miss、L2
/>（2）从Spark系统执⾏时间和吞吐的⾓度度量
/>（3）从Spark系统资源利⽤率的⾓度度量
/>（4）从扩展性的⾓度度量
Benchmark的使⽤
下⾯介绍3个典型的Benchmark的使⽤，即Hibench、BigDataBench和TPC-DS。
7.3.1
使⽤Hibench
下⾯介绍Hibench[1]的使⽤⽅法。
1.前期准备
（1）设置HiBench-2.2
下载或者签出HiBench-2.2
benchmark
suite，官⽅⽹址为https://github.com/intel-hadoop/HiBench/zipball/HiBench-2.2。
（2）设置Hadoop
在运⾏其他⼯作负载之前，请确认已经正确安装了Hadoop，所有的⼯作负载已经在Cloudera
Distribution
1.0.3版本的Hadoop上测试通过。
（3）设置Hive[2]
如果需要测试hivebench，则确认实验环境已经安装了Hive，或者使⽤benchmark中已经打包的Hive
0.9。
（4）针对所有的⼯作负载配置参数
需要在使⽤前在bin/hibench-config.sh中配置⼀些全局变量。
·HADOOP_HOME：Hadoop的安装路径。
·HADOOP_CONF_DIR：Hadoop的配置⽂件⽬录，默认为$HADOOP_HOME/conf⽬录下。
·COMPRESS_GLOBAL：设置是否压缩输⼊输出数据，0表⽰不压缩，1表⽰压缩。
·COMPRESS_CODEC_GLOBAL：设置默认的输⼊输出压缩⽅式。
（5）针对每个⼯作负载参数配置
如果⼯作负载的⽬录下游conf/configure.sh⽂件，则可以通过修改conf/configure.sh来配置每个⼯作负载，所有数据规模以及和这个⼯作负载相关的参数都在这个⽬录配置。
同步所有节点的时间，这在dfsioe是必须做的，其他可做可不做。
2.运⾏
（1）⼀起运⾏多个⼯作负载
在配置⽂件conf/benchmarks.lst中定义了当运⾏/run-all.sh时需要运⾏的⼯作负载。
⽂件中的每⼀⾏都是⼀个指定的⼯作负载.可以⽤#符号来注释掉不需要运⾏的负载。
（2）单独运⾏各个⼯作负载
/>也可以单独运⾏各个⼯作负载。
通常情况下，在每个⼯作负载的
/>⽬录下都有3个独⽴的shell⽂件，这3个⽂件的功能如下。
/>·conf/configure.sh：这个配置⽂件包含数据规模和测试的运⾏参
/>·bin/prepare*.sh：⽣成测试数据或者将输⼊数据复制到HDFS中。
/>·bin/run*.sh：执⾏⼯作负载。
/>如果需要更⾼级的测试需求，则通过修改配置⽂件configure.sh来
/>通过运⾏Shell⽂件bin/prepare.sh⽣成和准备数据（bin/prepareread.sh这个⽂件针对dfsioe）。
/>bin/run*.sh[1]
https://github.com/intel-hadoop/HiBench。
/>[2]
这个只在运⾏Hive的Benchmark时，才需要安装。