Hive查询性能优化

使用JOIN特性优化

性能由低到高依次为
Reduce端的JOIN < Map端的JOIN < Map端分桶表的JOIN < SMB

• Reduce端JOIN需要Shuffle过程
• Map端JOIN，适用于一个大表和一个小表的JOIN，小表数据放入内存。大表去内存中查找与之匹配的小表数据，进行连接。
  要求内存足够覆盖小表数据，需要设置以下参数。

set hive.auto.convert.join=true;
Set hive.mapjoin.smalltable.filesize = 25M

• Map端分桶表之间也可以JOIN，要求两个表的桶数量一致，或者是整数倍。两个分桶表未排序的话，需要有足够强大的内存支持

关联字段存在大量空值null的情况，必须先用子查询过滤null key，再执行join

• SMB，即Sort Merge Bucket Map Join 。分桶表内的数据已经排序，可以开启SMB。提高查询性能。需要开启以下参数。

hive> SET hive.auto.convert.sortmerge.join=true; 
SET hive.optimize.bucketmapjoin=true;
SET hive.optimize.bucketmapjoin.sortedmerge=true;

• 尽量缩减表的数据范围
  ① select m.cid,u.id form order m join customer u on m.cid=u.id where m.dt=’20160801’;
  ② select m.cid,u.id from (select cid from order where dt=’20160801’)m join customer u on m.cid = u.id
  实践发现：①的执行效率不如②高

IO优化

• 使用分区表、分桶表增加目录、文件数量。进而减少数据读取数量
• 使用列式存储，列式存储可以压缩数据
• 调整文件切片数量，一个文件切片对应一个MapTask，进而增加
  MapTask并发度
• 建议一个文件100M左右

单位字节（128MB)
hive> set mapred.max.split.size=134217728

JVM重利用

• 客户端程序提交一个Job任务给JobTracker，JobTracker校验任务信息通过，分配一个JobId给客户端程序；
• 客户端提交jar可执行程序给HDFS；
• JobTracker将任务分解为MapTask 和 ReduceTask。等待TaskTracker的心跳
• JobTracker接收到心跳信息，按照数据本地化策略，将MapTask分配到对应的TaskTracker节点上，ReduceTask分配到空闲节点上
• TaskTracker根据NameNode的元数据，从DataNode上下载jar包，启动JVM进程去执行MapTask，执行结束，关闭JVM进程。再启动一个新的JVM进程去执行新的MapTask。
  这个地方，在hive中可以通过命令：
  set mapred.job.reuse.jvm.num.tasks=20
  设置TaskTracker处理了20个任务后，关闭JVM进程

---

关闭推测执行机制

---

推测执行机制：假设有大小不一的任务在处理，小任务能很快的处理完。大任务也称慢任务，执行时间比较长。此时可以把这个慢任务重新分配给一个节点来执行，哪个节点执行完成，就采用哪个节点的处理结果，同时kill相同任务的进程。
关闭推测执行机制：存在数据倾斜的任务，建议关闭推测执行机制，因为再开一个节点处理，也不能解决慢任务的问题；
Hive中关闭推测执行的命令：

set mapreduce.map.speculative=false
set mapreduce.reduce.speculative=false
set hive.mapred.reduce.tasks.speculative.execution=false

使用groupBy特性解决数据倾斜

hive中有命令可以解决数据倾斜

hive> set hive.map.aggr=true;
set hive.groupby.skewindata=true;

set hive.map.aggr=true;表示开启map端聚合
set hive.groupby.skewindata=true;表示groupby支持数据倾斜

• 生成的查询计划会有两个MR Job。
• 第一个MR Job中，Map的输出结果会随机分发到Reduce中，每个Reduce做部分聚合操作，并输出结果。这样处理的结果是相同的Group By Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的。
• 第二个MR Job再根据预处理的数据结果按照Group By Key分布到reduce中，这个过程可以保证相同的key被分到同一个reduce中，最后完成最终的聚合操作。