数栈技术分享:Hive优化之配置参数的优化

Hive是大数据领域经常使用的组件之一,主要用于大数据离线数仓的运算,关于Hive的性能调优在平常工做和面试中是常常涉及的一个点,所以掌握一些Hive调优是必不可少的一项技能。影响Hive效率的主要因素有数据倾斜、数据冗余、job的IO以及不一样底层引擎配置状况和Hive自己参数和HiveSQL的执行等。本文主要从建表配置参数方面对Hive优化进行讲解。node

1. 建立一个普通表git

table test_user1(id int, name string,code string,code_id string ) ROW FORMAT DELIMITED FIELDS TERMINATED  BY ',';

2. 查看这张表的信息github

DESCRIBE FORMATTED  test_user1;

咱们从该表的描述信息介绍建表时的一些可优化点。面试

2.1 表的文件数算法

numFiles表示表中含有的文件数,当文件数过多时可能意味着该表的小文件过多,这时候咱们能够针对小文件的问题进行一些优化,HDFS自己提供了解决方案:apache

(1)Hadoop Archive/HAR:将小文件打包成大文件。app

(2)SEQUENCEFILE格式:将大量小文件压缩成一个SEQUENCEFILE文件。框架

(3)CombineFileInputFormat:在map和reduce处理以前组合小文件。工具

(4)HDFS Federation:HDFS联盟,使用多个namenode节点管理文件。oop

除此以外,咱们还能够经过设置hive的参数来合并小文件。

(1)输入阶段合并

须要更改Hive的输入文件格式,即参数hive.input.format,默认值是org.apache.hadoop.hive.ql.io.HiveInputFormat,咱们改为org.apache.hadoop.hive.ql.io.CombineHiveInputFormat。这样比起上面对mapper数的调整,会多出两个参数,分别是mapred.min.split.size.per.node和mapred.min.split.size.per.rack,含义是单节点和单机架上的最小split大小。若是发现有split大小小于这两个值(默认都是100MB),则会进行合并。具体逻辑能够参看Hive源码中的对应类。

(2)输出阶段合并

直接将hive.merge.mapfiles和hive.merge.mapredfiles都设为true便可,前者表示将map-only任务的输出合并,后者表示将map-reduce任务的输出合并,Hive会额外启动一个mr做业将输出的小文件合并成大文件。另外,hive.merge.size.per.task能够指定每一个task输出后合并文件大小的指望值,hive.merge.size.smallfiles.avgsize能够指定全部输出文件大小的均值阈值,默认值都是1GB。若是平均大小不足的话,就会另外启动一个任务来进行合并。

2.2 表的存储格式

经过InputFormat和OutputFormat能够看出表的存储格式是TEXT类型,Hive支持TEXTFILE, SEQUENCEFILE, AVRO, RCFILE, ORC,以及PARQUET文件格式,能够经过两种方式指定表的文件格式:

(1)CREATE TABLE ... STORE AS <file_format>:在建表时指定文件格式,默认是TEXTFILE

(2)ALTER TABLE ... [PARTITION partition_spec] SET FILEFORMAT <file_format>:修改具体表的文件格式

若是要改变建立表的默认文件格式,可使用set hive.default.fileformat=<file_format>进行配置,适用于全部表。同时也可使用set hive.default.fileformat.managed = <file_format>进行配置,仅适用于内部表或外部表。

扩展:不一样存储方式的状况

TEXT, SEQUENCE和 AVRO文件是面向行的文件存储格式,不是最佳的文件格式,由于即使只查询一列数据,使用这些存储格式的表也须要读取完整的一行数据。另外一方面,面向列的存储格式(RCFILE, ORC, PARQUET)能够很好地解决上面的问题。关于每种文件格式的说明,以下:

(1)TEXTFILE

建立表时的默认文件格式,数据被存储成文本格式。文本文件能够被分割和并行处理,也可使用压缩,好比GZip、LZO或者Snappy。然而大部分的压缩文件不支持分割和并行处理,会形成一个做业只有一个mapper去处理数据,使用压缩的文本文件要确保文件不要过大,通常接近两个HDFS块的大小。

(2)SEQUENCEFILE

key/value对的二进制存储格式,sequence文件的优点是比文本格式更好压缩,sequence文件能够被压缩成块级别的记录,块级别的压缩是一个很好的压缩比例。若是使用块压缩,须要使用下面的配置:set hive.exec.compress.output=true; set io.seqfile.compression.type=BLOCK

(3)AVRO

二进制格式文件,除此以外,avro也是一个序列化和反序列化的框架。avro提供了具体的数据schema。

(4)RCFILE

全称是Record Columnar File,首先将表分为几个行组,对每一个行组内的数据进行按列存储,每一列的数据都是分开存储,即先水平划分,再垂直划分。

(5)ORC

全称是Optimized Row Columnar,从hive0.11版本开始支持,ORC格式是RCFILE格式的一种优化的格式,提供了更大的默认块(256M)

(6)PARQUET

另一种列式存储的文件格式,与ORC很是相似,与ORC相比,Parquet格式支持的生态更广,好比低版本的impala不支持ORC格式。

配置一样数据一样字段的两张表,以常见的TEXT行存储和ORC列存储两种存储方式为例,对比执行速度。

TEXT存储方式

总结:从上图中能够看出列存储在对指定列进行查询时,速度更快,建议在建表时设置列存储的存储方式

2.3 表的压缩

对Hive表进行压缩是常见的优化手段,一些存储方式自带压缩选择,好比SEQUENCEFILE支持三种压缩选择:NONE,RECORD,BLOCK。Record压缩率低,通常建议使用BLOCK压缩;

ORC支持三种压缩选择:NONE,ZLIB,SNAPPY。咱们以TEXT存储方式和ORC存储方式为例,查看表的压缩状况。

配置一样数据一样字段的四张表,一张TEXT存储方式,另外三张分别是默认压缩方式的ORC存储、SNAPPY压缩方式的ORC存储和NONE压缩方式的ORC存储,查看在hdfs上的存储状况:

TEXT存储方式

 

默认压缩ORC存储方式

 

SNAPPY压缩的ORC存储方式

 

NONE压缩的ORC存储方式

 

总结:能够看到ORC存储方式将数据存放为两个block,默认压缩大小加起来134.69M,SNAPPY压缩大小加起来196.67M,NONE压缩大小加起来247.55M,TEXT存储方式的文件大小为366.58M,且默认block两种存储方式分别为256M和128M,ORC默认的压缩方式比SNAPPY压缩获得的文件还小,缘由是ORZ默认的ZLIB压缩方式采用的是deflate压缩算法,比Snappy压缩算法获得的压缩比高,压缩的文件更小。ORC不一样压缩方式之间的执行速度,通过屡次测试发现三种压缩方式的执行速度差很少,因此建议采用ORC默认的存储方式进行存储数据。

2.4 分桶分区

Num Buckets表示桶的数量,咱们能够经过分桶和分区操做对Hive表进行优化:

对于一张较大的表,能够将它设计成分区表,若是不设置成分区表,数据是全盘扫描的,设置成分区表后,查询时只在指定的分区中进行数据扫描,提高查询效率。要注意尽可能避免多级分区,通常二级分区足够使用。常见的分区字段:

(1)日期或者时间,好比year、month、day或者hour,当表中存在时间或者日期字段时,可使用些字段。

(2)地理位置,好比国家、省份、城市等

(3)业务逻辑,好比部门、销售区域、客户等等

与分区表相似,分桶表的组织方式是将HDFS上的一张大表文件分割成多个文件。分桶是相对分区进行更细粒度的划分,分桶将整个数据内容按照分桶字段属性值得hash值进行区分,分桶能够加快数据采样,也能够提高join的性能(join的字段是分桶字段),由于分桶能够确保某个key对应的数据在一个特定的桶内(文件),因此巧妙地选择分桶字段能够大幅度提高join的性能。一般状况下,分桶字段能够选择常常用在过滤操做或者join操做的字段。

建立分桶表

create table test_user_bucket(id int, name string,code string,code_id string ) clustered by(id) into 3 buckets ROW FORMAT DELIMITED FIELDS TERMINATED  BY ',';

查看描述信息

DESCRIBE FORMATTED test_user_bucket

多出了以下信息

查看该表的hdfs

一样的数据查看普通表和分桶表查询效率

普通表

分桶表

普通表是全表扫描,分桶表在按照分桶字段的hash值分桶后,根据join字段或者where过滤字段在特定的桶中进行扫描,效率提高。


本文首发于:数栈研习社

数栈是云原生—站式数据中台PaaS,咱们在github上有一个有趣的开源项目:FlinkX

FlinkX是一个基于Flink的批流统一的数据同步工具,既能够采集静态的数据,好比MySQL,HDFS等,也能够采集实时变化的数据,好比MySQL binlog,Kafka等,是全域、异构、批流一体的数据同步引擎,你们若是有兴趣,欢迎来github社区找咱们玩~

相关文章
相关标签/搜索