HIve之ORC与Parquet

Orc与parquet的区别

表类型默认压缩压缩格式描述
OrcZlibNode、Zlib、SnappyOrc可以选择Zlib或Snappy压缩,Snappy需要额外安装
ParquetUncompressedUncompressed、Snappy、Gzip、LzoParquet使用gzip压缩率高,使用lzo、snappy效率高

ORC列式存储

但支持的压缩格式有限,Orc表支持None、Zlib、Snappy压缩,默认支持Zlib压缩。但这3种压缩格式不支持切分,所以适合单个文件不是特别大的场景。使用Zlib压缩率高,但效率差一些,使用Snappy效率高,但压缩率低。

Parquet表支持Uncompress、Snappy、Gzip、lzo压缩,默认不压缩Uncompressed。其中Lzo压缩是支持切分的,所以在表的单个文件较大的场景会选择Lzo格式。Gzip方式压缩率高,效率低;而Snappy、Lzo效率高,压缩率低。

全局压缩配置:

除了在建表时手动指定Orc、Parquet表的压缩格式的属性之外,也可以在执行建表语句前,使用set命令指定

--设置parquet表的压缩格式为SNAPPY
set parquet.compression=SNAPPY;
--设置orc表的压缩格式为SNAPPY
set orc.compress=SNAPPY

当然了,这也意味着你可以将参数直接全局配置到hive-site.xml文件种,来规定表的的压缩格式。

在这里插入图片描述

  • 条带(Stripe):ORC文件存储数据的地方,每个Stripe一般为HDFS的块大小(包含以下三个部分)
    1. index data:保存了所在条带的一些统计信息,以及数据在stripe种的位置索引信息
    2. row data:数据存储的地方,由多个行组构成,每10000行构成一个行组,数据以stream的形式进行存储
    3. stripe footer:保存数据所在的文件目录
  • 文件标注(file footer):包含了文件种stripe的列表,每个stripe的行数,以及每个列的数据类型。它还包括每个列的数据类型。它还包括每个列的最小值、最大值、行计数、求和等聚合信息。
  • postscript:含有压缩参数和压缩大小相关的信息。

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

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

  • 特别注意,orc格式的表还支持事务ACID,但是支持事务的表必须是分桶表(因为Hive事务的实现主要依赖于表分桶的存储格式,如果表没有分桶,那么表底下的文件就会很散乱,hive的事务机制无法有效的读取),所以适用于更新大批量的数据,不建议用事务频繁的更新小批量的数据。

Parquet列式存储

既然ORC都那么高效了,那为什么还有parquet,那是因为**Parquet为为了使hadoop生态系统中的任何项目都可以使用压缩的,高效的列式数据表示形式,**它支持压缩格式:Snappy、Gzip、Lzo

在这里插入图片描述

Parquet文件是以二进制方式存储的,所以不可以直接读取,和ORC一样,文件的元数据和数据一起存储,所以Parquet格式文件自解析的。

  1. 行组(row Group):每一个行组包含一定的行数,在一个HDFS文件中至少存储一个行组,类似于orc的stripe的概念。
  2. 列块(Column Chunk):在一个行组中每一列保存在一个列块中,行组中的所有列连续的存储在这个行组文件中。一个列块中的值都是相同类型的,不同的列块可能使用不同的算法进行压缩。
  3. 页(Page):每一个列块划分为多个页,一个页是最小的编码的单位,在同一个列块的不同页可能使用不同的编码方式。

在hive的性能比较中,同样的数据,进行sql查询,发现使用ORC读取的行远小于Parquet,所以使用ORC作为存储,可以借助元数据过滤掉更多不必要的数据,查询时需要的集群资源比Parquet少,所以ORC在存储方面看起来还是更胜一筹

选择Parquet的生产原因

因为Hive的sql会转化为MR任务,如果该文件使用ORC作为存储,Snappy压缩的,因为Snappy不支持文件分割操作,所以压缩文件只会被一个任务所读取,如果压缩文件很大,那么处理该文件的Map需要花费的时间会多余普通文件Map时间,这就是常说的Map读取文件的数据倾斜

那么为了避免这种情况的发生,就需要在数据压缩的时候采用bzip2和lzo等支持文件分割的压缩算法。但恰当ORC不支持刚说的压缩方式,所以这也就成为大家在可能遇到大文件的情况下不选择ORC的原因,避免数据倾斜。

的压缩算法。但恰当ORC不支持刚说的压缩方式,所以这也就成为大家在可能遇到大文件的情况下不选择ORC的原因,避免数据倾斜。

所以在实际生产中,使用Parquet存储,lzo压缩的方式更为常见,这种情况下可以避免由于读取不可分割大文件引发的数据倾斜。但是,如果数据量并不大(预测不会有超大文件,若干G以上)的情况下,使用ORC存储,snappy压缩效率还是非常好的。

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值