https://blog.csdn.net/myproudcodelife/article/details/45378957 hive优化实践
https://www.cnblogs.com/juncaoit/p/6077512.html hive调优
最近遇到一张表ddm_content_doc_day 该表是由4张表full outer join 集合整合成的一张大宽表。
从3月20号左右集群突然跟抽风了似的运行特别慢,之前这个任务有13个job 跑大概70分钟左右就能完成,今天3月31号跑了足足4个小时。天啊噜...
于是开始了各种百度搜索的如何优化join..
简单如下:

 hive在实际的应用过程中，大部份分情况都会涉及到不同的表格的连接，例如在进行两个table的join的时候，利用MR的思想会消耗大量的内存，良妃磁盘的IO，大幅度的影响性能，因为shuffle真的好令人担心啊，总之，就是各种问题都是由他产生的。下面介绍一下涉及hive在join的时候的优化方式。

第一：在map端产生join

mapJoin的主要意思就是，当链接的两个表是一个比较小的表和一个特别大的表的时候，我们把比较小的table直接放到内存中去，然后再对比较大的表格进行map操作。join就发生在map操作的时候，每当扫描一个大的table中的数据，就要去去查看小表的数据，哪条与之相符，继而进行连接。这里的join并不会涉及reduce操作。map端join的优势就是在于没有shuffle，真好。在实际的应用中，我们这样设置：

set hive.auto.convert.join=true;

这样设置，hive就会自动的识别比较小的表，继而用mapJoin来实现两个表的联合。看看下面的两个表格的连接。这里的dept相对来讲是比较小的。

第二：common join

common join也叫做shuffle join，reduce join操作。这种情况下生再两个table的大小相当，但是又不是很大的情况下使用的。具体流程就是在map端进行数据的切分，一个block对应一个map操作，然后进行shuffle操作，把对应的block shuffle到reduce端去，再逐个进行联合，这里优势会涉及到数据的倾斜，大幅度的影响性能有可能会运行speculation，这块儿在后续的数据倾斜会讲到。因为平常我们用到的数据量小，所以这里就不具体演示了。

第三：SMBJoin

smb是sort  merge bucket操作，首先进行排序，继而合并，然后放到所对应的bucket中去，bucket是hive中和分区表类似的技术，就是按照key进行hash，相同的hash值都放到相同的buck中去。在进行两个表联合的时候。我们首先进行分桶，在join会大幅度的对性能进行优化。也就是说，在进行联合的时候，是table1中的一小部分和table1中的一小部分进行联合，table联合都是等值连接，相同的key都放到了同一个bucket中去了，那么在联合的时候就会大幅度的减小无关项的扫描。
 首先设置如下：

set hive.auto.convert.sortmerge.join=true;
set hive.optimize.bucketmapjoin = true;
set hive.optimize.bucketmapjoin.sortedmerge = true;
set hive.auto.convert.sortmerge.join.noconditionaltask=true;//但我设置了这一行 报错了 Query returned non-zero code: 1, cause: hive configuration hive.auto.convert.sortmerge.join.noconditionaltask does not exists.