hive简单查询优化总结

          hive作为hadoop系列的计算模型,在公司的数据清洗和报表开发广泛使用,合理的优化自己的语句结构可以节省计算时间,优化集群的计算资源,下面总结下日常工作中自己碰到的一些问题和别人总结的一些方法。

我们先了解下关系型数据库sql的执行顺序,hive大致相同

然后大致了解下hive的架构:

具体策略:

1、尽早的过滤数据,hive同样会先执行join,再执行where,分区表要加分区,同时只选择需要使用到的字段(尤其是大表)

2、order by全局排序会集中到一个reducer上执行,对于大数据集效率会极低,如果没有实际需求,避免使用

      同时,一般会设置  hive.mapred.mode=nonstrict,这时候使用order by必须加limit关键字

  order by默认顺序是升序(asc)。在Hive 2.1.0及以上版本,支持对null值进行排序,升序排序是null值被排在第一位,降序时null值被排在最后。

3、避免使用count(distinct)操作, 解决方法:先使用group by去重,再count计算。

4、join时小表放在左边,大表放在右边,hive会将小表放进内存。两张数据量相差特别大的表进行join操作时,如果小表特别小(比如几百几千条记录),使用mapjoin。在hive0.7版本后,也能够用配置来自己主动优化   set hive.auto.convert.join=true;

     数仓设计时销售数据大多数会用星型模型,即事实表和维度表相关联,这种问题比较常见

5、如果union all的部分个数大于2,或者每个union部分数据量大,应该拆成多个insert into 语句,实际测试过程中,执行时间能提升50%(实际没碰到过,真实度待定)

6、hive支持in的子查询写法,尽量用left semi join代替

7、多表join时使用相同的连接键

当对3个或者更多个表进行join连接时,如果每个on子句都使用相同的连接键的话,那么只会产生一个MapReduce job。

8、对于事实表,有分区的一定要加分区

 对于join和Group操作都可能会出现数据倾斜。

        以下有几种解决这个问题的常见思路

      1、参数hive.groupby.skewindata = true,解决数据倾斜的万能钥匙,查询计划会有两个 MR Job。第一个 MR Job 中,Map 的输出结果集合会随机分布到 Reduce 中,每个 Reduce 做部分聚合操作,并输出结果,这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中,从而达到负载均衡的目的;第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中(这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中),最后完成最终的聚合操作。

      2、where的条件写在join里面,使得减少join的数量(经过map端过滤,只输出复合条件的)

      3、mapjoin方式,无reduce操作,在map端做join操作(map端cache小表的全部数据),这种方式下无法执行Full/RIGHT OUTER join操作

      4、对于count(distinct)操作,在map端以group by的字段和count的字段联合作为key,如果有大量相同的key,那么会存在数据倾斜的问题
      5、数据的倾斜还包括,大量的join连接key为空的情况,空的key都hash到一个reduce上去了,解决这个问题,最好把空的key和非空的key做区分
         空的key不做join操作。

   当然有的hive操作,不存在数据倾斜的问题,比如数据聚合类的操作,像sum、count,因为已经在map端做了聚合操作了,到reduce端的数据相对少一些,所以不存在这个问题。

猜你喜欢

转载自blog.csdn.net/huobumingbai1234/article/details/83215164