大数据Spark、Mr、Impala使用parquet、textfile、snappy等不同数据存储编码和压缩的效率实测对比以及项目选型

5 篇文章 0 订阅
5 篇文章 0 订阅

整体说明

  • 会进行此次检测的背景介绍,通过官方以及自己的学习了解进行一些基础解释;
  • 使用具体的线上数据进行压缩比,查询性能的测试;
  • 查询性能的不同场景,大数据计算、用户查询性能等,包含Spark以及Impala的性能测试【这部分都是生产中会实际遇到的,希望能给大家阐述的清晰】;
  • 包含具体生产场景的项目选型;

背景

  • 当前背景为生产中真是遇到的问题,并且进行测试和选型;
  • 当前数据层作为数据湖的上游,作为所有数据分析的基础,数据仓库的过程以及所有服务的数据来源,满足各种场景是实际生产中所需要的,包括数据仓库、标签层建设等Spark数据处理,分析团队Impala数据查询,各类BI类查询,统一数据底座数据湖数据置入DW;

存储编码说明

file formatcharacteristicshive storage option
TextFile纯文本STORED AS TEXTFILE
SequenceFile基于行,二进制键值,可分割STORED AS SEQUENCEFILE
Avro基于行,二进制或JSON,可拆分STORED AS AVRO
RCFile列式存储, RLE【游程编码】STORED AS RCFILE
ORCFileOptimized RC, FlattenSTORED AS ORC
Parquet列式二进制编码STORED AS PARQUET

TextFile

  • 数据不做压缩,磁盘开销大,数据解析开销大。

Parquet

  • Parquet文件是以二进制方式存储的,所以是不可以直接读取的,文件中包括该文件的数据和元数据,因此Parquet格式文件是自解析的。
  • Impala推荐使用parquet格式,不支持ORC,Rcfile

压缩格式说明

compression formatcharacteristicssplittable
GZip比Snappy或LZO占用更多的CPU资源;提供更高的压缩比;对于冷数据来说,这是一个很好的选择no
BZip2比GZip压缩更大yes
LZO热数据的更好选择yes if indexed
LZ4明显快于LZOno
Snappy性能优于LZO,是热数据的更好选择yes

Snappy

  • 用于大数据快速的查询,和Parquet联用支持分隔,为快而生,查询过程中减少大量的IO;

空间压缩效果实测

说明

数据表说明
  • 过程中使用的是两张分别为100个字段,数据量为8500w的数据表;

不同形式压缩效果

textfile
  • 38.9 G 116.8 G
parquet
  • 4.1 G 12.2 G
parquet+snappy
  • 4.2 G 12.7 G

Impala查询实测

说明

数据表说明
  • 过程中使用的是两张分别为100个字段,数据量为8500w的数据表;
测试方法说明
  • python直连Impala集群,每单一次查询都进行Impala的connect和close,每个查询分别进行10次,并且计算平均值;

单表条件聚合计算

50个字段的textfile
平均值为: 1.2
{0: 1, 1: 2, 2: 1, 3: 1, 4: 1, 5: 1, 6: 2, 7: 1, 8: 1, 9: 1}
textfile
平均值为: 1.6
{0: 2, 1: 2, 2: 1, 3: 2, 4: 1, 5: 2, 6: 2, 7: 1, 8: 1, 9: 2}
parquet分区表
平均值为: 0.8
{0: 2, 1: 0, 2: 1, 3: 1, 4: 1, 5: 0, 6: 1, 7: 1, 8: 1, 9: 0}
textfile分区表
平均值为: 2.1
{0: 7, 1: 1, 2: 2, 3: 1, 4: 2, 5: 2, 6: 1, 7: 2, 8: 1, 9: 2}
parquet+snappy分区表
平均值为: 1.3
{0: 2, 1: 1, 2: 1, 3: 2, 4: 1, 5: 1, 6: 1, 7: 2, 8: 1, 9: 1}

多表关联后聚合计算

50个字段的textfile
平均值为: 2.7
{0: 3, 1: 2, 2: 2, 3: 2, 4: 3, 5: 2, 6: 4, 7: 3, 8: 3, 9: 3}
textfile
平均值为: 2.9
{0: 4, 1: 3, 2: 3, 3: 2, 4: 3, 5: 3, 6: 2, 7: 3, 8: 3, 9: 3}
parquet分区表
平均值为: 34.5
{0: 28, 1: 29, 2: 29, 3: 31, 4: 30, 5: 59, 6: 32, 7: 45, 8: 33, 9: 29}
textfile分区表
平均值为: 26.8
{0: 25, 1: 28, 2: 27, 3: 27, 4: 26, 5: 27, 6: 27, 7: 27, 8: 27, 9: 27}
parquet+snappy分区表
平均值为: 2.9
{0: 3, 1: 3, 2: 3, 3: 3, 4: 3, 5: 3, 6: 2, 7: 3, 8: 3, 9: 3}

项目选型

使用场景

  1. 数据仓库、标签层建设等Spark数据处理;
  2. 分析团队Impala数据查询,各类BI类查询;
  3. 统一数据底座数据湖数据置入DW;

目标

  • 能够满足所有的使用场景,在满足使用场景的情况下查询效率更高,尽量少的占用磁盘空间;

选型结论

  • TextFile一定不会使用,很占用磁盘空间,那么一定需要选型数据编码格式;
  • 在数据仓库以及标签层建设中都是基于一部分粒度的一部分数据的计算,所以列式存储占优,那么存储编码选型就压在了RCFile、ORCFile、Parquet;
  • 在是否选择压缩过程中我们的考量,既能满足写入的效率不低,又能满足查询的效率足够高;经过测试,实际上添加压缩对于写入的效率影响不大,后续我会补充这部分的实际测试过程;那么在压缩格式中挑选,压缩比高、支持分隔(目前大数据条件下必备),查询效率高,经过实际测试Snappy完全符合条件;
  • 最终的编码选型,因为使用场景要满足分析团队的Impala查询,Parquet直接成为首选;
  • Parquet+Snappy

结论

空间压缩效果

  • parquet+snappy >= Parquet >> TextFile

Impala查询效果

单表聚合查询
  • 效率基本一致;
多表联合聚合查询
  • parquet+snappy分区表 = TextFile未分区 >> TextFile分区表 > parquet分区表

Spark查询效果

  • 因为项目中都在使用,并且Spark并行执行下效率差不是特别明显,所以此处暂时不做效率测试;
  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值