场景一 .去重场景问题
1) UNION -- UNION ALL 之间的区别，如何取舍：UNION 会多出一个Reduce 流程。这也不难理，为什么在无去重需求下，使用 UNION ALL 而不是 UNION
2) DISTINCT 替代方式 GROUP BY：
优化原理：
我们先说下为什么大数据集下 先 GROUP BY 再COUNT 的效率 要优于 直接 COUNT(DISTINCT ...) .
因为 COUNT(DISTINCT ...) , 会把相关的列组成一个key 传入到 Reducer 中。即 count(DISTINCT KEY._col0:0._col0, KEY._col0:0._col1, KEY._col0:0._col2) | 这样需要在 一个 Reducer 中 ，完成全排序并去重。
先GROUP BY 再去 COUNT ，则GROUP BY 可以 将不同的KEY , 分发到多个 Reducer 中，在 GROUP BY流程中完成了去重。此时，去重时并不会把数据放入到 一个 Reducer 中，利用了分布式的优势。这个去重效率更高。在下一步 COUNT 阶段，再将上一步奏 GROUP BY 去重后的 KEY , 进行统计计算。
所以大数据量下 先GROUP BY ，再去 COUNT 效率比 COUNT(DISTINCT) 更高。
我们对比下上述的小数据量运行结果：
EXPLAIN 中 ：COUNT(DISTINCT ) 比 先GROUP BY 再 COUNT 的阶段少 。因为 GROUP BY 已经是一个 MR STAGE, 而 COUNT 是另一个 STAGE.
运行时间上 ：可以看到两者并无差别，甚至 COUNT(DISTINCT ) 总时间小于 先GROUP BY 再 COUNT。这是因为，运行一个 STAGE 需要申请资源，开辟资源，有时间成本。故小数据量下 ， 先GROUP BY 再 COUNT 时间多于 COUNT(DISTINCT ) , 主要是花费在 申请资源，创建容器的时间上。并且 总运行时间 COUNT(DISTINCT ) 小于 先GROUP BY 再 COUNT
产生上述结果的原因，还是因为数据集大小的问题。即 一个 Reducer 全局排序的时间成本，与划分多个作业阶段申请资源的成本的比较 ！！！
场景二.减少JOB的数量
1) 巧妙的使用 UNION ALL 减少 JOB 数量：
低效写法：SELECT
'a' AS type
,COUNT(1) AS num
FROM datacube_salary_basic_aggr AS a
UNION ALL
SELECT
'b' AS type
,COUNT(1) AS num
FROM datacube_salary_company_aggr AS b
高效写法：
SELECT
type
,COUNT(1)
FROM
(
SELECT
'a' AS type
,total_salary
FROM datacube_salary_basic_aggr AS a
UNION ALL
SELECT
'b' AS type
,total_salary
FROM datacube_salary_company_aggr AS b
) AS tmp
GROUP BY
type
这里为什么比上面的写法划分的阶段数量更少呢 ？因为我们先把所有数据UNION ALL了之后，再去做的统计，相当于多个表的数据利用 type 作为区分，一次扫描了进来，所以效率更高。但是相应的这个STAGE 阶段需要的Mapper 数量也更多，毕竟我们是一下扫描 的4张表的数据 。
2) 利用多表相同的JOIN 关联条件字段，去减少 JOB 的数量
场景三：合理控制并发
开启任务并行执行： set hive.exec.parallel=true;
允许并行任务的最大线程数： set hive.exec.parallel.thread.number=8;
场景四：控制mapper和reducer端个数及mapreduce输出文件大小
mapper：
（1）如果想增加map个数，则设置mapred.map.tasks 为一个较大的值。
（2）如果想减小map个数，则设置mapred.min.split.size 为一个较大的值。
（3）如果输入中有很多小文件，依然想减少map个数，则需要将小文件merge 为大文件，然后使用准则2。
reducer：
每个Reduce处理的数据量：set hive.exec.reducers.bytes.per.reducer=500000000;
500,000,000 ~= 500M;
指定Reduce数量：set mapred.reduce.tasks=20;
mapreduce输出文件大小：
在Map-only的任务结束时,合并小文件
set hive.merge.mapfiles=true
在Map-Reduce的任务结束时合并小文件
set hive.merge.mapredfiles=true
合并文件的大小
set hive.merge.size.per.task=256000000;
256,000,000 ~= 256M;
输出文件的平均大小小于该值时,启动一个独立的map-reduce任务进行文件合并
set hive.merge.smallfiles.avgsize=16000000;
16,000,000 ~= 16M;
场景5：排序问题
1) 合理使用 ORDER BY 与 SORT BY , 在两者之间做取舍
应该尽量避免使用 ORDER BY ，ORDER BY 会在全局进行排序。会单独增加一个作业，在全局进行排序。并且在排序中，数据会被分放在一个Reducer 中。SORT BY 只是在每一个 reducer 中，进行局部的排序。
2) 通过使用 LIMIT 限制排序的输出
通过 使用SORT BY + LMIT N , 我们只需要每个 Reduce 控制前N 条记录即可。然后我们在总的 M个 Reduce 中再去选取其中的 前N 个数据就可以找到前 N 排名的数据了。
Tips
1) 使用 SORT BY + LIMIT N 的方式会比 ORDER BY 多一个JOB。所以，在使用 SORT BY + LIMIT 的方式，我们也要注意数据量的规模
2) 据说每个Reduce 取前N 条记录，使用的是冒泡排序。
场景六：通过让MAP 端, 多去承担任务， 去减少 Reducer 的计算成本 和 数据传输成本
1、例子中的小表参与join，没使用map join时，会导致数据倾斜严重。某个reduce上落太多数据，reduce时内存会严重占用，甚至不足。
2、不等连接时，reduce会进行笛卡儿积，效率很低。
3、使用mapjoin时还要注意，用作join的关联字段的字段类型最好要一致。
使用map join后 join操作会在map阶段完成。
2) MAP AGGR , 在 Map 端进行预聚合
我们在做 GROUP BY , DISTINCT 这些都是可以在 Map 端进行预聚合的，
Map端聚合设置的参数
set hive.map.aggr=true;
