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文件和普通文件存储；
（2）分别查看生成的Parquet文件和普通文件的大小，对比结果。
⑤测试结果
结果如下图：
经过最终执行结果，存储为普通文件的总大小为12.6G,存储为parquet文件的大小为3.6G，存储所占空间减少了近70%，因此存储为parquet文件占用的空间更小。
四、Parquet在实际项目中的应用建议
（1）当读取的列数并非全部列数，建议使用parquet格式存储（建表时使用stored by parquet）；
（2）在进行列式计算或者向量计算时，建议也使用parquet格式存储，可以提高运算效率；
（3）如果有文件需要备份存储，可以使用parquet文件进行压缩，可以有效的节约空间，提高压缩效率和速率。
