mapred.min.split.size: 指的是数据的最小分割单元大小；min的默认值是1B
mapred.max.split.size: 指的是数据的最大分割单元大小；max的默认值是256MB
通过调整max可以起到调整map数的作用，减小max可以增加map数，增大max可以减少map数。
需要提醒的是，直接调整mapred.map.tasks这个参数是没有效果的。

假设一个SQL任务：
Select count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04';
该任务的inputdir : /group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04
共有194个文件，其中很多是远远小于128M的小文件，总大小9G，正常执行会用194个map任务。
Map总共消耗的计算资源：SLOTS_MILLIS_MAPS= 623,020
通过以下方法来在map执行前合并小文件，减少map数：
set mapred.max.split.size=100000000;(约95M)
set mapred.min.split.size.per.node=100000000;(约95M)
set mapred.min.split.size.per.rack=100000000;(约95M)
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
再执行上面的语句，用了74个map任务，map消耗的计算资源：SLOTS_MILLIS_MAPS= 333,500
对于这个简单SQL任务，执行时间上可能差不多，但节省了一半的计算资源。
大概解释一下，100000000表示100M,
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;这个参数表示执行前进行小文件合并，
前面三个参数确定合并文件块的大小，大于文件块大小128m的，按照128m来分隔，
小于128m,大于100m的，按照100m来分隔，把那些小于100m的（包括小文件和分隔大文件剩下的），
进行合并,最终生成了74个块。

如何适当的增加map数？
当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，可以考虑增加Map数，
来使得每个map处理的数据量减少，从而提高任务的执行效率。

假设有这样一个任务：
Ｓｅｌｅｃｔ　ｄａｔａ＿ｄｅｓｃ，　ｃｏｕｎｔ（１），　ｃｏｕｎｔ（ｄｉｓｔｉｎｃｔ　ｉｄ），　ｓｕｍ（ｃａｓｅ　ｗｈｅｎ　．．．），　ｓｕｍ（ｃａｓｅ　ｗｈｅｎ　．．．），　ｓｕｍ（．．．）　ｆｒｏｍ　ａ　ｇｒｏｕｐ　ｂｙ　ｄａｔａ＿ｄｅｓｃ

如果表a只有一个文件，大小为120M，但包含几千万的记录，如果用1个map去完成这个任务，肯定是比较耗时的， 这种情况下，我们要考虑将这一个文件合理的拆分成多个， 这样就可以用多个map任务去完成。 set mapred.reduce.tasks=10; create table a_1 as select * from a distribute by rand(123); 这样会将a表的记录，随机的分散到包含10个文件的a_1表中，再用a_1代替上面sql中的a表，则会用10个map任务去完成。 每个map任务处理大于12M（几百万记录）的数据，效率肯定会好很多。

如：select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt; 
            /group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04 总大小为9G多，
  因此这句有10个reduce

2. 调整reduce个数方法一：

调整hive.exec.reducers.bytes.per.reducer参数的值；

set hive.exec.reducers.bytes.per.reducer=500000000; （500M）

select pt, count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’ group by pt;

这次有20个reduce

3. 调整reduce个数方法二：

set mapred.reduce.tasks=15;

select pt,count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’ group by pt;

这次有15个reduce

4. reduce个数并不是越多越好；

同map一样，启动和初始化reduce也会消耗时间和资源；

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

5. 什么情况下只有一个reduce；

很多时候你会发现任务中不管数据量多大，不管你有没有调整reduce个数的参数，任务中一直都只有一个reduce任务；其实只有一个reduce任务的情况，除了数据量小于hive.exec.reducers.bytes.per.reducer参数值的情况外，还有以下原因：

• 没有group by的汇总，比如把select pt,count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’ group by pt; 写成select count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’; 这点非常常见，希望大家尽量改写。
• 用了Order by
• 有笛卡尔积。

注意：在设置reduce个数的时候也需要考虑这两个原则：使大数据量利用合适的reduce数；是单个reduce任务处理合适的数据量；

3.4 小文件合并优化

我们知道文件数目小，容易在文件存储端造成瓶颈，给HDFS带来压力，影响处理效率。对此，可以通过合并Map和Reduce的结果文件来消除这样的影响。

用于设置合并的参数有：

• • 是否合并Map输出文件：hive.merge.mapfiles=true（默认值为true）
  • 是否合并Reduce端输出文件：hive.merge.mapredfiles=false（默认值为false）
  • 合并文件的大小：hive.merge.size.per.task=256*1000*1000（默认值为256000000）

3.4.1 Hive优化之小文件问题及其解决方案：

小文件是如何产生的：

• • 动态分区插入数据，产生大量的小文件，从而导致map数量剧增；
  • reduce数量越多，小文件也越多（reduce的个数和输出文件是对应的）；
  • 数据源本身就包含大量的小文件。

小文件问题的影响：

• • 从Hive的角度看，小文件会开很多map，一个map开一个JVM去执行，所以这些任务的初始化，启动，执行会浪费大量的资源，严重影响性能。
  • 在HDFS中，每个小文件对象约占150byte，如果小文件过多会占用大量内存。这样NameNode内存容量严重制约了集群的扩展。

小文件问题的解决方案：

从小文件产生的途径就可以从源头上控制小文件数量，方法如下：

• • 使用Sequencefile作为表存储格式，不要用textfile，在一定程度上可以减少小文件；
  • 减少reduce的数量（可以使用参数进行控制）；
  • 少用动态分区，用时记得按distribute by分区；

对于已有的小文件，我们可以通过以下几种方案解决：

• • 使用hadoop archive命令把小文件进行归档；
  • 重建表，建表时减少reduce数量；
  • 通过参数进行调节，设置map/reduce端的相关参数，如下：

//每个Map最大输入大小(这个值决定了合并后文件的数量)  
set mapred.max.split.size=256000000;    
//一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并)  
set mapred.min.split.size.per.node=100000000;  
//一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并)    
set mapred.min.split.size.per.rack=100000000;  
//执行Map前进行小文件合并  
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;   

设置map输出和reduce输出进行合并的相关参数：
[java] view plain copy
//设置map端输出进行合并，默认为true  
set hive.merge.mapfiles = true  
//设置reduce端输出进行合并，默认为false  
set hive.merge.mapredfiles = true  
//设置合并文件的大小  
set hive.merge.size.per.task = 256*1000*1000  
//当输出文件的平均大小小于该值时，启动一个独立的MapReduce任务进行文件merge。  
set hive.merge.smallfiles.avgsize=16000000 

3.5 SQL优化

3.5.1 列裁剪

Hive在读数据的时候，可以只读取查询中所需要用到的列，而忽略其他列。例如，若有以下查询：

SELECT a,b FROM q WHERE e<10;

在实施此项查询中，Q表有5列（a，b，c，d，e），Hive只读取查询逻辑中真实需要的3列a、b、e， 而忽略列c，d；这样做节省了读取开销，中间表存储开销和数据整合开销。

裁剪对应的参数项为：hive.optimize.cp=true（默认值为真）

3.5.2 分区裁剪

可以在查询的过程中减少不必要的分区。例如，若有以下查询：

ＳＥＬＥＣＴ　* FROM (ＳＥＬＥＣＴ　a1, COUNT(1) FROM T GROUP BY a1) subq WHERE subq.prtn=100; # （多余分区）
ＳＥＬＥＣＴ　* FROM T1 JOIN (ＳＥＬＥＣＴ　* FROM T2) subq ON (T1.a1=subq.a2) WHERE subq.prtn=100;

查询语句若将”subq.prtn=100″条件放入子查询中更为高效，可以减少读入的分区数目。Hive自动执行这种裁剪优化。

分区参数为：hive.optimize.pruner=true（默认值为真）

3.5.3 熟练使用SQL提高查询

熟练地使用SQL，能写出高效率的查询语句。

场景：有一张user表，卖家每天收到表，user_id，ds（日期）为key，属性有主营类目，指标有交易金额，交易笔数。每天要取前10天的总收入，总笔数，和最近一天的主营类目。

解决方法 1 如下所示：常用方法

INSERT OVERWRITE TABLE t1
SELECT user_id, substr(MAX(CONCAT(ds,cat),9) AS main_cat) FROM users
WHERE ds=20120329 // 20120329 为日期列的值，实际代码中可以用函数表示当天日期GROUP BY user_id;

INSERT OVERWRITE TABLE t2
SELECT user_id,sum(qty) AS qty, SUM(amt) AS amt FROM users
WHERE ds BETWEEN 20120301 AND 20120329
GROUP BY user_id;

SELECT t1.user_id, t1.main_cat, t2.qty, t2.amt FROM t1
JOIN t2 ON t1.user_id=t2.user_id

下面给出方法1的思路，实现步骤如下：

第一步：利用分析函数，取每个user_id最近一天的主营类目，存入临时表t1；

第二步：汇总10天的总交易金额，交易笔数，存入临时表t2；

第三步：关联t1、t2，得到最终的结果。

解决方法 2 如下所示：优化方法

SELECT user_id, substr(MAX(CONCAT(ds, cat)), 9) AS main_cat, SUM(qty), SUM(amt) FROM users
WHERE ds BETWEEN 20120301 AND 20120329
GROUP BY user_id

在工作中我们总结出：方案2的开销等于方案1的第二步开销，性能提升，由原有的25分钟完成，缩短为10分钟以内完成。节省了两个临时表的读写是一个关键原因，这种方式也适用于Oracle中的数据查找工作。

SQL具有普适性，很多SQL通用的优化方案在Hadoop分布式计算方式中也可以达到效果。

3.5.5 不同数据类型关联产生的倾斜问题

问题：不同数据类型id的关联会产生数据倾斜问题。

一张表的s8的日志，每个商品一条记录，要和商品表关联。但关联却碰到倾斜的问题。s8的日志中有32位字符串商品id，也有数值商品id，日志中类型是string的，但商品中的数值id是bigint的。猜想问题的原因是把s8的商品id转成数值id做hash来分配Reduce，所以字符串id的s8日志，都到一个Reduce上了，解决的方法验证了这个猜测。

解决方法：把数据类型转换成字符串类型

SELECT * FROM s8_log a LEFT OUTER
JOIN r_auction_auctions b ON a.auction_id=CAST(b.auction_id AS STRING)

调优结果显示：数据表处理由1小时30分钟经代码调整后可以在20分钟内完成。

3.5.6 利用Hive对UNION ALL优化的特性

多表union all会优化成一个job。

问题：比如推广效果表要和商品表关联，效果表中的auction_id列既有32位字符串商品id，也有数字id，和商品表关联得到商品的信息。

解决方法：Hive SQL性能会比较好

SELECT * FROM effect a
JOIN
(SELECT auction_id AS auction_id FROM auctions
UNION ALL
SELECT auction_string_id AS auction_id FROM auctions) b
ON a.auction_id=b.auction_id

比分别过滤数字id，字符串id然后分别和商品表关联性能要好。

这样写的好处：1个MapReduce作业，商品表只读一次，推广效果表只读取一次。把这个SQL换成Map/Reduce代码的话，Map的时候，把a表的记录打上标签a，商品表记录每读取一条，打上标签b，变成两个<key, value>对，<(b，数字id)，value>，<(b，字符串id)，value>。

所以商品表的HDFS读取只会是一次。

3.5.7 解决Hive对UNION ALL优化的短板

Hive对union all的优化的特性：对union all优化只局限于非嵌套查询

• 消灭子查询内的group by

示例1：子查询内有group by

ＳＥＬＥＣＴ　* FROM
(ＳＥＬＥＣＴ　* FROM t1 GROUP BY c1,c2,c3 UNION ALL ＳＥＬＥＣＴ　* FROM t2 GROUP BY c1,c2,c3) t3
GROUP BY c1,c2,c3

ＳＥＬＥＣＴ　* FROM (ＳＥＬＥＣＴ　* FROM t1 UNION ALL ＳＥＬＥＣＴ　* FROM t2) t3 GROUP BY c1,c2,c3

• 消灭子查询内的COUNT(DISTINCT)，MAX，MIN

ＳＥＬＥＣＴ　* FROM 
(ＳＥＬＥＣＴ　* FROM t1
UNION ALL ＳＥＬＥＣＴ　c1,c2,c3 count(DISTINCT c4) FROM t2 GROUP BY c1,c2,c3) t3
GROUP BY c1,c2,c3

由于子查询里头有COUNT(DISTINCT)操作，直接去GROUP BY将达不到业务目标。这时采用临时表消灭COUNT(DISTINCT)作业不但能解决倾斜问题，还能有效减少jobs。

INSERT t4 SELECT c1,c2,c3,c4 FROM t2 GROUP BY c1,c2,c3;
SELECT c1,c2,c3,SUM(income),SUM(uv) FROM
(SELECT c1,c2,c3,income,0 AS uv FROM t1
UNION ALL
SELECT c1,c2,c3,0 AS income, 1 AS uv FROM t2) t3
GROUP BY c1,c2,c3;

job数是2，减少一半，而且两次Map/Reduce比COUNT(DISTINCT)效率更高。

调优结果：千万级别的类目表，member表，与10亿级的商品表关联。原先1963s的任务经过调整，1152s即完成。

• 消灭子查询内的JOIN

ＳＥＬＥＣＴ　* FROM
(ＳＥＬＥＣＴ　* FROM t1 UNION ALL ＳＥＬＥＣＴ　* FROM t4 UNION ALL ＳＥＬＥＣＴ　* FROM t2 JOIN t3 ON t2.id=t3.id) x
GROUP BY c1,c2;

上面代码运行会有5个jobs。加入先JOIN生存临时表的话t5，然后UNION ALL，会变成2个jobs。

INSERT OVERWRITE TABLE t5
ＳＥＬＥＣＴ　* FROM t2 JOIN t3 ON t2.id=t3.id;
ＳＥＬＥＣＴ　* FROM (t1 UNION ALL t4 UNION ALL t5);

调优结果显示：针对千万级别的广告位表，由原先5个Job共15分钟，分解为2个job，一个8-10分钟，一个3分钟。

3.5.8 COUNT(DISTINCT)

计算uv的时候，经常会用到COUNT(DISTINCT)，但在数据比较倾斜的时候COUNT(DISTINCT)会比较慢。这时可以尝试用GROUP BY改写代码计算uv。数据量小的时候无所谓，数据量大的情况下，由于COUNT DISTINCT操作需要用一个Reduce Task来完成，这一个Reduce需要处理的数据量太大，就会导致整个Job很难完成，一般COUNT DISTINCT使用先GROUP BY再COUNT的方式替换：

• 原有代码

①
INSERT OVERWRITE TABLE s_dw_tanx_adzone_uv PARTITION (ds=20120329) 
SELECT 20120329 AS thedate,adzoneid,COUNT(DISTINCT acookie) AS uv FROM s_ods_log_tanx_pv t WHERE t.ds=20120329 GROUP BY adzoneid;

②
select count(distinct id) from bigtable;

关于COUNT(DISTINCT)的数据倾斜问题不能一概而论，要依情况而定，下面是我测试的一组数据：

测试数据：169857条

①
#统计每日IP
CREATE TABLE ip_2014_12_29 AS ＳＥＬＥＣＴ　COUNT(DISTINCT ip) AS FROM logdfs WHERE logdate='2014_12_29';
耗时：24.805 seconds
#统计每日IP(改造)
CREATE TABLE ip_2014_12_29 AS ＳＥＬＥＣＴ　COUNT(1) AS IP FROM (ＳＥＬＥＣＴ　DISTINCT ip from logdfs WHERE logdate='2014_12_29') tmp;
耗时：46.833 seconds

②
 ＳＥＬＥＣＴ　count(id) from (ＳＥＬＥＣＴ　id from bigtable group by id) a;

测试结果表明：明显改造后的语句比之前耗时，这时因为改造后的语句有2个SELECT，多了一个job，这样在数据量小的时候，数据不会存在倾斜问题。

3.5.9 JOIN操作

3.5.9.1 小表、大表JOIN

在使用写有Join操作的查询语句时有一条原则：应该将条目少的表/子查询放在Join操作符的左边。原因是在Join操作的Reduce阶段，位于Join操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生OOM错误的几率；再进一步，可以使用Group让小的维度表（1000条以下的记录条数）先进内存。在map端完成reduce。

实际测试发现：新版的hive已经对小表JOIN大表和大表JOIN小表进行了优化。小表放在左边和右边已经没有明显区别。

案例实操：

（1）关闭mapjoin功能（默认是打开的）

set hive.auto.convert.join=false;

（2）执行小表JOIN大表语句

insert overwrite table jointable
select b.id, b.time, b.uid, b.keyword, b.url_rank, b.click_num, b.click_url
from smalltable s
left join bigtable  b
on b.id = s.id;

Time taken: 35.921 seconds

（3）执行大表JOIN大表语句

insert overwrite table jointable
select b.id, b.time, b.uid, b.keyword, b.url_rank, b.click_num, b.click_url
from bigtable  b
left join smalltable  s
on s.id = b.id;

Time taken: 34.196 seconds；