Hive数据仓库文件存储压缩格式探究及经验总结

目 录

0 引 言

1 文件存储格式研究

1.1 列式存储和行式存储

1.2 TextFile格式

1.3 Orc格式

1.4 Parquet格式

2 主流存储文件对比格式

2.1 存储文件的压缩比测试

2.1.1 测试数据

2.1.2 TextFile

2.1.3 ORC

2.1.4 Parquet

2.1.5 存储文件的压缩比总结

2.2 存储文件的查询速度测试

2.2.1 TextFile

2.2.2 ORC

2.2.3 Parquet

2.2.4 查询性能总结

3 存储和压缩结合

3.1 修改Hadoop集群具有Snappy压缩方式

3.1.1 查看hadoop checknative命令使用

3.1.2 查看hadoop支持的压缩方式

3.1.3 将编译好的支持Snappy压缩的hadoop-2.7.2.tar.gz包导入到hadoop102的/opt/software中

3.1.4 解压hadoop-2.7.2.tar.gz到当前路径

3.1.5 进入到/opt/software/hadoop-2.7.2/lib/native路径可以看到支持Snappy压缩的动态链接库

3.1.6 拷贝/opt/software/hadoop-2.7.2/lib/native里面的所有内容到开发集群的/opt/module/hadoop-2.7.2/lib/native路径上

3.1.7 分发集群

3.1.8 再次查看hadoop支持的压缩类型

3.1.9 重新启动hadoop集群和hive

3.2 测试存储和压缩

3.2.1 创建一个非压缩的的ORC存储方式

3.2.2 创建一个SNAPPY压缩的ORC存储方式

4 存储方式和压缩经验总结

4.1 经验总结

4.2 sqoop导出测试

5 小 结


0 引 言

数仓存储压缩格式的选择对于数仓存储及性能的优化具有重要参考意义,存储优化是一个重要的指标,他可以帮助节省磁盘存储空间,节约了成本。本文对常见的几种压缩存储方案进行了研究,并对其性能各方面进行了测试,给出了数仓中常用的存储压缩解决方案,并对实践中遇到的问题进行了总结,具有一定的借鉴意义。

1 文件存储格式研究

Hive支持的存储数的格式主要有:TEXTFILE SEQUENCEFILEORCPARQUET

1.1 列式存储和行式存储

如图所示左边为逻辑表,右边第一个为行式存储,第二个为列式存储。 

(1)行存储的特点

查询满足条件的一整行数据的时候,列存储则需要去每个聚集的字段找到对应的每个列的值,行存储只需要找到其中一个值,其余的值都在相邻地方,所以此时行存储查询的速度更快。

(2)列存储的特点

因为每个字段的数据聚集存储,在查询只需要少数几个字段的时候,能大大减少读取的数据量;每个字段的数据类型一定是相同的,列式存储可以针对性的设计更好的设计压缩算法。

TEXTFILESEQUENCEFILE的存储格式都是基于行存储的;

ORCPARQUET是基于列式存储的。

1.2 TextFile格式

默认格式,数据不做压缩,磁盘开销大,数据解析开销大。可结合GzipBzip2使用,但使用Gzip这种方式,hive不会对数据进行切分,从而无法对数据进行并行操作。

1.3 Orc格式

Orc (Optimized Row Columnar)Hive 0.11版里引入的新的存储格式。

如图所示可以看到每个Orc文件由1个或多个stripe组成,每个stripe250MB大小,这个Stripe实际相当于RowGroup概念,不过大小由4MB->250MB,这样应该能提升顺序读的吞吐率。每个Stripe里有三部分组成,分别是Index DataRow DataStripe Footer

       1Index Data:一个轻量级的index,默认是每隔1W行做一个索引保存了所在条带的一些统计信息,以及数据在 stripe中的位置索引信息。每个stripe中包含了每个columnmin/max值的索引数据,当查询中有<,>,=的操作时,会根据min/max值,跳过扫描不包含的stripes

      2Row Data:存的是具体的数据,先取部分行,然后对这些行按列进行存储。对每个列进行了编码,分成多个Stream来存储。

       3Stripe Footer:存的是各个Stream的类型,长度等信息。

每个文件有一个File Footer,这里面存的是每个Stripe的行数,每个Column的数据类型信息等;每个文件的尾部是一个PostScript,这里面记录了整个文件的压缩类型以及FileFooter的长度信息等。在读取文件时,会seek到文件尾部读PostScript,从里面解析到File Footer长度,再读FileFooter,从里面解析到各个Stripe信息,再读各个Stripe,即从后往前读。具体如下图所示:

 

所以其实发现,ORC提供了3级索引,文件级、条带级、行组级,所以在查询的时候,利用这些索引可以规避大部分不满足查询条件的文件和数据块。

但注意,ORC中所有数据的描述信息都是和存储的数据放在一起的,并没有借助外部的数据库。

   orc读写原理

在ORC格式的hive表中,记录首先会被横向的切分为多个stripes,然后在每一个stripe内数据以列为单位进行存储。使用ORC文件格式时,用户可以使用HDFS的每一个block存储ORC文件的一个stripe。对于一个ORC文件来说,stripe的大小一般需要设置得比HDFS的block小,如果不这样的话,一个stripe就会分别在HDFS的多个block上,当读取这种数据时就会发生远程读数据的行为。如果设置stripe的只保存在一个block上的话,如果当前block上的剩余空间不足以存储下一个strpie,ORC的writer接下来会将数据打散保存在block剩余的空间上,直到这个block存满为止。这样,下一个stripe又会从下一个block开始存储。

当ORC writer写数据时,会将整个stripe保存在内存中。由于stripe的默认值一般比较大, 大尺寸的stripes使得从HDFS读数据更高效,但当有多个ORC writer同时写数据时,可能会导致内存不足。为了现在这种并发写时的内存消耗,ORC文件中引入了一个内存管理器。在一个Map或者Reduce任务中内存管理器会设置一个阈值,这个阈值会限制writer使用的总内存大小。当有新的writer需要写出数据时,会向内存管理器注册其大小(一般也就是stripe的大小),当内存管理器接收到的总注册大小超过阈值时,内存管理器会将stripe的实际大小按该writer注册的内存大小与总注册内存大小的比例进行缩小。当有writer关闭时,内存管理器会将其注册的内存从总注册内存中注销。

因此,考虑为orc写数据,会将stripe保持到内存中,而stripe的值大,导致内存溢出。每个stripe的默认大小为256MB。

注意:目前平台hive中

set hive.exec.orc.default.stripe.size=67108864;默认64M

1.4 Parquet格式

Parquet是面向分析型业务的列式存储格式,由TwitterCloudera合作开发,20155月从Apache的孵化器里毕业成为Apache顶级项目。

Parquet文件是以二进制方式存储的,所以是不可以直接读取的,文件中包括该文件的数据和元数据,因此Parquet格式文件是自解析的。

通常情况下,在存储Parquet数据的时候会按照Block大小设置行组的大小,由于一般情况下每一个Mapper任务处理数据的最小单位是一个Block,这样可以把每一个行组由一个Mapper任务处理,增大任务执行并行度Parquet

  • 3
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值