本文记录的是，在数据处理过程中，遇到了一个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。如果资源充裕的情况下，可以将此值设置的大一些。但是绝对不是越大越好，单纯靠提升内存来优化程序是不被推荐的。

数据迁移过程中hive sql调优