Hive优化

1. MapJoin
   如果不指定MapJoin或者不符合MapJoin的条件，那么Hive解析器会将Join操作转换成Common Join，即在Reduce阶段完成join，容易发生数据倾斜。可以用MapJoin把小表（25M以下）加载到内存中在map端进行join，避免reducer处理。
   

2. 行列过滤
   列处理：在select中，只拿需要的列，如果有，尽量使用分区过滤，少用select *。
   行处理：在分区剪裁中，当使用外关联时，如果将副表的过滤条件写在where后面，那么就会先完全表关联，之后再过滤。可以通过子查询之后再关联表。

3. 列式存储
   列式存储有很高的压缩比.(因为同列数据,数据格式,重复率等相同几率很高,并且可以针对列相同的数据类型,采用更好的压缩方式)；优化查询效率(可以只查询某些需要的列而不用扫整个数据,降低IO)

4. 采用分区技术
   查询的时候直接根据分区查找数据，避免全局查询，调高查询效率。

5. 合理设置Map数
   mapred.min.split.size：指的是最小分割单元大小；min的默认值是1B
   mapred.max.split.size：指的是最大分割单元大小；max的默认值是256M
   通过调整max可以起到调整map数的作用，max与map数成反比。注：直接调整mapred.map.tasks这个参数是没有效果的。

6. 合理设置Reduce个数
   两个原则：处理大数据量利用合适的Reduce数；使单个Reduce任务处理数据量大小要合适。

   1. 过多的启动和初始化Reduce会消耗时间和资源
   2. 有多少个Reduce就会有多少个输出文件，可能会造成小文件过多。

7. 小文件
   产生原因：

   1. 动态分区插入数据导致小文件增多
   2. reduce数量多导致生成大量小文件
   3. 数据源本身就包含大量小文件

   解决方案：

   1. map前合并小文件
   2. 开启JVM重用
      set mapreduce.job.jvm.numtasks=10
   3. merge
      输出时合并小文件

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; -- 当输出文件的平均大小 小于 16m 该值时，启动一个独立的 map-reduce 任务进行文件 merge

8. 在不影响最终业务逻辑的前提下开启map端combiner
9. 压缩（选择快的）
   10.采用tez或者spark引擎