Hive基本参数手册

type

Post

status

Published

date

Dec 2, 2022

slug

hive-basic-parameters

summary

任务相关

启用压缩

支持的压缩方式：

org.apache.hadoop.io.compress.GzipCodec

org.apache.hadoop.io.compress.SnappyCodec

com.hadoop.compression.lzo.LzopCodec

org.apache.hadoop.io.compress.Lz4Codec

mapreduce内存配置

reduce相关配置

计算reducer数的公式

N=min( hive.exec.reducers.max ，总输入数据量/ hive.exec.reducers.bytes.per.reducer )

输入小文件合并

输入小文件合并可以减小map的个数

hive.input.format设置:

org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; //Map端输入、合并文件之后按照block的大小分割（默认）

org.apache.hadoop.hive.ql.io.HiveInputFormat; //Map端输入，不合并一个文件起一个Map

新版本配置

输出小文件合并

并行计算参数

map聚合

Group By相关

分区相关

本地模式相关

Strict Mode

严格模式不允许执行以下操作：

分区表没有指定分区

没有limit限制的order by

笛卡尔积join时没有on语句

Map-Side Join

Map Join 的计算步骤分两步，将小表的数据变成hashtable广播到所有的map 端，将大表的数据进行合理的切分，然后在map 阶段的时候用大表的数据一行一行的去探测(probe) 小表的hashtable. 如果join key 相等，就写入HDFS.

map join 之所以叫做map join 是因为它所有的工作都在map 端进行计算.

hive 在map join 上做了几个优化： hive 0.6 的时候默认认为写在select 后面的是大表，前面的是小表，或者使用 /*+mapjoin(map_table) */ 提示进行设定. hive 0.7 的时候这个计算是自动化的，它首先会自动判断哪个是小表，哪个是大表，这个参数由（hive.auto.convert.join=true）来控制. 然后控制小表的大小由（hive.smalltable.filesize=25000000L）参数控制（默认是25M），当小表超过这个大小，hive 会默认转化成common join. 你可以查看HIVE-1642.首先小表的Map 阶段它会将自己转化成MapReduce Local Task ，然后从HDFS 取小表的所有数据，将自己转化成Hashtable file 并压缩打包放入DistributedCache 里面. 目前hive 的map join 有几个限制，一个是它打算用BloomFilter 来实现hashtable , BloomFilter 大概比hashtable 省8-10倍的内存, 但是BloomFilter 的大小比较难控制. 现在DistributedCache 里面hashtable默认的复制是3份，对于一个有1000个map 的大表来说，这个数字太小，大多数map 操作都等着DistributedCache 复制.

Skew Join

hive 在运行的时候没有办法判断哪个key 会产生多大的倾斜，所以使用这个参数控制倾斜的阈值，如果超过这个值，新的值会发送给那些还没有达到的reduce, 一般可以设置成你（处理的总记录数/reduce个数）的2-4倍都可以接受.

倾斜是经常会存在的，一般select 的层数超过2层，翻译成执行计划多于3个以上的mapreduce job 都很容易产生倾斜，建议每次运行比较复杂的sql 之前都可以设一下这个参数. 如果你不知道设置多少，可以就按官方默认的1个reduce 只处理1G 的算法，那么 skew_key_threshold = 1G/平均行长. 或者默认直接设成250000000 (差不多算平均行长4个字节)

推测执行

推测执行(Speculative Execution)是指在集群环境下运行MapReduce，可能是程序Bug，负载不均或者其他的一些问题，导致在一个JOB下的多个TASK速度不一致，比如有的任务已经完成，但是有些任务可能只跑了10%，根据木桶原理，这些任务将成为整个JOB的短板，如果集群启动了推测执行，这时为了最大限度的提高短板，Hadoop会为该task启动备份任务，让speculative task与原始task同时处理一份数据，哪个先运行完，则将谁的结果作为最终结果，并且在运行完成后Kill掉另外一个任务。

推测执行的目的是减少作业执行时间，但这是以集群效率为代价的，在一个繁忙的集群中，推测执行会减少整体的吞吐量，因为冗余的任务执行时会减少作业的执行时间，因此一些集群管理员倾向于在集群上关闭这个选项，而让用户根据个别的作业需要而开启该功能。

不建议开启推测执行机制的场景：

Task之间存在固有的不均衡特点，比如有的Reduce Task处理的数据量远大于其他几个

不允许一个任务存在多个实例，比如将MapReduce结果写到Mysql数据库中，不允许一条数据写多分产生冗余