spark-sql(三)---spark-sql性能测试

1.测试环境

下图为spark-sql excutor和driver的数量和配置。

另外，每台机器上2个4T硬盘

2.数据环境

从网上扒过来的数据，某些网站泄漏的帐号信息，数据重复冗余很少。处理了一下，在原基础上增大了数据量。
准备的数据量大，是保证结果误差更小，也检测下sparksql数据处理能力。
9个字段，128亿行，纯文本大小1.2T。

3.textfile表

textfile表是默认的存储文件格式，为纯文本文件格式，在数据扫描、索引等方面没有任何优化，所有的操作都是全扫描，textfile表一般作为数据导入的中间格式。

3.1创建textfile外表

create external table test_txt (f1 string,f2 string,f3 string,f4 string,f5 string,f6 string,f7 string,f8 string,f9 string)  ROW FORMAT DELIMITED FIELDS TERMINATED BY '\r' STORED AS TEXTFILE location '/zhaowei';

这种方式是将text表的位置映射到外面hdfs的位置

3.2创建textfile内表，然后load数据进去

create table test_txt2 (f1 string,f2 string,f3 string,f4 string,f5 string,f6 string,f7 string,f8 string,f9 string)  ROW FORMAT DELIMITED FIELDS TERMINATED BY '\r' STORED AS TEXTFILE;load data local inpath '/root/pass.txt' into table test_txt2;

这种方式将本地的数据通过命令直接导入到表的文件夹下面。
打开表的hdfs文件/user/hive/warehouse/test_txt2/，可以看到文件夹下面有一个文件pass.txt。
可见这种方式只是用hdfs命令将本地文件上传到了表的文件夹下面，并没有用spark的mapreduce来处理数据。

3.3全扫描textfile表

0: jdbc:hive2://localhost:10000> select * from test_txt2 where f1='zhaowei';+----------+----------+----------+----------+----------+----------+----------+----------+----------+--+|    f1    |    f2    |    f3    |    f4    |    f5    |    f6    |    f7    |    f8    |    f9    |+----------+----------+----------+----------+----------+----------+----------+----------+----------+--+| zhaowei  | zhaowei  | zhaowei  | zhaowei  | zhaowei  | zhaowei  | zhaowei  | zhaowei  | zhaowei  |64 rows selected (2283.87 seconds)0: jdbc:hive2://localhost:10000> select count(*) from test_txt2;+--------------+--+|   count(1)   |+--------------+--+| 12818207296  |+--------------+--+1 row selected (2233.096 seconds)

扫描1.269T数据，128亿行，用时37分钟。
扫描速度：1269000/37/60=571M/s
由于是三台机器一块执行，每台机器扫描速度190M/s，每台机器2块硬盘，每块硬盘100M/s扫描速度，达到了满负载扫描速度。
由spark的任务界面可以看到，textfile表无论是查询还是count这种操作，都会全扫描文件。

4.orc表

Optimized Row Columnar (ORC),提供了非常高效的方式存储结构化数据。使用orc在hdfs读取、写入、处理结构化数据非常的迅速。

## 建表并将上面的数据导入过来create table test_orc2 as select * from  test_txt2;## 在hdfs文件目录中查看导过来的orc数据量大小[root@ht05 ~]# hdfs dfs -du -s -h /user/hive/warehouse/test_orc2511.1 G  /user/hive/warehouse/test_orc2

同样的数据，textfile原始数据大小为1269G，orc格式为511G，大小缩小了60%。

执行count

0: jdbc:hive2://localhost:10000> select count(*) from test_orc2;+--------------+--+|   count(1)   |+--------------+--+| 12818207296  |+--------------+--+1 row selected (86.216 seconds)

由于orc的特殊存储结构，orc里面的每个数据文件有很多strip file，每个strip file都有一个strip footer，strip footer里面存储了该段数据的row count，row max，row min，row avg等一下聚合结果。所以当做这些聚合运算的时候，就会直接从strip footer里面读取，就无需读取全部的orc数据。

全表扫描

0: jdbc:hive2://localhost:10000> select * from test_orc2 where f1='zhaowei';+----------+----------+----------+----------+----------+----------+----------+----------+----------+--+|    f1    |    f2    |    f3    |    f4    |    f5    |    f6    |    f7    |    f8    |    f9    |+----------+----------+----------+----------+----------+----------+----------+----------+----------+--+| zhaowei  | zhaowei  | zhaowei  | zhaowei  | zhaowei  | zhaowei  | zhaowei  | zhaowei  | zhaowei  |+----------+----------+----------+----------+----------+----------+----------+----------+----------+--+64 rows selected (1354.19 seconds)

将orc的全部数据进行全表扫，扫描了510.9G大小，时间为23分钟
扫描速度为：510.9/23/60=370M/s
单个节点扫描速度370/3=123M/s
orc的扫描速度没有textfile快，但高比例的压缩比减小了一大半的扫描文件，时间也比textfile（37分钟）快了近40%。

5.排序

textfile和orc的排序就没有测试，排序的过程中会有一定的shuffle，是否shuffle和数据内容有关，排序的速度和数据本身有一定关系，没有通用性。

从整个测试过程中发现，执行任务过程中cpu使用率不是很高，一般为15%左右，硬盘使用负载量大，单纯的加硬盘或者加节点应该可以加快整个任务的执行速度。

具体情况具体分析，有的sql语句瓶颈在加载数据，有的sql语句瓶颈在shuffle，有的sql语句瓶颈在计算，根据sparksql任务详细信息，分析执行任务的特点，做相应的调整。