hive性能优化及参数调优

2023-06-30

本文主要是 hive性能优化及参数调优 相关的知识问答,如果你也了解,请帮忙补充。

参考知识1 记录一下自己在工作中经常用到的几个参数设置,从调整的实际效果看还是有效果的。

企业相关服务器资源配置:平均600台active的节点,

每个节点可用的内存在200G左右,可用的memory total:116T

1、**set hive.exec.parallel=true;**

开启job的并行:基本每个hql脚本都会开启这个参数,默认并行度为8,

在集群资源充足的情况下,可以提高job并行的数量:

set hive.exec.parallel.thread.number=16;  (企业生产中我是很少用到这个的,都是用的默认值,因为太消耗资源怕影响别的任务,搞不好会被运维抓住,邮件通报批评!当然使用时还是看具体情况吧!)

因为需求中一张表的job的数量每次基本都在20个以上,在相关维度多,涉及到的字段逻辑复杂的情况下,

一张表中job的数量会超过100个,之前做的一个需求中insert插入的脚本中job的数量达到了169个,

在测试环境运行的时候只用了一个小时就跑完了,数据量在一亿条左右,大概有一百多G。

2、**set hive.map.aggr=true;**

在map端中会做部分聚集操作,效率更高但需要更多的内存,可以根据自己企业的资源情况来设置,

如果我的脚本涉及到的数据量不大的话,我一般不会开启这个参数。

3、**set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;**

hive0.5开始的默认值,执行map前进行小文件合并,在一个job中生成的map的数量很多的时候,

和第二个参数一起开启配合使用,在实际生产中多次验证发现可以减少一倍以上的map数量。

在开启前我的一个job的map数量有577个,开启后的map的数量只有196个,极大提高程序的运行效率。

4、**set mapred.max.split.size=256000000;**

每个Map(一个切片的)最大输入大小(这个值决定了合并后文件的数量),和第3个参数配合一起使用

默认值也是256000000,

mapred.min.split.size默认值是10000000

dfs.block.size默认是128M,这个参数通过hive来更改是没有实际用的,只能通过hdfs来修改

***实际在hive中,并不是split的大小要小于等于blocksize,而是可以远大于blocksize,为什么???(map的数量)***

<1>当hive需要处理的文件是压缩,且压缩算法不支持文件切分的时候,决定map个数的因素主要是文件块实际存储的大小,

如果文件块本身很大,比如500Mb左右,那么每个map处理的splitsize至少要是500Mb左右。

这个时候我们不能人为通过参数降低每个map的splitsize来增加map个数,只能通过增加splitsize,减少map个数,

如果hive处理的文件是压缩模式,且压缩模式不支持文件切分,那么这个时候我们只能通过控制参数来减少map个数,而不能通过配置参数来增加map个数,所以Hive对于压缩不可切分文件的调优有限

<2>如果Hive处理的的文件为非压缩格式或者压缩可切分,且inputFormat为CombineHiveInputFormat时,

则控制map个数是由以下四个参数起作用,关于这四个参数作用优先级与使用注意事项请参考如下:

一般来讲这几个参数的结果大小要满足以下条件:

max.split.size >= min.split.size >= min.size.per.node >= min.size.per.rack

几个参数的作用优先级为:

max.split.size <= min.split.size <= min.size.per.node <= min.size.per.rack

总结:所以对于控制map的个数进行调优,首先需要看是否开启了压缩,压缩算法是否支持切分,参数的设置等等!

5、**set mapred.min.split.size.per.node=256000000;**

一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并) ,

和第3和第4个参数一起配合使用。

6、**set mapred.min.split.size.per.rack=256000000;**

一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并) ,

也适合第3,4,5的参数一起配合使用。

7、**set hive.exec.mode.local.auto=true;**

开启本地模式,这个参数在自己学习中可能经常用到,但是在实际生产中用到的还是比较少,

因为这个参数开启后,针对的是小数据集,在单台机器上处理所有的任务,对生产中的任务不适用!

8、**set hive.exec.reducers.bytes.per.reducer=512*1000*1000;**

每个reduce任务处理的数据量,默认为256M,在hive0.14.0之前默认是1G,我们公司设置的是512M,写的是512*1000*1000因为在网络传输中用的是1000,而不是1024机制,

将该参数值调小可以增加reduce的数量,提高运行的效率,

当然也不是reduce的数量越多越好,因为启动和初始化reduce都是会消耗资源和时间的,

而且有多少个reduce就会有多少个输出文件,如果这些文件作为下一个任务的输入,就会造成小文件过多的问题

9、**hive.exec.reducers.max**

每个任务最大的reduce数,默认为1009,在hive0.14.0之前默认是999

计算reducer数的公式很简单N=min(参数9,总输入数据量/参数8)

即,如果reduce的输入(map的输出)总大小不超过1G,那么只会有一个reduce任务;

10、**set mapred.reduce.tasks = 15;**

设置reduce的个数(在实际生产中谨慎使用)

那么什么时候可以进行手动设定reduce数量呢?比如系统自动计算的reduce个数,因为集群资源不足,

造成程序运行出现OOM(内存溢出不足)时,可以根据推定的reduce个数手动增加数量,保证程序在跑的慢的基础上可以完整运行

那么在什么情况下只有一个reduce呢?

<1>、当map的输出文件小于hive.exec.reducers.bytes.per.reducer时

<2>、手动设置set mapred.reduce.tasks =1时

<3>、使用了order by时(全局排序会使用一个reduce去处理)

<4>、表关联时出现笛卡尔积

<5>、单独使用count时,比如:select count(*) from tablename,

如果改写加入了group by配合使用就不会出现一个reduce,比如:select sign_date,count(*) from tablename group by sign_date;

11、**set mapred.job.reuse.jvm.num.tasks=10;**

用于避免小文件的场景或者task特别多的场景,这类场景大多数执行时间都很短,因为hive调起mapreduce任务,JVM的启动过程会造成很大的开销,尤其是job有成千上万个task任务时,JVM重用可以使得JVM实例在同一个job中重新使用N次

12、**set hive.exec.dynamic.partition=true;**

表示开启动态分区功能

13、**set hive.exec.dynamic.partition.mode=nonstrict;**

表示允许所有分区都是动态的,

默认是strict,表示必须保证至少有一个分区是静态的

14、**set hive.groupby.skewindata=true;**

有数据倾斜的时候进行负载均衡 ,决定group by操作是否支持倾斜数据,其实说白了就相当于MR中的conbiner做了一次预聚合。

注意:只能对单个字段聚合。

控制生成两个MR Job,第一个MR Job Map的输出结果随机分配到reduce中减少某些key值条数过多某些key条数过小造成的数据倾斜问题。

在第一个 MapReduce 中,map 的输出结果集合会随机分布到 reduce 中, 每个reduce 做部分聚合操作,并输出结果。这样处理的结果是,相同的 Group By Key 有可能分发到不同的reduce中,从而达到负载均衡的目的;

第二个 MapReduce 任务再根据预处理的数据结果按照 Group By Key 分布到 reduce 中(这个过程可以保证相同的 Group By Key 分布到同一个 reduce 中),最后完成最终的聚合操作

15、**set hive.auto.convert.join=true;**

开启map join

16、**set hive.mapjoin.smalltable.filesize=512000000;**

map join的小表的大小,也是开启和关闭map join的阈值

17、**hive.exec.compress.output=true;**

开启压缩,我们公司使用的是默认的压缩算法deflate

压缩算法有:<1>、org.apache.hadoop.io.compress.GzipCodec,

  <2>、org.apache.hadoop.io.compress.DefaultCodec,

  <3>、com.hadoop.compression.lzo.LzoCodec,

  <4>、com.hadoop.compression.lzo.LzopCodec,

  <5>、org.apache.hadoop.io.compress.BZip2Codec

使用的压缩算法:

set mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.DefaultCodec

**针对上述小文件合并的三个参数值做以下解释:**

大于文件块大小128m的,按照128m来分隔,小于128m,大于100m的,按照100m来分隔,把那些小于100m的(包括小文件和分隔大文件剩下的),进行合并
相似知识
es性能调优 参考知识1elk上线所有应用后,发现日志有延迟现象,少则延迟几分钟,多则延迟半个多小时,查看kafka,发现有大量的消息堆积,于是,我就多增加了几台logstash的机器来消费日志,但是经过观察后,日
ElasticSearch性能优化实践(JVM调优+ES调优) 参考知识1近一年内对公司的ELK日志系统做过性能优化,也对SkyWalking使用的ES存储进行过性能优化,在此做一些总结。本篇主要是讲ES在ELK架构中作为日志存储时的性能优化方案。随着接入ELK的
tomcat 性能调优 参考知识1java性能优化原则:代码运算性能内存回收应用配置(影响java程序注意原因是垃圾回收)代码层优化:避免过多的循环嵌套调用和复杂逻辑Tomcat调优主要内容1.增加最大连接数2.调整工作模式
Elasticsearch性能调优之磁盘读写性能优化 参考知识1优化磁盘空间的占用,减少磁盘空间的占用,更多的数据可以进入filesystemcache比如说你原来,磁盘空间占用一共是1T,内存只有512G,现在优化了磁盘空间占用之后,减少了数据量,可能
北大青鸟java培训:Java性能调优都有哪些技巧? 参考知识1大多数Java开发人员都认为性能优化是复杂的,需要大量的经验和知识。其实这样的说法是有一定的道理的,一般情况下,优化应用程序以获得最好的性能不是一件容易的事。但这并不意味着如果你没有知识,你
linux性能调优都有哪几种方法? 1、为磁盘I/O调整Linux内核电梯算法在选择文件系统后,有一些内核和挂载选项可能会影响到它的性能表现,其中一个内核设置是电梯算法,通过此算法,系统可以平衡低延迟需求,收集足够的数据,从而有效地组织
Elasticsearch性能调优之索引写入性能优化 参考知识11和2,适合的是,你的esjavaclient程序,可以采取批量写的场景3,比较通用的,比较合适的是,你对于写入数据到可以读到能够接受比较大的延迟4,一次性批量导入数据的场景5/6/7/8/
北大青鸟设计培训:简单的Java性能调优技巧? 参考知识1  大多数JAVA开发人员理所当然地以为性能优化很复杂,需要大量的经验和知识。好吧,不能说这是完全错误的。  优化应用程序以获得最佳性能不是一件容易的