脚本宝典收集整理的这篇文章主要介绍了Hive调优，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

Hive建表优化

1，分区，分桶 一般是按照业务日期进行分区 每天的数据放在一个分区里

2，一般使用外部表，避免数据误删

3，选择适当的文件储存格式及压缩格式

4，命名要规范

5，数据分层，表分离，但是也不要分的太散

Hive查询优化

分区裁剪 where过滤，

先过滤，后join 分区分桶，

合并小文件 适当的子查询（小表全局广播，左连是大表在左，小表在右）

order by 语句： 是全局排序

sort by 语句： 是单reduce排序

distribute by语句： 是分区字段

cluster by语句： 可以确保类似的数据的分发到同一个reduce task中，并且保证数据有序防止所有的数据分发到同一个reduce上，导致整体的job时间延长

cluster by语句的等价语句： distribute by Word sort by Word ASC

Hive数据倾斜优化

 原因：key分布不均匀，数据重复

 表现：任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。单一reduce的记录数与平均记录数差异过大，通常可能达到3倍甚至更多。   最长时长远大于平均时长。

 解决方案：

 1、从数据源头，业务层面进行优化 2、找到key重复的具体值，进行拆分，hash。异步求和。（增加随机数，加盐，可以在key后concat拼接数，最后splIT切分）

 hive> select key,count(*) From data_skew group by key；  （没有优化前）

hive> select t.key,sum(t.c) from       > (select key,if(key=='84401' or key=='null',floor(8*rand()),0) as hash_key,count(*) as c> from data_skew group by key,if(key=='84401' or key=='null',floor(8*rand()),0)) t> group by t.key;

Hive作业优化

调整mapPEr和reducer的数量

太多map导致启动产生过多开销

按照输入数据量大小确定reducer数目set maPRed.reduce.tasks= 默认3

DFs -count /分区目录/*

hive.exec.reducers.max设置阻止资源过度消耗

参数调节

set hive.map.aggr = true （hive2默认开启）

Map 端部分聚合，相当于Combiner

hive.groupby.skewindata=true

脚本宝典总结

以上是脚本宝典为你收集整理的Hive调优全部内容，希望文章能够帮你解决Hive调优所遇到的问题。

如果觉得脚本宝典网站内容还不错，欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。