本文记录的是,在数据处理过程中,遇到了一个sql执行很慢,对一些大型的hive表还会出现OOM,一步一步通过参数的设置和sql优化,将其调优的过程。
先上sql
select t1.create_time from
(
select * from beatles_ods.route where year=2017 and month=07 and day=01
) t1
left outer join
(
select * from (select *,row_number() over(partition by id) num from beatles_test.route where year=2017 and month=07 and day=01) t where t.num =1
) t2
on t1.id = t2.id where t2.id = NULL;
可以看到这个sql由1个join,一个去重语句,组成,这两种操作都是很耗费资源的。
1、对链接操作,小表放在链接左边。
这是一个老生常谈的事情了,在这里不做细致介绍。基本来说,小表会减少mapreduce过程中的shuffle。
事实上“把小表放在前面做关联可以提高效率”这种说法是错误的。正确的说法应该是“把重复关联键少的表放在join前面做关联可以提高join的效率。”
最终得出的结论是:写在关联左侧的表每有1条重复的关联键时底层就会多1次运算处理。
假设A表有一千万个id,平均每个id有3条重复值,那么把A表放在前面做关联就会多做三千万次的运算处理,这时候谁写在前谁写在后就看出性能的差别来了。
如果想深刻了解,请移步:
http://blog.sina.com.cn/s/blog_6ff05a2c01016j7n.html
2、调整reduce的个数,这个个数可以调整到256以内,并不是越大越好,太大会消耗集群上的资源,并增加汇总压力。
set mapred.reduce.tasks = 30;
3、将内存调大,防止内存溢出
设置map和reduce的内存
set mapreduce.map.memory.mb=4096; set mapreduce.reduce.memory.mb=4096;
设置JVM内存
set mapreduce.map.java.opts=-Xmx2500M;
map和reduce可以视情况开大一些,我这里设置的是4G。如果资源充裕的情况下,可以将此值设置的大一些。但是绝对不是越大越好,单纯靠提升内存来优化程序是不被推荐的。