码迷,mamicode.com
首页 > 其他好文 > 详细

Parquet性能测试调优及其优化建议

时间:2018-02-17 22:06:04      阅读:904      评论:0      收藏:0      [点我收藏+]

标签:def   步骤   性能   结果   单元   最大   list   tle   了解   

                  Parquet性能测试调优及其优化建议

  一、我们为什么选择parquet

  1、选择parquet的外部因素

  1) 我们已经在使用spark集群,spark原本就支持parquet,并推荐其存储格式(默认存储为parquet);

2hive支持parquet格式存储,使用HiveSql查询也是完全兼容的。

  

2、选择parquet的本身原因

  1parquet由于每一列的成员都是同构的,可以针对不同的数据类型使用更高效的数据压缩算法,进一步减小I/OCSV格式一般不进行压缩,通过parquet存储数据有效的节约了空间,不考虑备份情况下,压缩比将近27倍(parquet有四种压缩方式lzogzipsnappyuncompressed,其中默认gzip的压缩方式,其压缩率最高,压缩解压的速率最快);

  2) 查询的时候不需要扫描全部的数据,而只需要读取每次查询涉及的列,这样可以将I/O消耗降低N倍,另外可以保存每一列的统计信息(minmaxsum)

  3) 分区过滤与列修剪中,parquet结合spark可以实现分区过滤(spark sqlrddfilterwhere关键字),列修剪即获取所需要的列,列数越少查询的速率也就也快;

  1. 由于每一列的成员的同构性,可以使用更加适合CPU pipeline的编码方式,减小CPU的缓存失效。

     

  2. parquet的列式存储格式的解析(仅了解)

       技术分享图片

     

    Parquet文件在磁盘上的分布情况如上图,所有的数据被水平切分成Row group,一个Row group包含这个Row group对应的区间内的所有列的column chunk 。一个column chunk负责存储某一列的数据,这些数据是这一列的Repetition levelDefinition levelValues。一个column chunk是由Page组成的,Page是压缩和编码的单元,对数据模型来说是透明的。一个Parquet文件最后是Footer,存储了文件的元数据信息和统计信息。Row group是数据读写时候的缓存单元,所以推荐设置较大的Row group从而带来较大的并行度,当然也需要较大的内存空间作为代价。一般情况下推荐配置一个Row group大小1G,一个HDFS块大小1G,一个HDFS文件只含有一个块。

     

  3. Parquet性能测试

    1)测试普通文件和parquet文件读取列的性能

    测试环境:58.56机器、spark1.6stshive

     

    测试目的:验证spark在读取普通文件和parquet文件性能时,在读取相同的列的速率上面,比普通的文件效率更高,随着列的增加读取的效率会降低。

    测试原理:

    由于以下特性,使得列式存储对于一些运算速率相对行式存储运行速率更快:

    1由于每一列的成员都是同构的,可以针对不同的数据类型使用更高效的数据压缩算法,进一步减小I/O

    2由于每一列的成员的同构性,可以使用更加适合CPU pipeline的编码方式,减小CPU的缓存失效。

    测试步骤

    1)使用C_PORT表建立hive表,同样建立一个C_PORT_PARQUET,使用stored as parquet将表存储为parquet格式;

    2)编写spark读取语句,对列数进行查询读取操作;

    3)增加读取列数,在机器上spark提交任务运行记录运行时间;

    4)对比运行时间,得出最终结论。

     

    测试结果

    27005w数据   普通hive表      request表    测试结果:

查询列数

普通hive表耗时

Parquet表耗时

1

 253

242

5

 353

127

20

 558

356秒  

35

 916

936秒  

50

1319

811

 

总结结论

  通过以上五组数据列的读取得知,随着列数的增加,读取的时间增加,相对于parquet和普通hive的读取速率相近,由此在列数较多时,读取非全部列数据,建议使用parquet存储可以增加读取效率。

 

 

 

 

2)测试parquet列式存储在对多列数据进行列式计算的效率

 

测试环境:58.56机器、spark1.6stshive

 

测试目的:验证spark在读取普通文件和parquet文件性能时,针对某些列式运算列式存储的性能更佳,即读取计算速率更快。

测试原理:

由于以下特性,使得列式存储对于一些运算速率相对行式存储运行速率更快:

1查询的时候不需要扫描全部的数据,而只需要读取每次查询涉及的列,这样可以将I/O消耗降低N倍,另外可以保存每一列的统计信息(minmaxsum),实现部分的谓词下推。

2由于每一列的成员都是同构的,可以针对不同的数据类型使用更高效的数据压缩算法,进一步减小I/O

3由于每一列的成员的同构性,可以使用更加适合CPU pipeline的编码方式,减小CPU的缓存失效。

测试步骤

1)使用C_PORT表建立hive表,同样建立一个C_PORT_PARQUET,使用stored as parquet将表存储为parquet格式;

2)编写spark读取语句,包含列式计算的sumavg以及maxmin语句;

3)在机器上spark提交任务运行记录运行时间;

4)对比运行时间,得出最终结论。

 

测试结果

 

第一组:

27005w数据   普通hive表      request表    (按照每天小时分组,2个求和,3个求平均运算)  

测试结果:

时间

普通hive

Parquet

耗时

  214

  137

耗时

  224

  108

耗时

  227

  136

平均耗时

233

127

 

 

 

第二组:

27005w数据   普通hive表      request表    (按照每天小时分组,2个求和,3个求平均运算,2求最大值,2个求最小值)

测试结果:

时间

普通hive

Parquet

耗时

  222

  138

耗时

  258秒  

  151

耗时

  231秒  

  138

平均耗时

237

142

 

 

 

第三组:

27005w数据   普通hive表      request表    (按照每天小时分组,4个求和,4个求平均运算,4求最大值,4个求最小值)  

测试结果:

时间

普通hive

Parquet

耗时

  303

  158

耗时

  245秒  

  203

耗时

  248秒  

  206

平均耗时

252

202秒  

 

 

总结结论

通过三组数值的比对计算,列式存储格式parquet针对列式计算效率比普通的行式存储有明显的优势,运算的效率提升在30%-40%左右,效率更高,执行效率更快。

 

  1. 测试普通文件和parquet文件的压缩效率对比

    测试环境:58.56机器、spark1.6stshive

     

    测试目的:验证测试普通文件和parquet文件的压缩效率对比,在压缩存储相同数据时,存储为parquet文件压缩效率更高,占用的空间更小。

    测试原理:

    1由于每一列的成员都是同构的,可以针对不同的数据类型使用更高效的数据压缩算法,进一步减小I/O

    2由于每一列的成员的同构性,可以使用更加适合CPU pipeline的编码方式,减小CPU的缓存失效。

    测试步骤

    1)同样的SparkSql运行,存储方式不同。生成相同数据量的parquet文件和普通文件存储;

    2)分别查看生成的Parquet文件和普通文件的大小,对比结果。

     

    测试结果

     

    结果如下图:

     技术分享图片

      经过最终执行结果,存储为普通文件的总大小为12.6G,存储为parquet文件的大小为3.6G,存储所占空间减少了近70%,因此存储为parquet文件占用的空间更小。

     

    四、Parquet在实际项目中的应用建议

    1)当读取的列数并非全部列数,建议使用parquet格式存储(建表时使用stored by parquet);

    2)在进行列式计算或者向量计算时,建议也使用parquet格式存储,可以提高运算效率;

    3)如果有文件需要备份存储,可以使用parquet文件进行压缩,可以有效的节约空间,提高压缩效率和速率。

     

     

     

     

     

     

     

     

     

     

Parquet性能测试调优及其优化建议

标签:def   步骤   性能   结果   单元   最大   list   tle   了解   

原文地址:http://blog.51cto.com/11964104/2071800

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!