本文共 3143 字，大约阅读时间需要 10 分钟。

作业优化总结

 

 

目录

Hive作业优化总结... 1

一、Hadoop 计算框架的特性... 1

二、优化常用的手段... 2

三、优化案例... 2

1、Join原则... 2

2、笛卡尔积... 2

3、控制Map数... 3

4、设置合理reducer个数... 3

5、合并MapReduce操作... 4

6 、LEFT SEMI  JOIN.. 4

7、Hive注意事项... 4

 

 

 

 

计算框架的特性

1、什么是数据倾斜？

•由于数据分布不均匀，造成数据大量的集中到一点，造成数据热点。

 

2、Hadoop框架的特性

•不怕数据大，怕数据倾斜。

•jobs数比较多的作业运行效率相对比较低，如子查询比较多。

•sum,count,max,min等聚集函数，不会有数据倾斜问题

3、容易数据倾斜情况

·group by

·count(distinct ),在数据量大的情况下，容易数据倾斜，因为count(distinct)是按group by 字段分组，按distinct字段排序。

·小表关联超大表

 

•   数据倾斜的时候进行负载均衡

hive.groupby.skewindata=true

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

 

•解决数据倾斜问题

•减少job数（合并MapReduce，用Multi-group by）

•设置合理的mapreduce的task数，能有效提升性能。

•数据量较大的情况下，慎用count(distinct)。

•对小文件进行合并，针对文件数据源。

 

、Join原则

将条目少的表/子查询放在 Join的左边。 原因是在 Join 操作的 Reduce 阶段，位于 Join左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生内存溢出的几率。

 

当一个小表关联一个超大表时，容易发生数据倾斜，可以用MapJoin把小表全部加载到内存在map端进行join，避免reducer处理。

         如：SELECT /*+ MAPJOIN(user)*/  l.session_id, u.username from user u join page_views lon (u. id=l.user_id) ;

 

、笛卡尔积

         当Hive设定为严格模式（hive.mapred.mode=strict）时，不允许在HQL语句中出现笛卡尔积。

         当无法躲避笛卡尔积时，采用MapJoin，会在Map端完成Join操作，将Join操作的一个或多个表完全读入内存。

MapJoin的用法是在查询/子查询的SELECT关键字后面添加/*+MAPJOIN(tablelist) */提示优化器转化为MapJoin 。

其中tablelist可以是一个表，或以逗号连接的表的列表。tablelist中的表将会读入内存，应该将小表写在这里

、控制Map数

同时可执行的map数是有限的。

•通常情况下，作业会通过input的目录产生一个或者多个map任务

•主要的决定因素有： input的文件总个数，input的文件大小。

 

•举例

   a) 假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块（block为128M,6个128m的块和1个12m的块），从而产生7个map数

b) 假设input目录下有3个文件a,b,c,大小分别为10m，20m，130m，那么hadoop会分隔成4个块（10m,20m,128m,2m）,从而产生4个map数

 

 

两种方式控制Map数：即减少map数和增加map数

减少map数可以通过合并小文件来实现，这点是对文件数据源来讲。

增加map数的可以通过控制上一个job的reduer数来控制，见5.

 

、设置合理reducer个数

•reducer个数的设定极大影响执行效率

•不指定reducer个数的情况下，Hive分配reducer个数基于以下：

    参数1：hive.exec.reducers.bytes.per.reducer（默认为1G)

    参数2 ：hive.exec.reducers.max（默认为999）

•计算reducer数的公式

•N=min(参数2，总输入数据量/参数1)

set mapred.reduce.tasks=13;

 

•reduce个数并不是越多越好

同map一样，启动和初始化reduce也会消耗时间和资源；有多少个reduce,就会有多少个输出文件。

 

Reducer数过多：

生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题。

 

Reducer过少：

         影响执行效率。

 

•什么情况下只有一个reduce

    很多时候你会发现任务中不管数据量多大，不管你有没有设置调整reduce个数的参数，任务中一直都只有一个reduce任务；

1、  除了数据量小于hive.exec.reducers.bytes.per.reducer参数值的情况外

2、没有group by的汇总

3、用了Order by。

 

 

、合并MapReduce操作

• Multi-group by：当从同一个源表进行多次查询时用。

 

•Multi-group by是Hive的一个非常好的特性，它使得Hive中利用中间结果变得非常方便

•FROM log

•  insert overwrite table test1select log.id group by log.id

•  insert overwrite table test2select log.name group by log.name

•上述查询语句使用了Multi-group by特性连续group by了2次数据，使用不同的group by key。这一特性可以减少一次MapReduce操作。

 

 

 

、LEFT SEMI  JOIN

是 IN/EXISTS 子查询的一种更高效的实现。

Hive 当前没有实现 IN/EXISTS 子查询，所以你可以用 LEFT SEMI JOIN 重写你的子查询语句。LEFT SEMI JOIN 的限制是， JOIN 子句中右边的表只能在 ON 子句中设置过滤条件，在 WHERE 子句、SELECT 子句或其他地方过滤都不行。

  SELECT a.key,a.value

  FROM a

  WHERE a.key in

   (SELECTb.key

    FROM B);

可以被重写为：

   SELECT a.key, a.val

   FROM a LEFT SEMIJOIN b on (a.key = b.key)

 

、Hive注意事项

只支持INSERT/LOAD操作，无UPDATE和DELTE

0.10之前版本没有索引

不支持HAVING操作。

不支持where子句中的子查询

Join只支持等值关联

Not用法

关系数据库：

… where username not like（in） ..

 

Hive

… where not username like（in）..

 

Hive中string类型没有长度限制

转载地址：http://lkemb.baihongyu.com/