提升Parquet性能的测试与调优技巧及建议
Parquet性能测试调优及其优化建议
一、我们为什么选择parquet
1、选择parquet的外部因素
(1) 我们已经在使用spark集群,spark原本就支持parquet,并推荐其存储格式(默认存储为parquet);
(2) hive支持parquet格式存储,使用HiveSql查询也是完全兼容的。
2、选择parquet的本身原因
(1) parquet由于每一列的成员都是同构的,可以针对不同的数据类型使用更高效的数据压缩算法,进一步减小I/O。CSV格式一般不进行压缩,通过parquet存储数据有效的节约了空间,不考虑备份情况下,压缩比将近27倍(parquet有四种压缩方式lzo、gzip、snappy、uncompressed,其中默认gzip的压缩方式,其压缩率最高,压缩解压的速率最快);
(2) 查询的时候不需要扫描全部的数据,而只需要读取每次查询涉及的列,这样可以将I/O消耗降低N倍,另外可以保存每一列的统计信息(min、max、sum等);
(3) 分区过滤与列修剪中,parquet结合spark可以实现分区过滤(spark sql,rdd的filter和where关键字),列修剪即获取所需要的列,列数越少查询的速率也就也快;
-
由于每一列的成员的同构性,可以使用更加适合CPU pipeline的编码方式,减小CPU的缓存失效。
-
parquet的列式存储格式的解析(仅了解)
Parquet文件在磁盘上的分布情况如上图,所有的数据被水平切分成Row group,一个Row group包含这个Row group对应的区间内的所有列的column chunk 。一个column chunk负责存储某一列的数据,这些数据是这一列的Repetition level,Definition level和Values。一个column chunk是由Page组成的,Page是压缩和编码的单元,对数据模型来说是透明的。一个Parquet文件最后是Footer,存储了文件的元数据信息和统计信息。Row group是数据读写时候的缓存单元,所以推荐设置较大的Row group从而带来较大的并行度,当然也需要较大的内存空间作为代价。一般情况下推荐配置一个Row group大小1G,一个HDFS块大小1G,一个HDFS文件只含有一个块。
-
Parquet性能测试
(1)测试普通文件和parquet文件读取列的性能
①测试环境:58.56机器、spark1.6、sts、hive等
②测试目的:验证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列 |
2分53秒 |
2分42秒 |
5列 |
3分53秒 |
1分27秒 |
20列 |
5分58秒 |
3分56秒 |
35列 |
9分16秒 |
9分36秒 |
50列 |
13分19秒 |
8分11秒 |
⑥总结结论
通过以上五组数据列的读取得知,随着列数的增加,读取的时间增加,相对于parquet和普通hive的读取速率相近,由此在列数较多时,读取非全部列数据,建议使用parquet存储可以增加读取效率。
(2)测试parquet列式存储在对多列数据进行列式计算的效率
①测试环境:58.56机器、spark1.6、sts、hive等
②测试目的:验证spark在读取普通文件和parquet文件性能时,针对某些列式运算列式存储的性能更佳,即读取计算速率更快。
③测试原理:
由于以下特性,使得列式存储对于一些运算速率相对行式存储运行速率更快:
(1)查询的时候不需要扫描全部的数据,而只需要读取每次查询涉及的列,这样可以将I/O消耗降低N倍,另外可以保存每一列的统计信息(min、max、sum等),实现部分的谓词下推。
(2)由于每一列的成员都是同构的,可以针对不同的数据类型使用更高效的数据压缩算法,进一步减小I/O。
(3)由于每一列的成员的同构性,可以使用更加适合CPU pipeline的编码方式,减小CPU的缓存失效。
④测试步骤
(1)使用C_PORT表建立hive表,同样建立一个C_PORT_PARQUET,使用stored as parquet将表存储为parquet格式;
(2)编写spark读取语句,包含列式计算的sum,avg以及max,min语句;
(3)在机器上spark提交任务运行记录运行时间;
(4)对比运行时间,得出最终结论。
⑤测试结果
第一组:
约27005w数据 普通hive表 request表 (按照每天小时分组,2个求和,3个求平均运算)
测试结果:
时间 |
普通hive表 |
Parquet表 |
耗时 |
2分14秒 |
1分37秒 |
耗时 |
2分24秒 |
1分08秒 |
耗时 |
2分27秒 |
1分36秒 |
平均耗时 |
2分33秒 |
1分27秒 |
第二组:
约27005w数据 普通hive表 request表 (按照每天小时分组,2个求和,3个求平均运算,2求最大值,2个求最小值)
测试结果:
时间 |
普通hive表 |
Parquet表 |
耗时 |
2分22秒 |
1分38秒 |
耗时 |
2分58秒 |
1分51秒 |
耗时 |
2分31秒 |
1分38秒 |
平均耗时 |
2分37秒 |
1分42秒 |
第三组:
约27005w数据 普通hive表 request表 (按照每天小时分组,4个求和,4个求平均运算,4求最大值,4个求最小值)
测试结果:
时间 |
普通hive表 |
Parquet表 |
耗时 |
3分03秒 |
1分58秒 |
耗时 |
2分45秒 |
2分03秒 |
耗时 |
2分48秒 |
2分06秒 |
平均耗时 |
2分52秒 |
2分02秒 |
⑥总结结论
通过三组数值的比对计算,列式存储格式parquet针对列式计算效率比普通的行式存储有明显的优势,运算的效率提升在30%-40%左右,效率更高,执行效率更快。
-
测试普通文件和parquet文件的压缩效率对比
①测试环境:58.56机器、spark1.6、sts、hive等
②测试目的:验证测试普通文件和parquet文件的压缩效率对比,在压缩存储相同数据时,存储为parquet文件压缩效率更高,占用的空间更小。
③测试原理:
(1)由于每一列的成员都是同构的,可以针对不同的数据类型使用更高效的数据压缩算法,进一步减小I/O。
(2)由于每一列的成员的同构性,可以使用更加适合CPU pipeline的编码方式,减小CPU的缓存失效。
④测试步骤
(1)同样的SparkSql运行,存储方式不同。生成相同数据量的parquet文件和普通文件存储;
上一篇: OpenOCD初探:如何配置调试适配器
推荐阅读
-
提升Parquet性能的测试与调优技巧及建议
-
【2022新手指南】Java编程进阶之路 - 六、技术架构篇 ### MySQL索引底层解析与优化实战 - 你会讲解MySQL索引的数据结构吗?性能调优技巧知多少? - Redis深度揭秘:你知道多少?从基础到哨兵、主从复制全梳理 - Redis持久化及哨兵模式详解,还有集群搭建和Leader选举黑箱打开 - Zookeeper是个啥?特性和应用场景大公开 - ZooKeeper集群搭建攻略及 Leader选举、读写一致性、共享锁实现细节 - 探究ZooKeeper中的Leader选举机制及其在分布式环境中的作用 - Zab协议深入剖析:原理、功能与在Zookeeper中的核心地位 - RabbitMQ全方位解读:工作模式、消费限流、可靠投递与配置策略 - 设计者视角:RabbitMQ过期时间、死信队列与延时队列实践指南 - RocketMQ特性和应用场景揭示:理解其精髓与差异化优势 - Kafka详细介绍:特性及广泛应用于实时数据处理的场景解析 - ElasticSearch实力揭秘:特性概述与作为搜索引擎的广泛应用 - MongoDB认知升级:非关系型数据库的优势阐述,安装与使用实战教学 - BIO/NIO/AIO网络模型对比:掌握它们的区别与在网络编程中的实际应用 - Netty带你飞:理解其超快速度背后的秘密,包括线程模型分析 - 网络通信黑科技:Netty编解码原理与常用编解码器的应用,Protostuff实战演示 - 解密Netty粘包与拆包现象,怎样有效应对这一常见问题 - 自定义Netty心跳检测机制,轻松调整检测间隔时间的艺术 - Dubbo轻骑兵介绍:核心特性概览,服务降级实战与其实现益处 - Dubbo三大神器解读:本地存根与本地伪装的实战运用与优势呈现 ----------------------- 七、结语与回顾