**1.1.1 **Hive优化
- MapJoin
如果不指定MapJoin或者不符合MapJoin的条件，那么Hive解析器会将Join操作转换成Common Join，即：在Reduce阶段完成join。容易发生数据倾斜。可以用MapJoin把小表全部加载到内存在map端进行join，避免reducer处理。
- 行列过滤
列处理：在SELECT中，只拿需要的列，如果有，尽量使用分区过滤，少用SELECT *。
行处理：在分区剪裁中，当使用外关联时，如果将副表的过滤条件写在Where后面，那么就会先全表关联，之后再过滤。
采用分桶技术
采用分区技术
合理设置Map数
a. 通常情况下，作业会通过input的目录产生一个或者多个map任务。
主要的决定因素有：input的文件总个数，input的文件大小，集群设置的文件块大小。
b. 是不是map数越多越好？
答案是否定的。如果一个任务有很多小文件（远远小于块大小128m），则每个小文件也会被当做一个块，用一个map任务来完成，而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。而且，同时可执行的map数是受限的。
c. 是不是保证每个map处理接近128m的文件块，就高枕无忧了？
答案也是不一定。比如有一个127m的文件，正常会用一个map去完成，但这个文件只有一个或者两个小字段，却有几千万的记录，如果map处理的逻辑比较复杂，用一个map任务去做，肯定也比较耗时。
针对上面的问题2和3，我们需要采取两种方式来解决：即减少map数和增加map数；
- 小文件进行合并
在Map执行前合并小文件，减少Map数：CombineHiveInputFormat具有对小文件进行合并的功能（系统默认的格式）。HiveInputFormat没有对小文件合并功能。
- 合理设置Reduce数
Reduce个数并不是越多越好
a. 过多的启动和初始化Reduce也会消耗时间和资源；
b. 另外，有多少个Reduce，就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题；
在设置Reduce个数的时候也需要考虑这两个原则：处理大数据量利用合适的Reduce数；使单个Reduce任务处理数据量大小要合适；
- 常用参数
// 输出合并小文件
SET hive.merge.mapfiles = true; -- 默认true，在map-only任务结束时合并小文件
SET hive.merge.mapredfiles = true; -- 默认false，在map-reduce任务结束时合并小文件
SET hive.merge.size.per.task = 268435456; -- 默认256M
SET hive.merge.smallfiles.avgsize = 16777216; -- 当输出文件的平均大小小于该值时，启动一个独立的map-reduce任务进行文件merge
原网址：https://blog.csdn.net/liyaohhh/article/details/50697519
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相对来讲是比较小的。我们看看会发生什么，如图所示：
注意看啦，这里的第一句话就是运行本地的map join任务，继而转存文件到XXX.hashtable下面，在给这个文件里面上传一个文件进行map join，之后才运行了MR代码去运行计数任务。
说白了，在本质上map join根本就没有运行MR进程，仅仅是在内存就进行了两个表的联合。具体运行如下图：
第二：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;
create table emp_info_bucket(ename string,deptno int)
partitioned by (empno string)
clustered by(deptno) into 4 buckets;
insert overwrite table emp_info_bucket
partition (empno=7369)
select ename ,deptno from emp
create table dept_info_bucket(deptno string,dname string,loc string)
clustered by (deptno) into 4 buckets;
insert overwrite table dept_info_bucket
select * from dept;
select * from emp_info_bucket emp join dept_info_bucket dept
on(emp.deptno==dept.deptno);//正常的情况下，应该是启动smbjoin的但是这里的数据量太小啦，还是启动了mapjoin
