在实际的项目开发当中,hive表的存储格式一般选择:ORC或PARQUET,压缩算法一般选择 Zlib 和 SNAPPY
逻辑表中的数据,最终需要落到磁盘上,以文件的形式存储,有两种常见的存储形式:行式存储和列式存储
优点:
1、相关的数据保存在一起,比较符合面向对象的思维,因为一行数据就是一条记录
2、方便进行insert或update操作
缺点:
1、如果仅需要查询几列数据,它会把整行数据都读取出来,不能跳过不必要的列读取
2、由于每一行中列的数据类型不一致,导致不容易获得一个极高的压缩比(空间利用率不高)
行式存储
适合用于将小文件合并起来,可以获得更高效率的存储和计算
优点:
1、查询时,只有涉及到的列才会被查询,可以跳过不必要的列查询
2、高效的压缩率,不仅节省储存空间也节省计算内存和CPU
3、任何列都可以作为索引
缺点:
1、不适合进行insert或update操作
2、不适合扫描小量的数据
全称为Optimized Row Columnar,最初产生自Apache Hive,用于降低Hadoop数据存储空间和加速Hive查询速度
它并不是一个单纯的列式存储格式,仍然是首先根据行组分割整个表,在每一个行组内进行按列存储
ORC文件是以二进制方式存储的,所以不可以直接读取,ORC文件也是自解析的
优点:
一个ORC文件可以分为若干个Stripe,一个stripe可以分为三个部分:
每个ORC文件文件有一个File Footer,存储的是每个Stripe的行数以及Stripe中每个Column的数据类型信息等;
每个ORC文件文件的尾部是一个Post Script,这里面记录了整个文件的压缩类型以及File Footer的长度信息等。
在读取文件时,会seek到文件尾部读Post Script,从里面解析到File Footer长度,再读FileFooter,从里面解析到各个Stripe信息,再读各个Stripe,即从后往前读
面向分析型业务的列式存储格式,由Twitter和Cloudera合作开发,2015年5月从Apache的孵化器里毕业成为Apache顶级项目
parquet文件是以二进制方式存储的,所以是不可以直接读取。文件中包括该文件的数据和元数据,因此Parquet格式文件是自解析的
通常情况下,在存储Parquet数据的时候会按照Block大小设置行组的大小,由于一般情况下每一个Mapper任务处理数据的最小单位是一个Block,这样可以把每一个行组由一个Mapper任务处理,增大任务执行并行度
优点:
1、减少存储磁盘空间,降低单节点的磁盘IO
2、由于压缩后的数据占用的带宽更少,因此可以加快数据在Hadoop集群流动的速度,减少网络传输带宽
缺点:
1、需要花费额外的时间/CPU做压缩和解压缩计算
问题:MR(Hive的底层是MR)哪些阶段可以进行压缩操作
压缩格式 | 压缩格式所在的类 |
---|---|
Zlib | org.apache.hadoop.io.compress.DefaultCodec |
Gzip | org.apache.hadoop.io.compress.GzipCodec |
Bzip2 | org.apache.hadoop.io.compress.BZip2Codec |
Lzo | com.hadoop.compression.lzo.LzoCodec |
Lz4 | org.apache.hadoop.io.compress.Lz4Codec |
Snappy | org.apache.hadoop.io.compress.SnappyCodec |
问题:Zlib和Snappy两种压缩算法的对比?
Zlib 压缩率 高, 解压速度 慢
Snappy则与Zlib相反,按照业务情况来选择使用