干货：Hive优化与数据倾斜总结！

Hive优化与数据倾斜

a.优化：

	1.使用mapJoin功能，默认为打开状态

	2.创建表的时候，采用分区表和分桶表，可以避免全表扫描，加快速度

	3.采用行列过滤，join where 改为 先where再join

	4.小文件方向：
		-- JVM重用，重用次数10~20次

		-- conbineHiveInputformat合并小文件，可以减少mapTask数量

		-- merge（输出时合并小文件）
			SET hive.merge.mapfiles = true; 默认true，在map-only任务结束时合并小文件

			SET hive.merge.mapredfiles = true; 默认false，在map-reduce任务结束时合并小文件

			SET hive.merge.size.per.task = 268435456; 默认256M

			SET hive.merge.smallfiles.avgsize = 16777216; 当输出文件的平均大小小于16m该值时，启动一个独立的map-reduce任务进行文件merge

		-- 开启JVM重用
			set mapreduce.job.jvm.numtasks=10 默认10次，可改为10~20次

	5.采用列式存储，加快查询速度

	6.采用压缩，map输出阶段采用snappy（快）或lzo（支持切片）压缩

	7.提前进行conbiner预聚合，注意不影响后面的业务逻辑，例如求平均数不可用

	8.可以切换计算引擎：
		-- MR：运行大型任务时采用（月指标或年指标），基于磁盘，虽然慢，但一定可以跑出结果

		-- spark：基于内存，目前市场常用，查询速度非常快，一般用于执行当天的任务

		-- tez：不常用，基于内存，对于数据量小的任务非常合适，常用于处理一些临时的任务，经常出现小bug

	9.mapReduce内存分配 128g对应一个g的内存
	改变切片大小 max（0，min（块大小，long最大值））

	10.对hive的元数据增加高可用配置


b.数据倾斜产生之后的表现：

	1.有一个或多个reduce卡在99.99%，一直不能结束

	2.各种container报错，OOM

	3.异常的reduce读写的数据量非常大，远超其他正常的reduce

	4.随着数据倾斜的发生，任务会诡异的被kill掉


c.数据倾斜产生的原因：

	操作上采用了会引起shuffle的操作（distinct count，group by，join on等）导致相同key的值会被分配到一个或几个reduce上进行计算；

	总结如下：
		1.key分布不均匀

		2.两张表数据类型不同，join on阶段直接卡死

		3.业务数据激增：比如上海，北京双11订单激增，group操作直接数据倾斜；


d.如何解决数据倾斜（4个方面）：

	1.业务逻辑方面：
		比如上海，北京订单问题，我们可以单独将上海和北京按照地区打散，进行2次MR，再与其他城市进行整合操作；

	2.程序方面：
		比如用sum（）+ group by代替count（distinct），再增加reduce个数

	3.调参方面：
		开启数据倾斜时负载均衡
		set hive.groupby.skewindata=true;

	4.从业务和数据上解决数据倾斜：
		-- 把关键字段为0或空值给过滤掉（可能损坏数据）
		-- 对分布不均匀的数据单独计算
		-- 将key加上随机值打散，增加并行度，再做聚合处理