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

整体说明

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

背景

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

存储编码说明

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

TextFile

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

Parquet

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

压缩格式说明

compression format	characteristics	splittable
GZip	比Snappy或LZO占用更多的CPU资源;提供更高的压缩比;对于冷数据来说，这是一个很好的选择	no
BZip2	比GZip压缩更大	yes
LZO	热数据的更好选择	yes if indexed
LZ4	明显快于LZO	no
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并行执行下效率差不是特别明显，所以此处暂时不做效率测试；