Parquet性能测试之项目实践中应用测试

因为从事大数据方面的工作,经常在操作过程中数据存储占空间过大,读取速率过慢等问题,我开始对parquet格式存储进行了研究,下面是自己的一些见解(使用的表都是项目中的,大家理解为宽表即可):

一、SparkSql中两种格式存储的读写性能(以资源产品拓扑信息宽表为例)
1、假设:由于对于parquet存储格式来说,针对列式的查询读取操作以及列式的计算性能更高于普通的存储格式,所以在读取相同的sql过程中,表的存储格式为parquet,读取的性能更高,所花费的时间更少。
2、测试步骤:
①将sparksql用的相关hive表,建立相同的parquet存储格式的表;
②分别执行生成的jar包,进行数据的整合;
③统计运行的时间,进行比较得出结论。

3、测试结果:(可能是由于资源占用问题第三次测试中parquet存储格式花费时间较长,但是仍然低于hdfs格式存储的读取效率)

次数|时间 Parquet格式表 普通格式表
第1次 9分0秒 14分51秒
第2次 9分38秒 14分18秒
第3次 13分9秒 16分14秒
平均时间 10分36秒 15分08秒

4、测试分析
此次测试,使用相同的sparksql进行读取转化,只是所使用的hive 的存储方式不同,由以上的执行时间来看,很明显在读写生成资源产品拓扑信息宽表过程中,建表为parquet存储所花费的时间更少,假设成立。

二、存储的格式不同,列式计算中parquet格式存储比普通文件存储进行列式运算的效率更高
1、假设:由于parquet进行列式存储,不需要扫描全部全部的数据,只读取每次查询涉及的列,这样可以将I/O降低至N倍,另外可以保存每一列的统计信息实现部分谓词下推。因此,我们假设存储的格式不同,列式计算中parquet格式存储比普通文件存储进行列式运算的效率更高
2、测试步骤:
①对sparksql中需要处理的表存储为parquet格式和普通格式;
②执行列式运算的sparksql;
③对比执行时间,得出结论。

3、测试结果:
生成文件来源|执行所花费的时间 Parquet格式存储运算耗时 普通格式存储耗时 Sql难度分析
七天质量跟踪(Build_mov_fix_7day_fix)用表ksdd_oss.build_mov_fix 2分18秒 7分50秒 Sparksql要对500万左右的数据进行多次分组求最大值
计算客户健康度分数(Cust_Count_Yarn)用表ksdd_oss.cust_health_detail 4分3秒 4分45秒 Sparksql要对40亿的数据查一天并进行多组复杂的加减求最大值以及判断最终获取结果
客户健康档案--开通装移修监控期数据(Build_mov_fix_7day_health)用表ksdd_oss.cust_health_detail和ksdd_oss.cust_health_detail_num 12分49秒 4分2秒 Sparksql对健康档案详单和统计表7天的数据进行计算关联,两张表的数据在40亿以上

4、测试分析
此次测试,通过复杂的大数据量的数据进行运算,写出结果。通过执行的时间,我们可以从里面看出执行效率如何。从前两次测试结果来看parquet格式存储的优势明显高于普通的文件存储。而从第三个来看关联查询运算,数据量也比较大,测试结果并非我们所假设的那样。什么原因造成的上述结果,经过查询资料,我们得知在列数查询较少的情况下,我们使用parquet格式存储进行查询的效率很高,包括直接impala查询大表所消耗的时间也是相比来说非常短。造成上述原因的主要原因应该是所需要进行聚合函数的字段过多,导致parquet格式存储的查询效率极具降低。因此,我们在进行sparksql执行时要考虑到所使用的表字段的个数,若是字段过多,建议使用一般的存储格式,不宜使用parquet来存储。通过分析,我们对假设要分情况来讨论,通过具体的字段数来决定使用哪种方式来进行数据格式的存储。

三、存储格式不同,Parquet格式存储所占用的内存更小
1、假设:由于parquet存储格式每一列的成员都是同构的,针对不同的数据类型使用更高效的数据压缩算法,进一步减少I/O;并且由于每一列的成员的同构性,可以使用更加适合CPU pipeline的编码方式,减少CPU的缓存失效,所以我们假设存储格式不同,Parquet格式存储所占用的内存更小。
2、测试步骤:
①生成相同数据量;
②将生成的数据按照普通文件格式存储和parquet格式存储;
③查看生成文件所占用的空间大小,进而得出结论。

3、测试结果:

生成文件的来源|所占用内存大小 Parquet存储文件大小 普通文件大小 相对节约比例 节约空间大小
资源产品拓扑信息宽表中间文件(zyproinfotwo) 3.6G 12.6G 71.4% 9G
资源宽表回写oracle的数据(zydata_to_oracle) 726M 2.3G(2355.2M) 69.2% 1629.2M
拓扑导入bras数据(topo_add_stb) 294.3M 1.2G(1228.8M) 76% 934.5M

4、测试分析
此次测试,我们可以通过测试的数据看出使用Parquet格式来存储数据,占用的空间更小,节约的空间在70%以上,在我们的应用之中针对大数据量的基础表的存储,我们可以生成parquet格式进行存储,在代码之中我们可以通过读取所需的文件解析注册成临时表再进行操作提取所需要的字段。由此看见假设成立,存储格式不同,Parquet格式存储所占用的内存更小。

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

时间: 2024-10-08 14:18:39

Parquet性能测试之项目实践中应用测试的相关文章

性能测试之线上引流测试--让性能测试更真实更丰富

为什么要做引流测试 目前为止大部分的测试是在测试环境下,通过模拟用户的行为来对系统进行验证,包括功能以及性能.在这个过程中,你可能会遇到以下问题: 用户访问行为比较复杂,模拟很难和用户行为一致,模拟不够真实; 线下模拟场景有限,会出现业务覆盖不全的情况.引流测试就是为了解决以上问题,通过把线上的真实流量复制到线下环境,解决测试环境模拟不够真实,或覆盖不够全面的问题. 引流的做法 目前不少公司对引流测试进行了实践,主要有以下4种引流方式: 以上几种办法各有利弊,有的是需要自己开发相应的工具来支持.

项目实践中Linux集群的总结和思考

前言:作为一名Linux/unix系统工程师.项目实施工程师,这几年一直在涉及到对外项目,经手过许多小中型网站的架构,F5.LVS及Nginx接触的都比较多,我想一种比较通俗易懂的语气跟大家说明下何谓负载均衡,何谓Linux集群,帮助大家走出这个误区,真正意义上来理解它们,具体项目施工案例请参考我在network.51cto.com上的同类文章.一.目前网站架构一般分成负载均衡层.web层和数据库层,我其实一般还会多加一层,即文件服务器层,因为现在随着网站的PV越来越多,文件服务器的压力也越来越

项目实践中--Git服务器的搭建与使用指南(转)

一.前言 Git是一款免费.开源的分布式版本控制系统,用以有效.高速的处理从很小到非常大的项目版本管理.在平时的项目开发中,我们会使用到Git来进行版本控制. Git的功能特性: 从一般开发者的角度来看,git有以下功能: 1.从服务器上克隆数据库(包括代码和版本信息)到单机上. 2.在自己的机器上创建分支,修改代码. 3.在单机上自己创建的分支上提交代码. 4.在单机上合并分支. 5.新建一个分支,把服务器上最新版的代码fetch下来,然后跟自己的主分支合并. 6.生成补丁(patch),把补

项目实践中--Git服务器的搭建与使用指南

一.前言 Git是一款免费.开源的分布式版本控制系统,用以有效.高速的处理从很小到非常大的项目版本管理.在平时的项目开发中,我们会使用到Git来进行版本控制. Git的功能特性: 从一般开发者的角度来看,git有以下功能: 1.从服务器上克隆数据库(包括代码和版本信息)到单机上. 2.在自己的机器上创建分支,修改代码. 3.在单机上自己创建的分支上提交代码. 4.在单机上合并分支. 5.新建一个分支,把服务器上最新版的代码fetch下来,然后跟自己的主分支合并. 6.生成补丁(patch),把补

[PHP] 项目实践中使用的IOC容器思想

1.容器的意思就是一个全局变量,里面存了很多对象,如果要用到某个对象就从里面取,前提就是要先把对象放进去2.控制反转就是把自己的控制权交给别人3.这两个结合就是,把自己的控制权交给别人并且创建的对象放进一个全局变量里4.好处就是可以灵活的修改一个对象的属性,而不需要去修改类本身的代码 项目实践:1.Application对象的resources属性数组就是那个容器2.getResource方法就是控制生成对象的方法,生成一个对象的控制权交给了Application3.这里先简化的规定下,自定义的

一次项目实践中DBCP数据库连接池性能优化

关于数据库连接池DBCP的关注源于刚刚结束的一轮测试,测试内容是衡量某Webserver服务创建用户接口的性能.这是一款典型的tomcat应用,使用的测试工具是Grinder.DBCP作为tomcat服务器常用的数据库连接池,其性能表现直接关乎应用的性能. 1.遇到的问题 当并发量增加到100时,该接口出现瓶颈,此时TPS接近400,如下图.但是服务端CPU和内存等资源并未达到瓶颈,服务器CPU使用率仅为30%,内存使用率为40%.监控到的javaMethod慢方法为incrAppAccount

[Java 泥水匠] Java Components 之二:算法篇之项目实践中的位运算符(有你不懂的

作者:泥沙砖瓦浆木匠 网站:http://blog.csdn.net/jeffli1993 个人签名:打算起手不凡写出鸿篇巨作的人,往往坚持不了完成第一章节. 交流QQ群:[编程之美 365234583]http://qm.qq.com/cgi-bin/qm/qr?k=FhFAoaWwjP29_AonqzL0rpdQAjjqlHQQ 如果我的帮到了你,是否乐意捐助一下或请一杯啤酒也好呢?有你支持,干的更好~ 点这参与众筹 我的支付宝:13958686678 2.1 前言 自从上篇[Java 泥水

项目实践中的机器学习

这里介绍机器学习的六大步骤 一.定义问题 二.理解数据 三.数据准备 四.评估算法 五.优化模型 六.结果部署 (当然,这六个步骤并非机械的使用,有时候各个步骤还可能进一步细分,还有可能几个步骤合并成一个步骤.这里以常用的python模板为例) 详细说明 一.定义问题 需要导入常用的类库和数据集,包括导入python 的类库.类和方法,以及数据.可以将数据进行瘦身,快速进行可视化数据集建立. 二.理解数据 描述性统计来分析数据,可视化观察数据.***这一步需要花费时间多问几个问题,设定假设条件并

测试人员为什么要深入到项目实现中去?

(“马蜂窝技术”公众号原创内容,ID: mfwtech) 一个项目从需求确定到最后上线,通常来说流程是这样的: 「测试」作为一个项目质量保证角色,在上面的整个流程中均有参与.而用例设计.项目测试环节更像测试的主场,PRD 的评审测试人员也会发表很多自己的观点,对项目的技术评审虽然测试人员也有参与,但也不如前两个环节的参与程度深. 其实,一个优秀的测试人员应该深入到项目的每一个环节中去发现问题,提出自己的观点,保证项目质量.那么要真正深入到项目实现中,测试应该怎么做呢? 一.Review 接口定义