Hive优化方法

JOIN优化——Common Join 优化
• 优点：
不受数据量的大小影响
• 缺点：
效率低
• 调优：
调整reduce个数（mapred.reduce.tasks或者 mapreduce.job.reduces） 数据倾斜
JOIN优化——BucketMapJoin
小表不能完全放入内存 大小表数据量差别非常大 两个表都是分桶表 大表的桶个数是小表桶个数的整数倍 Join列的限制：必须为做bucket的列
数据倾斜优化 —— JOIN
JOIN时存在数据倾斜，优化分两大方面：
Skew Join 重写业务逻辑
数据倾斜优化 —— JOIN
• Skew Join
set hive.optimize.skewjoin = true 记录数超过参数hive.skewjoin.key（默认100000） 设置的大小就是特殊值
输出合并
hive.merge.size.per.task
MR任务输出合并
set hive.merge.mapredfiles=true;
Shuffle过程优化
• Shuffle定义 Hadoop的shuffle过程就是从map端输出到 reduce端输入之间的过程 • 可能的问题：
磁盘IO 网络IO
Map Output Bytes
• 调整reduce个数
通过mapred.reduce.tasks或mapreduce.job.reduc es设置
小文件合并——输入合并
输入是大量小文件的影响： Overhead过大：map task 调度启动时间：4~6s
实际计算时间很小
输入数据是大量小文件怎么办？
key B
value 1
减少处理数据量
• 分区裁剪
查询涉及分区表时，在WHERE子句或ON子句中限制 分区范围
• 列裁剪
只读取查询中需要用到的列，忽略其他不关心的列
select * from …
select t.col1,… from …
合理设置map、reduce个数
增加map/reduce数，提高并发度，可以加快 计算速度，但……
数据倾斜优化 —— JOIN
数据倾斜优化 —— JOIN
• 重写业务逻辑 特殊值——NULL或业务逻辑造成的某个值 譬如： select a.* from logs a join users b on a. user_id = b.user_id;
单独处理非注册用户的关联再合并注册用 户关联。
数据倾斜优化 —— JOIN特殊值
小文件合并——输出合并
输入 输入 任务A 输出 结果表 输入 输入 任务D 任务B 输出
任务C
输出
输出
若任务A输出很多小文件，则后续的任务B/C/D均要做相 应的优化处理。
如何合并输出小文件？
小文件合并——输出合并
Map-Only任务输出 合并 set hive.merge.mapfiles=true;
是不是map 、reduce个 数越多越好呢？
合理设置map、reduce个数
那么设置过多task会造成哪些影响呢？
从单一任务角度看
Task overhead过大 调度成本高
从用户资源调度角度看
抢占资源，造成任务拥堵
合理设置map数
影响Map个数的因素：
hdfs块大小（dfs.block.size: 128M） 文件的大小
maxReducers由参数hive.exec.reducers.max设置，默认 999 bytesPerReducer由参数hive.exec.reducers.bytes.per.red ucer 设置，默认1G
极端：大数据量Count(1) 情况
合理设置reduce个数
• 建议值
512MB~1GB/Task
所有用户提交任务（特别是使用DBVisualizer查询时带上工 号），必须设置下任务名参数（mapreduce.job.name或ma pred.job.name）
如何排查
• 查看用户资源使用
如何排查
• 查看用户资源使用
如何排查
• 某个任务是否正常
map个数 reduce个数 HDFS读数据量：扫全表 每个task 处理数据量：数据倾斜 长尾task 查询语句分析
常见问题——未限制分区
• 查询涉及分区表时
未设置分区限制 使用unix_timestamp方法限制分区
SELECT t.* FROM (SELECT a.* FROM (SELECT * FROM users WHERE user_id = 0) b JOIN (SELECT * FROM logs WHERE user_id = 0) a ON a.user_id = b.user_id UNION ALL SELECT c.* FROM logs c JOIN users d ON c.user_id <> 0 AND c.user _id = d.user_id)t;
BucketMapJoin
set hive.optimize.bucketmapjoin = true;
数据倾斜
• 定义：
由于数据分布不均匀，造成数据热点。
• 表现：
一个或几个key的记录数与平均记录数差异过大， 最长时长远大于平均时长。
数据倾斜示例
数据倾斜——定位倾斜值
• 业务自己判断
那我们碰到数 据倾斜该怎么 办呢？
Shuffle MAP Reduce
Hive执行
以一个GroupBy查询为例：
select name,count(*) from logs group by name
logs name area
A
A A B
China
China China Japan
fileA fileB
Leabharlann Baiduive执行
select name,count(*) from logs group by name
数据倾斜优化
如果特殊值是空值的话呢？
关联的时候给个随机数 示例： select a.* from logs a left outer join users b on (case when a.user_id is null then rand() else a.user_id end) = b.user_id;
常见问题——内存不足
• 发生在reduce阶段
单个reduce处理数据量过大 通过设置参数mapred.reduce.tasks 或 mapreduce.job.reduces 修改reduce个数分散压 力 如果存在数据倾斜的情况，单纯修改reduce个 数没有用
注意事项
• 设置任务名
浪费集群资源
某任务查询涉及分区表，但未限制分区，导致任务 map起了好几万个map
如何优化
减少处理数据量
如何合理的设置map、reduce个数
小文件合并
Shuffle过程优化
JOIN优化
数据倾斜优化
Hive执行
Hive执行其实是将hql语句转换为MapReduc e任务进行运行。
文件的个数
splitsize的大小（ mapred.max.split.size 和mapred.min.split.
size ）
splitSize=Math.max(minSize, Math.min(maxSize, blockSize))
合理设置map个数
• 建议值
128MB~512MB/Task
替换使用to_unix_timestamp方法
常见问题——内存不足
• 内存不足发生的阶段：
Map阶段 Shuffle阶段 Reduce阶段
• 如何解决内存不足问题？
按内存不足发生的阶段进行判断处理
常见问题——内存不足
• 发生在map阶段
一般存在MapJoin 通过设置参数set hive.auto.convert.join = false转 成reduce端的Common Join
数据倾斜优化
操作 GroupBy JOIN 情形 分组key集中 现象 处理某值的reduce非常 耗时
关联key集中（关联字段 处理某值的reduce非常 空值过多） 耗时
数据倾斜优化，分成GroupBy造成的倾 斜和JOIN造成的倾斜来分析解决。
数据倾斜优化 —— GroupBy
set hive.groupby.skewindata = true
常见问题——内存不足
• 发生在shuffle阶段
由于map的输出较大，但shuffle阶段选择的是 拷贝map输出到内存导致。 降低单个shuffle能够消耗的内存占reduce所有 内存的比例（set mapreduce.reduce.shuffle.me mory.limit.percent=0.10），使得shuffle阶段拷 贝map输出时选择落磁盘
• 调大map个数
调小mapred.max.split.size
• 调小map个数
调大mapred.max.split.size
合理设置reduce个数
在未指定reduce个数的情况下，计算公式 如下：
reducers = Math.min(maxReducers, totalInputFi leSize/bytesPerReducer)
hive.map.aggr
logs name area
MAP
Reduce
key
key A value 2 Shuffle key A B value 1 1
value 2
1
key A
value 3
A
A
A
A
China
China
logs name A B area China Japan
key B
value 1
JOIN优化——大小表关联
两个表关联时，如果一个表非常大、另一个表非 常小，可采用MapJoin。 小表放左边，开启参数hive.auto.convert.join（默 认开启）。
hive.auto.convert.join=true MapJoin
小表文件大小小于 hive.mapjoin.smalltable.filesize（默认 25M）
考虑输入合并
小文件合并——输入合并
输入合并示例：
set hive.input.format = org.apache.hadoop.hive.ql.io.c ombinehiveinputformat; set mapred.max.split.size = 536870912; //512MB set mapred.min.split.size = 134217728; //128MB
• 优化思路： 减小各种IO
Shuffle过程优化
• 优化方法 中间结果压缩（集群默认开启）
（1）开启中间结果压缩： set mapred.compress.map.output=true; （2）设置中间结果压缩算法： set mapred.compress.output.compression.codec=co m.hadoop.compression.lzo.LzoCodec;
Hive优化方法简介
目录
为什么要优化
如何优化
如何排查
常见问题
注意事项 Hive-0.13新特性
为什么要优化
• Hive使用简单 • 门槛低 • 容易造成误用
为什么要优化
• 低效的查询语句会带来哪些问题？
耗时长
任务类型 Sqoop任务A Sqoop任务A 是否优化 否 是 耗时 3hrs, 58mins, 35sec 1hrs, 9mins, 17sec
• 业务不清楚 如果sql：select ta.c1,ta.c2,tb.c2 from ta left join tb on ta.c1=tb.c2 存在数据倾斜，怎么查出倾 斜值？ select c2,count(*) as a from tb group by c2 order by a desc limit 20;
• 先不按GroupBy字段分发，随机分发做一次 聚合 • 额外启动一轮job，拿前面聚合过的数据按G roupBy字段分发再算结果
数据倾斜优化 —— JOIN
Join造成的倾斜，譬如网站访问日志和用户表两 个表关联，其中网站访问日志中非注册用户 （user_id=0）访问占了绝大多数，sql如下： select a.* from users b join logs a on a.user_id = b.user_id; 执行时会导致user_id=0所在的reduce处理的特别 慢。