Hive数仓建表该选用ORC还是Parquet,压缩选LZO还是Snappy?

大家好,我是后来,周末理个发,赶脚人都精神了不少,哈哈。

因为上一篇文章中提到我在数仓的ods层因为使用的是
STORED AS INPUTFORMAT 'com.hadoop.mapred.DeprecatedLzoTextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'存储模式,但是遇到了count(*) 统计结果与select * 不一样的情况,所以我不得不开始详细了解一下文件的存储格式(虽然还解决不了那个问题,但至少在接近问题真相的路上了,想看这篇文章的,请跳转Hive环境调优大全,但还有个bug没解决,头疼!)。

在数仓中,建议大家除了接口表(从其他数据库导入或者是最后要导出到其他数据库的表),其余表的存储格式与压缩格式保持一致。

我们先来说一下目前Hive表主流的存储格式与压缩方式

文件存储格式

从Hive官网得知,Apache Hive支持Apache Hadoop中使用的几种熟悉的文件格式,如 TextFile(文本格式)RCFile(行列式文件)SequenceFile(二进制序列化文件)AVROORC(优化的行列式文件)Parquet 格式,而这其中我们目前使用最多的是TextFileSequenceFileORCParquet

下面来详细了解下这2种行列式存储。

1、ORC

1.1 ORC的存储结构

我们先从官网上拿到ORC的存储模型图
在这里插入图片描述
看起来略微有点复杂,那我们稍微简化一下,我画了一个简单的图来说明一下

在这里插入图片描述
左边的图就表示了传统的行式数据库存储方式,按行存储,如果没有存储索引的话,如果需要查询一个字段,就需要把整行的数据都查出来然后做筛选,这么做式比较消耗IO资源的,于是在Hive种最开始也是用了索引的方式来解决这个问题。

但是由于索引的高成本,在目前的Hive3.X 中,已经废除了索引,当然也早就引入了列式存储。

列式存储的存储方式,其实和名字一样,它是按照一列一列存储的,如上图中的右图,这样的话如果查询一个字段的数据,就等于是索引查询,效率高。但是如果需要查全表,它因为需要分别取所有的列最后汇总,反而更占用资源。于是ORC行列式存储出现了。

  1. 在需要全表扫描时,可以按照行组读取
  2. 如果需要取列数据,在行组的基础上,读取指定的列,而不需要所有行组内所有行的数据和一行内所有字段的数据。

了解了ORC存储的基本逻辑后,我们再来看看它的存储模型图。
在这里插入图片描述

同时我也把详细的文字也附在下面,大家可以对照着看看:

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

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

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

特别注意:ORC格式的表还支持事务ACID,但是支持事务的表必须为分桶表,所以适用于更新大批量的数据,不建议用事务频繁的更新小批量的数据


#开启并发支持,支持插入、删除和更新的事务
set hive. support concurrency=truei
#支持ACID事务的表必须为分桶表
set hive. enforce bucketing=truei
#开启事物需要开启动态分区非严格模式
set hive.exec,dynamicpartition.mode-nonstrict
#设置事务所管理类型为 org. apache.hive.q1. lockage. DbTxnManager
#原有的org. apache. hadoop.hive.q1.1 eckmar. DummyTxnManager不支持事务
set hive. txn. manager=org. apache. hadoop. hive. q1. lockmgr DbTxnManageri
#开启在相同的一个 meatore实例运行初始化和清理的线程
set hive. compactor initiator on=true:
#设置每个 metastore实例运行的线程数 hadoop
set hive. compactor. worker threads=l
#(2)创建表
create table student_txn
(id int,
name string
)
#必须支持分桶
clustered by (id) into 2 buckets
#在表属性中添加支持事务
stored as orc
TBLPROPERTIES('transactional'='true‘);
#(3)插入数据
#插入id为1001,名字为student 1001
insert into table student_txn values('1001','student 1001');
#(4)更新数据
#更新数据
update student_txn set name= 'student 1zh' where id='1001';
# (5)查看表的数据,最终会发现id为1001被改为 sutdent_1zh

1.2关于ORC的Hive配置

表配置属性(建表时配置,例如tblproperties ('orc.compress'='snappy');

  • orc.compress:表示ORC文件的压缩类型,可选的类型有NONE、ZLB和SNAPPY,默认值是ZLIB(Snappy不支持切片)—这个配置是最关键的。
  • orc. compress.Slze:表示压缩块( chunk)的大小,默认值是262144(256KB)。
  • orc. stripe.size:写 stripe,可以使用的内存缓冲池大小,默认值是67108864(64MB)
  • orc. row. index. stride:行组级别索引的数据量大小,默认是10000,必须要设置成大于等于10000的数
  • orc. create index:是否创建行组级别索引,默认是true
  • orc. bloom filter. columns:需要创建布隆过滤的组。
  • orc. bloom filter fpp:使用布隆过滤器的假正( False Positive)概率,默认值是0.
    扩展:在Hive中使用 bloom过滤器,可以用较少的文件空间快速判定数据是否存表中,但是也存在将不属于这个表的数据判定为属于这个这表的情况,这个称之为假正概率,开发者可以调整该概率,但概率越低,布隆过滤器所需要

2、Parquet

上面说过ORC后,我们对行列式存储也有了基本的了解,而Parquet是另一种高性能的行列式存储结构。

2.1 Parquet的存储结构

既然ORC都那么高效了,那为什么还要再来一个Parquet,那是因为Parquet是为了使Hadoop生态系统中的任何项目都可以使用压缩的,高效的列式数据表示形式,它支持压缩格式:Snappy、GZIP、Lzo

Parquet 是语言无关的,而且不与任何一种数据处理框架绑定在一起,适配多种语言和组件,能够与 Parquet 配合的组件有:

查询引擎: Hive, Impala, Pig, Presto, Drill, Tajo, HAWQ, IBM Big SQL

计算框架: MapReduce, Spark, Cascading, Crunch, Scalding, Kite

数据模型: Avro, Thrift, Protocol Buffers, POJOs

再来看看Parquet的存储结构吧,先看官网给的
在这里插入图片描述
嗯,略微有点头大,我画个简易版

在这里插入图片描述
Parquet文件是以二进制方式存储的,所以不可以直接读取,和ORC一样,文件的元数据和数据一起存储,所以Parquet格式文件是自解析的。

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

2.2Parquet的表配置属性

  • parquet. block size:默认值为134217728byte,即128MB,表示 Row Group在内存中的块大小。该值设置得大,可以提升 Parquet文件的读取效率,但是相应在写的时候需要耗费更多的内存
  • parquet. page:size:默认值为1048576byt,即1MB,表示每个页(page)的大小。这个特指压缩后的页大小,在读取时会先将页的数据进行解压。页是 Parquet操作数据的最小单位,每次读取时必须读完一整页的数据才能访问数据。这个值如果设置得过小,会导致压缩时出现性能问题
  • parquet. compression:默认值为 UNCOMPRESSED,表示页的压缩方式。可以使用的压缩方式有 UNCOMPRESSED、 SNAPPY、GZP和LZO
  • Parquet enable. dictionary:默认为tue,表示是否启用字典编码。
  • parquet. dictionary page.size:默认值为1048576byte,即1MB。在使用字典编码时,会在 Parquet的每行每列中创建一个字典页。使用字典编码,如果存储的数据页中重复的数据较多,能够起到一个很好的压缩效果,也能减少每个页在内存的占用。

3、ORC和Parquet对比

在这里插入图片描述
在这里插入图片描述
同时,从《Hive性能调优实战》作者的案例中,2张分别采用ORC和Parquet存储格式的表,导入同样的数据,进行sql查询,发现使用ORC读取的行远小于Parquet,所以使用ORC作为存储,可以借助元数据过滤掉更多不需要的数据,查询时需要的集群资源比Parquet更少。(查看更详细的性能分析,请移步https://blog.csdn.net/yu616568/article/details/51188479)

所以ORC在存储方面看起来还是更胜一筹

压缩方式

格式可分割平均压缩速度文本文件压缩效率Hadoop压缩编解码器纯Java实现原生备注
gziporg.apache.hadoop.io.compress.GzipCodec
lzo是(取决于所使用的库)非常快中等com.hadoop.compression.lzo.LzoCodec需要在每个节点上安装LZO
bzip2非常高org.apache.hadoop.io.compress.Bzip2Codec为可分割版本使用纯Java
zlib中等org.apache.hadoop.io.compress.DefaultCodecHadoop 的默认压缩编解码器
Snappy非常快org.apache.hadoop.io.compress.SnappyCodecSnappy 有纯Java的移植版,但是在Spark/Hadoop中不能用

存储和压缩结合该如何选择?

根据ORC和parquet的要求,一般就有了

1、ORC格式存储,Snappy压缩

create table stu_orc(id int,name string)
stored as orc 
tblproperties ('orc.compress'='snappy');

2、Parquet格式存储,Lzo压缩

create table stu_par(id int,name string)
stored as orc 
tblproperties ('parquet.compression'='lzo');

3、Parquet格式存储,Snappy压缩

create table stu_par(id int,name string)
stored as orc 
tblproperties ('parquet.compression'='snappy');

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

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

在Hve on Spark的方式中,也是一样的,Spark作为分布式架构,通常会尝试从多个不同机器上一起读入数据。要实现这种情况,每个工作节点都必须能够找到一条新记录的开端,也就需要该文件可以进行分割,但是有些不可以分割的压缩格式的文件,必须要单个节点来读入所有数据,这就很容易产生性能瓶颈。(下一篇文章详细写Spark读取文件的源码分析)

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

©️2020 CSDN 皮肤主题: 黑客帝国 设计师:上身试试 返回首页