会进行此次检测的背景介绍，通过官方以及自己的学习了解进行一些基础解释；使用具体的线上数据进行压缩比，查询性能的测试；查询性能的不同场景，大数据计算、用户查询性能等，包含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 |
数据不做压缩，磁盘开销大，数据解析开销大。 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 |
用于大数据快速的查询，和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}
项目选型
使用场景
- 数据仓库、标签层建设等Spark数据处理；分析团队Impala数据查询，各类BI类查询；统一数据底座数据湖数据置入DW；
能够满足所有的使用场景，在满足使用场景的情况下查询效率更高，尽量少的占用磁盘空间； 选型结论
TextFile一定不会使用，很占用磁盘空间，那么一定需要选型数据编码格式；在数据仓库以及标签层建设中都是基于一部分粒度的一部分数据的计算，所以列式存储占优，那么存储编码选型就压在了RCFile、ORCFile、Parquet；在是否选择压缩过程中我们的考量，既能满足写入的效率不低，又能满足查询的效率足够高；经过测试，实际上添加压缩对于写入的效率影响不大，后续我会补充这部分的实际测试过程；那么在压缩格式中挑选，压缩比高、支持分隔（目前大数据条件下必备），查询效率高，经过实际测试Snappy完全符合条件；最终的编码选型，因为使用场景要满足分析团队的Impala查询，Parquet直接成为首选；Parquet+Snappy 结论 空间压缩效果
parquet+snappy >= Parquet >> TextFile Impala查询效果 单表聚合查询
效率基本一致； 多表联合聚合查询
parquet+snappy分区表 = TextFile未分区 >> TextFile分区表 > parquet分区表 Spark查询效果
因为项目中都在使用，并且Spark并行执行下效率差不是特别明显，所以此处暂时不做效率测试；
