hive企业级调优概述

---

1.Fetch抓取

2.本地模式

3.表的优化

• 1.小表、大表Join（新版的hive已经做了优化，两者的先后顺序已经没有明显区别）
• 2.大表Join大表
  • 空KEY过滤
  • 空KEY转换
• 3.MapJoin
• 4.Group By
  • 默认情况下，Map阶段的同一Key数据会分发给一个reduce，当一个key数据过大时就倾斜了，并不是所有的聚合操作都需要在reduce端完成，可以先在Map端进行部分聚合，最后在reduce端得到最终结果。进行了相关的配置后，生成的查询计划会有两个MR Job。
  • 第一个MR Job中，Map的输出结果会随机分布到Reduce中，每个Reduce做部分聚合后，输出结果。这样相同的Key可能会被分发到不同的Reduce中（我感觉这里应该是map端做部分聚合），从而达到负载均衡的效果；
  • 第二个MR Job在根据预处理的数据结果分布到Reduce中（这个过程可以保证相同的Key被分发到一个Reduce中），完成最终的聚合操作。
• 5.不用Count(Distinct)
  • select count(id) from (select id from bigtable group by id) a
• 6.避免笛卡尔积
• 7.行列过滤
• 8.动态分区调整
• 9.分桶（对数据文件）
• 10.分区（对数据的存储路径）

4.数据倾斜

• 1.合理设置Map数
  • 通常情况下，作业会通过input的目录产生一个或者多个map任务（input的文件总个数、input的文件大小、集群设置的文件块的大小）
  • map数过多（如果一个任务有很多小文件（远远小于块大小128M），则每个小文件都会被当成一个块处理，用一个map任务来完成，但会存在两个问题：map task启动和初始化需要时间；同时可执行的map数也是受限的）：可以在map执行前合并小文件，减少map数
  • 每个map处理接近128M的文件块：可以增加map数，方法是减少每个map处理的数据量
• 2.合理设置Reduce数
  • 设置方法有两种
  • reduce数过多：reduce的启动和初始化也需要时间和资源；有多少个reduce就对应多少个输出文件，如果生成了很多个小文件，他们作为下一个任务的输入，也会出现小文件过多的问题。

5.并行执行

• hive会将一个查询转化成一个或者多个阶段，这样的阶段可以是MR阶段、抽样阶段、合并阶段、limit阶段、其他阶段。默认情况下hive一次只能执行一个阶段，不过这些阶段可能不是相互依赖的就可以并行执行。

6.严格模式

• 可以禁止3中类型的查询
  • 1.对于分区表，除非where语句中包含分区字段，否则不运行执行
  • 2.order by 全局排序必须与limit搭配使用
  • 3.限制笛卡尔积的查询

7.JVM的重用（慎用）

8.推测执行（慎用）

9.压缩

10.执行计划

• explain select * from emp；–查看语句的执行计划
• explain extended select * from emp; --查看语句详细的执行计划

详细内容可以看这里