Hive性能优化

2019独角兽企业重金招聘Python工程师标准>>>

Hive设置参数的三种方法

Hive提供三种可以改变环境变量的方法，分别是：（1）、修改${HIVE_HOME}/conf/hive-site.xml配置文件；（2）、命令行参数；（3）、在已经进入cli时进行参数声明。下面分别来介绍这几种设定。

　　方法一：
　　在Hive中，所有的默认配置都在${HIVE_HOME}/conf/hive-default.xml文件中，如果需要对默认的配置进行修改，可以创建一个hive-site.xml文件，放在${HIVE_HOME}/conf目录下。里面可以对一些配置进行个性化设定。在hive-site.xml的格式如下：

1	<configuration>

2	<property>

3	<name>hive.metastore.warehouse.dir</name>

4	<value>/user/hive/warehouse</value>

5	<description>location of

6	default database for the warehouse</description>

7	</property>

8	</configuration>

　　所有的配置都是放在<configuration></configuration>标签之间，一个configuration标签里面可以存在多个<property></property>标签。<name>标签里面就是我们想要设定属性的名称；<value>标签里面是我们想要设定的值；<description;<标签是描述在这个属性的，可以不写。绝大多少配置都是在xml文件里面配置的，因为在这里做的配置都全局用户都生效，而且是永久的。用户自定义配置会覆盖默认配置。另外，Hive也会读入Hadoop的配置，因为Hive是作为Hadoop的客户端启动的，Hive的配置会覆盖Hadoop的配置。

　　方法二：
　　在启动Hive cli的时候进行配置，可以在命令行添加-hiveconf param=value来设定参数，例如：

1	[wyp@master ~]$ hive --hiveconf mapreduce.job.queuename=queue1

这样在Hive中所有MapReduce作业都提交到队列queue1中。这一设定对本次启动的会话有效，下次启动需要重新配置。

　　方法三：
　　在已经进入cli时进行参数声明，可以在HQL中使用SET关键字设定参数，例如：

1	hive> set mapreduce.job.queuename=queue1;

这样也能达到方法二的效果。这种配置也是对本次启动的会话有效，下次启动需要重新配置。在HQL中使用SET关键字还可以查看配置的值，如下：

1	hive> set mapreduce.job.queuename;

2	mapreduce.job.queuename=queue1

我们可以得到mapreduce.job.queuename=queue1。如果set后面什么都不添加，这样可以查到Hive的所有属性配置，如下：

01	hive> set;

02	datanucleus.autoCreateSchema=true

03	datanucleus.autoStartMechanismMode=checked

04	datanucleus.cache.level2=false

05	datanucleus.cache.level2.type=none

06	datanucleus.connectionPoolingType=DBCP

07	datanucleus.identifierFactory=datanucleus

08	datanucleus.plugin.pluginRegistryBundleCheck=LOG

09	datanucleus.storeManagerType=rdbms

10	datanucleus.transactionIsolation=read-committed

11	datanucleus.validateColumns=false

12	datanucleus.validateConstraints=false

13	datanucleus.validateTables=false

14

15	............................

　　上述三种设定方式的优先级依次递增。即参数声明覆盖命令行参数，命令行参数覆盖配置文件设定。

　　注意：某些系统级的参数，例如log4j相关的设定，必须用前两种方式设定，因为那些参数的读取在会话建立以前已经完成了。所以在HQL中设定是无效的。这个特列可以参见本博客《Hive日志调试》进行了解。

hive on spark参数配置样例

set hive.execution.engine=spark;
set spark.executor.memory=4g;
set spark.executor.cores=2;
set spark.executor.instances=40;
set spark.serializer=org.apache.spark.serializer.KryoSerializer;

 

1.介绍

首先，我们来看看Hadoop的计算框架特性，在此特性下会衍生哪些问题？

• 数据量大不是问题，数据倾斜是个问题。

• jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，耗时很长。原因是map reduce作业初始化的时间是比较长的。

• sum,count,max,min等UDAF，不怕数据倾斜问题,hadoop在map端的汇总合并优化，使数据倾斜不成问题。

• count(distinct ),在数据量大的情况下，效率较低，如果是多count(distinct )效率更低，因为count(distinct)是按group by 字段分组，按distinct字段排序，一般这种分布方式是很倾斜的。举个例子：比如男uv,女uv，像淘宝一天30亿的pv，如果按性别分组，分配2个reduce,每个reduce处理15亿数据。

面对这些问题，我们能有哪些有效的优化手段呢？下面列出一些在工作有效可行的优化手段：

• 好的模型设计事半功倍。

• 解决数据倾斜问题。

• 减少job数。

• 设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。

• 了解数据分布，自己动手解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化有时不能适应特定业务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效的解决数据倾斜问题。

• 数据量较大的情况下，慎用count(distinct)，count(distinct)容易产生倾斜问题。

• 对小文件进行合并，是行至有效的提高调度效率的方法，假如所有的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的正向影响。

• 优化时把握整体，单个作业最优不如整体最优。

而接下来，我们心中应该会有一些疑问，影响性能的根源是什么？

2.性能低下的根源

hive性能优化时，把HiveQL当做M/R程序来读，即从M/R的运行角度来考虑优化性能，从更底层思考如何优化运算性能，而不仅仅局限于逻辑代码的替换层面。

RAC（Real Application Cluster）真正应用集群就像一辆机动灵活的小货车，响应快；Hadoop就像吞吐量巨大的轮船，启动开销大，如果每次只做小数量的输入输出，利用率将会很低。所以用好Hadoop的首要任务是增大每次任务所搭载的数据量。

Hadoop的核心能力是parition和sort，因而这也是优化的根本。

观察Hadoop处理数据的过程，有几个显著的特征：

• 数据的大规模并不是负载重点，造成运行压力过大是因为运行数据的倾斜。

• jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联对此汇总，产生几十个jobs，将会需要30分钟以上的时间且大部分时间被用于作业分配，初始化和数据输出。M/R作业初始化的时间是比较耗时间资源的一个部分。

• 在使用SUM，COUNT，MAX，MIN等UDAF函数时，不怕数据倾斜问题，Hadoop在Map端的汇总合并优化过，使数据倾斜不成问题。

• COUNT(DISTINCT)在数据量大的情况下，效率较低，如果多COUNT(DISTINCT)效率更低，因为COUNT(DISTINCT)是按GROUP BY字段分组，按DISTINCT字段排序，一般这种分布式方式是很倾斜的；比如：男UV，女UV，淘宝一天30亿的PV，如果按性别分组，分配2个reduce,每个reduce处理15亿数据。

• 数据倾斜是导致效率大幅降低的主要原因，可以采用多一次 Map/Reduce 的方法， 避免倾斜。

最后得出的结论是：避实就虚，用 job 数的增加，输入量的增加，占用更多存储空间，充分利用空闲 CPU 等各种方法，分解数据倾斜造成的负担。

3.配置角度优化

我们知道了性能低下的根源，同样，我们也可以从Hive的配置解读去优化。Hive系统内部已针对不同的查询预设定了优化方法，用户可以通过调整配置进行控制， 以下举例介绍部分优化的策略以及优化控制选项。

3.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.2分区裁剪

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

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

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

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

3.3JOIN操作

在编写带有 join 操作的代码语句时，应该将条目少的表/子查询放在 Join 操作符的左边。 因为在 Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，载入条目较少的表 可以有效减少 OOM（out of memory）即内存溢出。所以对于同一个 key 来说，对应的 value 值小的放前，大的放后，这便是“小表放前”原则。 若一条语句中有多个 Join，依据 Join 的条件相同与否，有不同的处理方法。

3.3.1JOIN原则

在使用写有 Join 操作的查询语句时有一条原则：应该将条目少的表/子查询放在 Join 操作符的左边。原因是在 Join 操作的 Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生 OOM 错误的几率。对于一条语句中有多个 Join 的情况，如果 Join 的条件相同，比如查询：

INSERT OVERWRITE TABLE pv_users

SELECT pv.pageid, u.age FROM page_view p

JOIN user u ON (pv.userid = u.userid)

JOIN newuser x ON (u.userid = x.userid);

• 如果 Join 的 key 相同，不管有多少个表，都会则会合并为一个 Map-Reduce

• 一个 Map-Reduce 任务，而不是 ‘n’ 个

• 在做 OUTER JOIN 的时候也是一样

如果 Join 的条件不相同，比如：

INSERT OVERWRITE TABLE pv_users

SELECT pv.pageid, u.age FROM page_view p

JOIN user u ON (pv.userid = u.userid)

JOIN newuser x on (u.age = x.age);

Map-Reduce 的任务数目和 Join 操作的数目是对应的，上述查询和以下查询是等价的：

INSERT OVERWRITE TABLE tmptable

SELECT * FROM page_view p JOIN user u

ON (pv.userid = u.userid);

INSERT OVERWRITE TABLE pv_users

SELECT x.pageid, x.age FROM tmptable x

JOIN newuser y ON (x.age = y.age);

3.4MAP JOIN操作

Join 操作在 Map 阶段完成，不再需要Reduce，前提条件是需要的数据在 Map 的过程中可以访问到。比如查询：

INSERT OVERWRITE TABLE pv_users

SELECT /*+ MAPJOIN(pv) */ pv.pageid, u.age

FROM page_view pv

JOIN user u ON (pv.userid = u.userid);

可以在 Map 阶段完成 Join.

相关的参数为：

• hive.join.emit.interval = 1000

• hive.mapjoin.size.key = 10000

• hive.mapjoin.cache.numrows = 10000

3.5GROUP BY操作

进行GROUP BY操作时需要注意一下几点：

• Map端部分聚合

事实上并不是所有的聚合操作都需要在reduce部分进行，很多聚合操作都可以先在Map端进行部分聚合，然后reduce端得出最终结果。

这里需要修改的参数为：

hive.map.aggr=true（用于设定是否在 map 端进行聚合，默认值为真） hive.groupby.mapaggr.checkinterval=100000（用于设定 map 端进行聚合操作的条目数）

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

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

3.6合并小文件

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

用于设置合并属性的参数有：

• 是否合并Map输出文件：hive.merge.mapfiles=true（默认值为真）

• 是否合并Reduce 端输出文件：hive.merge.mapredfiles=false（默认值为假）

• 合并文件的大小：hive.merge.size.per.task=256*1000*1000（默认值为 256000000）

4.程序角度优化

4.1熟练使用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 分布式计算方式中也可以达到效果。

4.2无效ID在关联时的数据倾斜问题

问题：日志中常会出现信息丢失，比如每日约为 20 亿的全网日志，其中的 user_id 为主 键，在日志收集过程中会丢失，出现主键为 null 的情况，如果取其中的 user_id 和 bmw_users 关联，就会碰到数据倾斜的问题。原因是 Hive 中，主键为 null 值的项会被当做相同的 Key 而分配进同一个计算 Map。

解决方法 1：user_id 为空的不参与关联，子查询过滤 null

SELECT * FROM log a

JOIN bmw_users b ON a.user_id IS NOT NULL AND a.user_id=b.user_id

UNION All SELECT * FROM log a WHERE a.user_id IS NULL

解决方法 2 如下所示：函数过滤 null

SELECT * FROM log a LEFT OUTER

JOIN bmw_users b ON

CASE WHEN a.user_id IS NULL THEN CONCAT(‘dp_hive’,RAND()) ELSE a.user_id END =b.user_id;

调优结果：原先由于数据倾斜导致运行时长超过 1 小时，解决方法 1 运行每日平均时长 25 分钟，解决方法 2 运行的每日平均时长在 20 分钟左右。优化效果很明显。

我们在工作中总结出：解决方法2比解决方法1效果更好，不但IO少了，而且作业数也少了。解决方法1中log读取两次，job 数为2。解决方法2中 job 数是1。这个优化适合无效 id（比如-99、 ‘’，null 等）产生的倾斜问题。把空值的 key 变成一个字符串加上随机数，就能把倾斜的 数据分到不同的Reduce上，从而解决数据倾斜问题。因为空值不参与关联，即使分到不同 的 Reduce 上，也不会影响最终的结果。附上 Hadoop 通用关联的实现方法是：关联通过二次排序实现的，关联的列为 partion key，关联的列和表的 tag 组成排序的 group key，根据 pariton key分配Reduce。同一Reduce内根据group key排序。

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

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

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

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

SELECT * FROM s8_log a LEFT OUTERJOIN r_auction_auctions b ON a.auction_id=CASE(b.auction_id AS STRING)

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

4.4利用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 读取只会是一次。

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

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

• 消灭子查询内的 group by

示例 1：子查询内有 group by

SELECT * FROM

(SELECT * FROM t1 GROUP BY c1,c2,c3 UNION ALL SELECT * FROM t2 GROUP BY c1,c2,c3)t3

GROUP BY c1,c2,c3

从业务逻辑上说，子查询内的 GROUP BY 怎么都看显得多余（功能上的多余，除非有 COUNT(DISTINCT)），如果不是因为 Hive Bug 或者性能上的考量（曾经出现如果不执行子查询 GROUP BY，数据得不到正确的结果的 Hive Bug）。所以这个 Hive 按经验转换成如下所示：

SELECT * FROM (SELECT * FROM t1 UNION ALL SELECT * FROM t2)t3 GROUP BY c1,c2,c3

调优结果：经过测试，并未出现 union all 的 Hive Bug，数据是一致的。MapReduce 的 作业数由 3 减少到 1。

t1 相当于一个目录，t2 相当于一个目录，对 Map/Reduce 程序来说，t1，t2 可以作为 Map/Reduce 作业的 mutli inputs。这可以通过一个 Map/Reduce 来解决这个问题。Hadoop 的 计算框架，不怕数据多，就怕作业数多。

但如果换成是其他计算平台如 Oracle，那就不一定了，因为把大的输入拆成两个输入， 分别排序汇总后 merge（假如两个子排序是并行的话），是有可能性能更优的（比如希尔排 序比冒泡排序的性能更优）。

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

SELECT * FROM

(SELECT * FROM t1

UNION ALL SELECT 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

SELECT * FROM

(SELECT * FROM t1 UNION ALL SELECT * FROM t4 UNION ALL SELECT * 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

SELECT * FROM t2 JOIN t3 ON t2.id=t3.id;

SELECT * FROM (t1 UNION ALL t4 UNION ALL t5);

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

4.6GROUP BY替代COUNT(DISTINCT)达到优化效果

计算 uv 的时候，经常会用到 COUNT(DISTINCT)，但在数据比较倾斜的时候 COUNT(DISTINCT) 会比较慢。这时可以尝试用 GROUP BY 改写代码计算 uv。

• 原有代码

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

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

测试数据：169857条

#统计每日IP

CREATE TABLE ip_2014_12_29 AS SELECT COUNT(DISTINCT ip) AS IP FROM logdfs WHERE logdate=’2014_12_29′;

耗时：24.805 seconds

#统计每日IP（改造）

CREATE TABLE ip_2014_12_29 AS SELECT COUNT(1) AS IP FROM (SELECT DISTINCT ip from logdfs WHERE logdate=’2014_12_29′) tmp;

耗时：46.833 seconds

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

5.优化总结

优化时，把hive sql当做mapreduce程序来读，会有意想不到的惊喜。理解hadoop的核心能力，是hive优化的根本。这是这一年来，项目组所有成员宝贵的经验总结。

• 长期观察hadoop处理数据的过程，有几个显著的特征:

1. 不怕数据多，就怕数据倾斜。

2. 对jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，没半小时是跑不完的。map reduce作业初始化的时间是比较长的。

3. 对sum，count来说，不存在数据倾斜问题。

4. 对count(distinct ),效率较低，数据量一多，准出问题，如果是多count(distinct )效率更低。

• 优化可以从几个方面着手：

1. 好的模型设计事半功倍。

2. 解决数据倾斜问题。

3. 减少job数。

4. 设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。

5. 自己动手写sql解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化总是漠视业务，习惯性提供通用的解决方法。 Etl开发人员更了解业务，更了解数据，所以通过业务逻辑解决倾斜的方法往往更精确，更有效。

6. 对count(distinct)采取漠视的方法，尤其数据大的时候很容易产生倾斜问题，不抱侥幸心理。自己动手，丰衣足食。

7. 对小文件进行合并，是行至有效的提高调度效率的方法，假如我们的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的影响。

优化时把握整体，单个作业最优不如整体最优。

6.优化的常用手段

主要由三个属性来决定：

• hive.exec.reducers.bytes.per.reducer   ＃这个参数控制一个job会有多少个reducer来处理，依据的是输入文件的总大小。默认1GB。

• hive.exec.reducers.max    ＃这个参数控制最大的reducer的数量， 如果 input / bytes per reduce > max  则会启动这个参数所指定的reduce个数。  这个并不会影响mapre.reduce.tasks参数的设置。默认的max是999。

• mapred.reduce.tasks ＃这个参数如果指定了，hive就不会用它的estimation函数来自动计算reduce的个数，而是用这个参数来启动reducer。默认是-1。

6.1参数设置的影响

如果reduce太少：如果数据量很大，会导致这个reduce异常的慢，从而导致这个任务不能结束，也有可能会OOM 2、如果reduce太多：  产生的小文件太多，合并起来代价太高，namenode的内存占用也会增大。如果我们不指定mapred.reduce.tasks， hive会自动计算需要多少个reducer。

安装部署
安装部署这里我们就不讲解了，不会的同学，参考作者以前的博客

Hive基本语法
改篇博客主要讲解Hive底层的东西和一些优化对于基本的东西可以参考作者以前的博客。 
DDL 
DML 
基本SQL 
内置函数和基本的UDF函数

UDF函数这里要进行一个讲解UDF、DUAF、UDTF分别是啥。 
我们知道Hive的SQL还可以通过用户定义的函数（UDF），用户定义的聚合（UDAF）和用户定义的表函数（UDTF）进行扩展。 
当Hive提供的内置函数无法满足你的业务处理需要时，此时就可以考虑使用用户自定义函数（UDF：user-defined function）。　　 
UDF(User-Defined-Function) 一进一出

UDAF(User- Defined Aggregation Funcation) 聚集函数，多进一出。

UDTF(User-Defined Table-Generating Functions) 一进多出，如lateral view explore()

Hive于关系型数据库的区别
时效性、延时性比较高，可扩展性高；
Hive数据规模大，优势在于处理大数据集，对于小数据集没有优势
事务没什么用(比较鸡肋，没什么实际的意义，对于离线的来说)  一个小问题：那个版本开始提供了事务？
insert/update没什么实际用途，大数据场景下大多数是select
RDBMS也支持分布式，节点有限 成本高，处理的数据量小
Hadoop集群规模更大 部署在廉价机器上，处理的数据量大
数据库可以用在Online的应用中，Hive主要进行离线的大数据分析；
数据库的查询语句为SQL，Hive的查询语句为HQL；
数据库数据存储在LocalFS，Hive的数据存储在HDFS；
数据格式:Hive中有多种存储格式：由于在加载数据的过程中，不需要从用户数据格式到 Hive 定义的数据格式的转换，
因此，Hive 在加载的过程中不会对数据本身进行任何修改，而只是将数据内容复制或者移动到相应的 HDFS 目录中。
而在数据库中，不同的数据库有不同的存储引擎，定义了自己的数据格式。所有数据都会按照一定的组织存储，因此，
数据库加载数据的过程会比较耗时。
Hive执行MapReduce，MySQL执行Executor；
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Hive的优点
1.简单易上手
2.扩展能力较好(指集群 HDFS或是YARN)
3.统一的元数据管理 metastore包括的了数据库，表，字段分区等详细信息
1
2
3
该篇博客对于元数据信息进行了详细的讲解

4.由于统一的元数据管理所以和spark/impala等SQL引擎是通用的 
通用是指，在拥有了统一的metastore之后，在Hive中创建一张表，在Spark/impala中是能用的，反之在Spark中创建一张表，
在Hive中也能用；只需要共用元数据，就可以切换SQL引擎   
涉及到了Spark sql 和Hive On Spark(实验版本)
5.使用SQL语法，提供快速开发的能力，支持自定义函数UDF。
6.避免了去写mapreduce，减少开发人员学习成本。
7.数据离线处理，比如日志分析，海量数据结构化分析
1
2
3
4
5
6
7
SQL转化为MapReduce的过程
了解了MapReduce实现SQL基本操作之后，我们来看看Hive是如何将SQL转化为MapReduce任务的，整个编译过程分为六个阶段： 
1. Antlr定义SQL的语法规则，完成SQL词法，语法解析，将SQL转化为抽象语法树AST Tree 
2. 遍历AST Tree，抽象出查询的基本组成单元QueryBlock 
3. 遍历QueryBlock，翻译为执行操作树OperatorTree 
4. 逻辑层优化器进行OperatorTree变换，合并不必要的ReduceSinkOperator，减少shuffle数据量 
5. 遍历OperatorTree，翻译为MapReduce任务 
6. 物理层优化器进行MapReduce任务的变换，生成最终的执行计划

可以参考美团的技术沙龙

Hive内部表和外部表的区别
未被external修饰的是内部表（managed table），被external修饰的为外部表（external table）；
区别： 
内部表数据由Hive自身管理，外部表数据由HDFS管理； 
内部表数据存储的位置是hive.metastore.warehouse.dir（默认：/user/hive/warehouse），外部表数据的存储位置由自己制定； 
删除内部表会直接删除元数据（metadata）及存储数据；删除外部表仅仅会删除元数据，HDFS上的文件并不会被删除；

行式存储vs列式存储
行式数据库存储在hdfs上式按行进行存储的，一个block存储一或多行数据。而列式数据库在hdfs上则是按照列进行存储，一个block可能有一列或多列数据。

如果要将数据进行压缩： 
对于行式数据库，必然按行压缩，当一行中有多个字段，各个字段对应的数据类型可能不一致，压缩性能压缩比就比较差。 
对于列式数据库，必然按列压缩，每一列对应的是相同数据类型的数据，故列式数据库的压缩性能要强于行式数据库。 
如果要进行数据的查询： 
假设执行的查询操作是：select id,name from table_emp; 
对于行式数据库，它要遍历一整张表将每一行中的id,name字段拼接再展现出来，这样需要查询的数据量就比较大，效率低。 
对于列式数据库，它只需找到对应的id,name字段的列展现出来即可，需要查询的数据量小，效率高。 
假设执行的查询操作是：select * from table_emp; 
对于这种查询整个表全部信息的操作，由于列式数据库需要将分散的行进行重新组合，行式数据库效率就高于列式数据库。 
但是，在大数据领域，进行全表查询的场景少之又少，进而我们使用较多的还是列式数据库及列式储存。

Hive哪些查询会执行mr
hive 0.10.0为了执行效率考虑，简单的查询，就是只是select，不带count,sum,group by这样的，都不走map/reduce，直接读取hdfs文件进行filter过滤。 
这样做的好处就是不新开mr任务，执行效率要提高不少，但是不好的地方就是用户界面不友好，有时候数据量大还是要等很长时间，但是又没有任何返回。 
改这个很简单，在hive-site.xml里面有个配置参数叫 
hive.fetch.task.conversion 
将这个参数设置为more，简单查询就不走map/reduce了，设置为minimal，就任何简单select都会走map/reduce

Create Table As Select (CTAS) 走mr 
create table emp2 as select * from emp;

insert一条或者多条 走mr

Hive静态分区动态分区
分区的概念 
Hive的分区方式：由于Hive实际是存储在HDFS上的抽象，Hive的一个分区名对应HDFS上的一个目录名，子分区名就是子目录名，并不是一个实际字段。 
分区的好处 
产生背景：如果一个表中数据很多，我们查询时就很慢，耗费大量时间，如果要查询其中部分数据该怎么办呢，这是我们引入分区的概念。 
Partition:分区，每张表中可以加入一个分区或者多个，方便查询，提高效率；并且HDFS上会有对应的分区目录： 
语法： 
Hive分区是在创建表的时候用Partitioned by 关键字定义的，但要注意，Partitioned by子句中定义的列是表中正式的列， 
但是Hive下的数据文件中并不包含这些列，因为它们是目录名，真正的数据在分区目录下。 
静态分区和 动态分区的区别 
创建表的语法都一样

静态分区：加载数据的时候要指定分区的值（key=value），比较麻烦的是每次插入数据都要指定分区的值，创建多个分区多分区一样，以逗号分隔。
动态分区： 
如果用上述的静态分区，插入的时候必须首先要知道有什么分区类型，而且每个分区写一个load data，太烦人。使用动态分区可解决以上问题，其可以根据查询得到的数据动态分配到分区里。其实动态分区与静态分区区别就是不指定分区目录，由系统自己选择。
首先，启动动态分区功能

hive> set hive.exec.dynamic.partition=true;

采用动态方式加载数据到目标表 
加载之前先设置一下下面的参数

hive (default)> set hive.exec.dynamic.partition.mode=nonstrict
1
开始加载

insert into table emp_dynamic_partition partition(deptno)
select empno , ename , job , mgr , hiredate , sal , comm, deptno from emp;
1
2
3
4
5
6
7
8
9
10
11
12
13
加载数据方式并没有指定具体的分区，只是指出了分区字段。 
在select最后一个字段必须跟你的分区字段，这样就会自行根据deptno的value来分区。 
删除分区： 
ALTER TABLE my_partition_test_table DROP IF EXISTS PARTITION (day='2018-08-08');

Hive优化
1.我们知道大数据场景下不害怕数据量大，害怕的是数据倾斜，怎样避免数据倾斜，找到可能产生数据倾斜的函数尤为关键，数据量较大的情况下，慎用count(distinct)，count(distinct)容易产生倾斜问题。 
2.设置合理的map reduce 的task数量 
map阶段优化

    mapred.min.split.size: 指的是数据的最小分割单元大小；min的默认值是1B
    mapred.max.split.size: 指的是数据的最大分割单元大小；max的默认值是256MB
    通过调整max可以起到调整map数的作用，减小max可以增加map数，增大max可以减少map数。
    需要提醒的是，直接调整mapred.map.tasks这个参数是没有效果的。
1
2
3
4
举例： 
a) 假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块（6个128m的块和1个12m的块），从而产生7个map数 
b) 假设input目录下有3个文件a,b,c,大小分别为10m，20m，130m，那么hadoop会分隔成4个块（10m,20m,128m,2m）,从而产生4个map数 
即，如果文件大于块大小(128m),那么会拆分，如果小于块大小，则把该文件当成一个块。

其实这就涉及到小文件的问题：如果一个任务有很多小文件（远远小于块大小128m）,则每个小文件也会被当做一个块，用一个map任务来完成， 
而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。 
而且，同时可执行的map数是受限的。那么问题又来了。。是不是保证每个map处理接近128m的文件块，就高枕无忧了？ 
答案也是不一定。比如有一个127m的文件，正常会用一个map去完成，但这个文件只有一个或者两个小字段，却有几千万的记录， 
如果map处理的逻辑比较复杂，用一个map任务去做，肯定也比较耗时。

我们该如何去解决呢？？？ 
我们需要采取两种方式来解决：即减少map数和增加map数； 
- 减少map数量

假设一个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;
set mapred.min.split.size.per.node=100000000;
set mapred.min.split.size.per.rack=100000000;
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个块。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
增大map数量
如何适当的增加map数？ 
当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，可以考虑增加Map数，
来使得每个map处理的数据量减少，从而提高任务的执行效率。
   假设有这样一个任务：
   Select data_desc,
          count(1),
          count(distinct id),
          sum(case when …),
          sum(case when ...),
          sum(…)
  from a group by data_desc
  如果表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（几百万记录）的数据，效率肯定会好很多。

   看上去，貌似这两种有些矛盾，一个是要合并小文件，一个是要把大文件拆成小文件，
   这点正是重点需要关注的地方，
   使单个map任务处理合适的数据量；
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
reduce阶段优化

    Reduce的个数对整个作业的运行性能有很大影响。如果Reduce设置的过大，那么将会产生很多小文件，
    对NameNode会产生一定的影响，
    而且整个作业的运行时间未必会减少；如果Reduce设置的过小，那么单个Reduce处理的数据将会加大，
    很可能会引起OOM异常。
    如果设置了mapred.reduce.tasks/mapreduce.job.reduces参数，那么Hive会直接使用它的值作为Reduce的个数；
    如果mapred.reduce.tasks/mapreduce.job.reduces的值没有设置（也就是-1），那么Hive会
    根据输入文件的大小估算出Reduce的个数。
    根据输入文件估算Reduce的个数可能未必很准确，因为Reduce的输入是Map的输出，而Map的输出可能会比输入要小，
    所以最准确的数根据Map的输出估算Reduce的个数。
1
2
3
4
5
6
7
8
9
1. Hive自己如何确定reduce数： 
reduce个数的设定极大影响任务执行效率，不指定reduce个数的情况下，Hive会猜测确定一个reduce个数，基于以下两个设定： 
hive.exec.reducers.bytes.per.reducer（每个reduce任务处理的数据量，默认为1000^3=1G） 
hive.exec.reducers.max（每个任务最大的reduce数，默认为999） 
计算reducer数的公式很简单N=min(参数2，总输入数据量/参数1) 
即，如果reduce的输入（map的输出）总大小不超过1G,那么只会有一个reduce任务； 
如：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

调整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

调整reduce个数方法二； 
set mapred.reduce.tasks = 15; 
select pt,count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’ group by pt;这次有15个reduce

reduce个数并不是越多越好； 
同map一样，启动和初始化reduce也会消耗时间和资源； 
另外，有多少个reduce,就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入， 
则也会出现小文件过多的问题；

什么情况下只有一个reduce； 
很多时候你会发现任务中不管数据量多大，不管你有没有设置调整reduce个数的参数，任务中一直都只有一个reduce任务； 
其实只有一个reduce任务的情况，除了数据量小于hive.exec.reducers.bytes.per.reducer参数值的情况外，还有以下原因： 
a) 没有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’; 
这点非常常见，希望大家尽量改写。 
b) 用了Order by 
c) 有笛卡尔积 
通常这些情况下，除了找办法来变通和避免，我暂时没有什么好的办法，因为这些操作都是全局的，所以hadoop不得不用一个reduce去完成； 
同样的，在设置reduce个数的时候也需要考虑这两个原则：使大数据量利用合适的reduce数；使单个reduce任务处理合适的数据量；

合并小文件

　　我们知道文件数目小，容易在文件存储端造成瓶颈，给 HDFS 带来压力，影响处理效率。
　　对此，可以通过合并Map和Reduce的结果文件来消除这样的影响。
　　用于设置合并属性的参数有：
        是否合并Map输出文件：hive.merge.mapfiles=true（默认值为真）
        是否合并Reduce 端输出文件：hive.merge.mapredfiles=false（默认值为假）
        合并文件的大小：hive.merge.size.per.task=256*1000*1000（默认值为 256000000）
1
2
3
4
5
6
Hive优化之小文件问题及其解决方案 
小文件是如何产生的 
1.动态分区插入数据，产生大量的小文件，从而导致map数量剧增。

2.reduce数量越多，小文件也越多(reduce的个数和输出文件是对应的)。

3.数据源本身就包含大量的小文件。

小文件问题的影响 
1.从Hive的角度看，小文件会开很多map，一个map开一个JVM去执行，所以这些任务的初始化，启动，执行会浪费大量的资源，严重影响性能。

2.在HDFS中，每个小文件对象约占150byte，如果小文件过多会占用大量内存。这样NameNode内存容量严重制约了集群的扩展。

小文件问题的解决方案 
从小文件产生的途经就可以从源头上控制小文件数量，方法如下：

1.使用Sequencefile作为表存储格式，不要用textfile，在一定程度上可以减少小文件。

2.减少reduce的数量(可以使用参数进行控制)。

3.少用动态分区，用时记得按distribute by分区。

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

1.使用hadoop archive命令把小文件进行归档。

2.重建表，建表时减少reduce数量。

3.通过参数进行调节，设置map/reduce端的相关参数，如下：

设置map输入合并小文件的相关参数：

[java] view plain copy 
//每个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.Write good SQL :说道sql优化很惭愧，自己sql很烂，不多比比了，但是sql优化确实很关键。。。 
4.存储格式：可以使用列裁剪，分区裁剪，orc，parquet等存储格式。参考该博客

Hive支持ORCfile，这是一种新的表格存储格式，通过诸如谓词下推，压缩等技术来提高执行速度提升。
对于每个HIVE表使用ORCFile应该是一件容易的事情，并且对于获得HIVE查询的快速响应时间非常有益。
作为一个例子，考虑两个大表A和B（作为文本文件存储，其中一些列未在此处指定，即行试存储的缺点）以及一个简单的查询，如：
SELECT A.customerID, A.name, A.age, A.address join
B.role, B.department, B.salary
ON A.customerID=B.customerID;
此查询可能需要很长时间才能执行，因为表A和B都以TEXT形式存储，进行全表扫描。
将这些表格转换为ORCFile格式通常会显着减少查询时间：
1
2
3
4
5
6
7
8
ORC支持压缩存储（使用ZLIB或如上所示使用SNAPPY），但也支持未压缩的存储。
    CREATE TABLE A_ORC (
    customerID int, name string, age int, address string
    ) STORED AS ORC tblproperties (“orc.compress" = “SNAPPY”);

    INSERT INTO TABLE A_ORC SELECT * FROM A;

    CREATE TABLE B_ORC (
    customerID int, role string, salary float, department string
    ) STORED AS ORC tblproperties (“orc.compress" = “SNAPPY”);

    INSERT INTO TABLE B_ORC SELECT * FROM B;

    SELECT A_ORC.customerID, A_ORC.name,
    A_ORC.age, A_ORC.address join
    B_ORC.role, B_ORC.department, B_ORC.salary
    ON A_ORC.customerID=B_ORC.customerID;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
5.压缩格式：大数据场景下存储格式压缩格式尤为关键，可以提升计算速度，减少存储空间，降低网络io，磁盘io，所以要选择合适的压缩格式和存储格式，那么首先就了解这些东西，作者以前博客已经进行了详细的说明，参考该博客 
6.MAP JOIN 

MapJoin简单说就是在Map阶段将小表读入内存，顺序扫描大表完成Join。 
上图是Hive MapJoin的原理图，出自Facebook工程师Liyin Tang的一篇介绍Join优化的slice，从图中可以看出MapJoin分为两个阶段： 
（1）通过MapReduce Local Task，将小表读入内存，生成HashTableFiles上传至Distributed Cache中，这里会对HashTableFiles进行压缩。 
（2）MapReduce Job在Map阶段，每个Mapper从Distributed Cache读取HashTableFiles到内存中，顺序扫描大表，在Map阶段直接进行Join，将数据传递给下一个MapReduce任务。 
也就是在map端进行join避免了shuffle。 
7.引擎的选择

Hive可以使用ApacheTez执行引擎而不是古老的Map-Reduce引擎。 
我不会详细讨论在这里提到的使用Tez的许多好处; 相反，我想提出一个简单的建议：
如果它没有在您的环境中默认打开，请在您的Hive查询的开头将以下内容设置为'true'来使用Tez：
设置hive.execution.engine = tez;
通过上述设置，您执行的每个HIVE查询都将利用Tez。
目前Hive On Spark还处于试验阶段，慎用。。
1
2
3
4
5
6
8.Use Vectorization

向量化查询执行通过一次性批量执行1024行而不是每次单行执行，从而提高扫描，聚合，筛选器和连接等操作的性能。
在Hive 0.13中引入，此功能显着提高了查询执行时间，并可通过两个参数设置轻松启用：
设置hive.vectorized.execution.enabled = true;
设置hive.vectorized.execution.reduce.enabled = true;
1
2
3
4
9.cost based query optimization

Hive 自0.14.0开始，加入了一项”Cost based Optimizer”来对HQL执行计划进行优化，这个功能通  
过”hive.cbo.enable”来开启。在Hive 1.1.0之后，这个feature是默认开启的,它可以自动优化HQL中多个JOIN的顺序，并
选择合适的JOIN算法.
Hive在提交最终执行前,优化每个查询的执行逻辑和物理执行计划。这些优化工作是交给底层来完成。
根据查询成本执行进一步的优化，从而产生潜在的不同决策：如何排序连接，执行哪种类型的连接，并行度等等。
要使用基于成本的优化（也称为CBO），请在查询开始处设置以下参数：
设置hive.cbo.enable = true;

设置hive.compute.query.using.stats = true;

设置hive.stats.fetch.column.stats = true;

设置hive.stats.fetch.partition.stats = true;
1
2
3
4
5
6
7
8
9
10
11
12
13
10.模式选择

本地模式 
对于大多数情况，Hive可以通过本地模式在单台机器上处理所有任务。 
对于小数据，执行时间可以明显被缩短。通过set hive.exec.mode.local.auto=true（默认为false）设置本地模式。 
hive> set hive.exec.mode.local.auto; 
hive.exec.mode.local.auto=false

并行模式 
Hive会将一个查询转化成一个或者多个阶段。这样的阶段可以是MapReduce阶段、抽样阶段、合并阶段、limit阶段。 
默认情况下，Hive一次只会执行一个阶段，由于job包含多个阶段，而这些阶段并非完全互相依赖， 
即：这些阶段可以并行执行，可以缩短整个job的执行时间。设置参数：set hive.exec.parallel=true,或者通过配置文件来完成。 
hive> set hive.exec.parallel; 
hive.exec.parallel=false

严格模式 
Hive提供一个严格模式，可以防止用户执行那些可能产生意想不到的影响查询，通过设置 
Hive.mapred.modestrict来完成 
set Hive.mapred.modestrict; 
Hive.mapred.modestrict is undefined

11.JVM重用 
Hadoop通常是使用派生JVM来执行map和reduce任务的。这时JVM的启动过程可能会造成相当大的开销， 
尤其是执行的job包含偶成百上千的task任务的情况。JVM重用可以使得JVM示例在同一个job中时候使用N此。 
通过参数mapred.job.reuse.jvm.num.tasks来设置。

12.推测执行 
Hadoop推测执行可以触发执行一些重复的任务，尽管因对重复的数据进行计算而导致消耗更多的计算资源， 
不过这个功能的目标是通过加快获取单个task的结果以侦测执行慢的TaskTracker加入到没名单的方式来提高整体的任务执行效率。

Hadoop的推测执行功能由2个配置控制着，通过mapred-site.xml中配置

mapred.map.tasks.speculative.execution=true

mapred.reduce.tasks.speculative.execution=true

hive on spark 性能远比hive on mr 要好，而且提供了一样的功能。用户的sql无需修改就可以直接运行于hive on spark。 udf函数也是全部支持。

本文主要是想讲hive on spark 在运行于yarn模式的情况下如何调优。

下文举例讲解的yarn节点机器配置，假设有32核，120GB内存。

yarn配置

yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb,这两个参数决定这集群资源管理器能够有多少资源用于运行yarn上的任务。 这两个参数的值是由机器的配置及同时在机器上运行的其它进程共同决定。本文假设仅有hdfs的datanode和yarn的nodemanager运行于该节点。

1. 配置cores

基本配置是datanode和nodemanager各一个核，操作系统两个核，然后剩下28核配置作为yarn资源。也即是yarn.nodemanager.resource.cpu-vcores=28 

2. 配置内存 

对于内存，预留20GB给操作系统，datanode，nodemanager，剩余100GB作为yarn资源。也即是 yarn.nodemanager.resource.memory-mb=100*1024

spark配置

给yarn分配资源以后，那就要想着spark如何使用这些资源了，主要配置对象：

execurtor 和driver内存，executro配额，并行度。

1. executor内存

设置executor内存需要考虑如下因素:

executor内存越多，越能为更多的查询提供map join的优化。由于垃圾回收的压力会导致开销增加。

某些情况下hdfs的 客户端不能很好的处理并发写入，所以过多的核心可能会导致竞争。

为了最大化使用core，建议将core设置为4，5，6（多核心会导致并发问题，所以写代码的时候尤其是静态的链接等要考虑并发问题）具体分配核心数要结合yarn所提供的核心数。 由于本文中涉及到的node节点是28核，那么很明显分配为4的化可以被整除，spark.executor.cores设置为4 不会有多余的核剩下,设置为5，6都会有core剩余。 spark.executor.cores=4，由于总共有28个核，那么最大可以申请的executor数是7。总内存处以7，也即是 100/7，可以得到每个executor约14GB内存。

要知道 spark.executor.memory 和spark.executor.memoryOverhead 共同决定着 executor内存。建议 spark.executor.memoryOverhead站总内存的 15%-20%。 那么最终 spark.executor.memoryOverhead=2 G 和spark.executor.memory=12 G

根据上面的配置的化，每个主机就可以申请7个executor，每个executor可以运行4个任务，每个core一个task。那么每个task的平均内存是 14/4 = 3.5GB。在executor运行的task共享内存。 其实，executor内部是用newCachedThreadPool运行task的。

确保 spark.executor.memoryOverhead和 spark.executor.memory的和不超过yarn.scheduler.maximum-allocation-mb

2. driver内存

对于drvier的内存配置，当然也包括两个参数。

spark.driver.memoryOverhead    每个driver能从yarn申请的堆外内存的大小。

spark.driver.memory 当运行hive on spark的时候，每个spark driver能申请的最大jvm 堆内存。该参数结合 spark.driver.memoryOverhead共同决定着driver的内存大小。

driver的内存大小并不直接影响性能，但是也不要job的运行受限于driver的内存. 这里给出spark driver内存申请的方案，假设yarn.nodemanager.resource.memory-mb是 X。

driver内存申请12GB，假设 X > 50GB

driver内存申请 4GB，假设 12GB < X <50GB

driver内存申请1GB,假设 1GB < X < 12 GB

driver内存申请256MB，假设 X < 1GB

这些数值是 spark.driver.memory和 spark.driver.memoryOverhead内存的总和。对外内存站总内存的10%-15%。 假设 yarn.nodemanager.resource.memory-mb=100*1024MB,那么driver内存设置为12GB，此时 spark.driver.memory=10.5gb和spark.driver.memoryOverhead=1.5gb

注意，资源多少直接对应的是数据量的大小。所以要结合资源和数据量进行适当缩减和增加。

3. executor数

executor的数目是由每个节点运行的executor数目和集群的节点数共同决定。如果你有四十个节点，那么hive可以使用的最大executor数就是 280(40*7). 最大数目可能比这个小点，因为driver也会消耗1core和12GB。

当前假设是没有yarn应用在跑。

Hive性能与用于运行查询的executor数量直接相关。 但是，不通查询还是不通。 通常，性能与executor的数量成比例。 例如，查询使用四个executor大约需要使用两个executor的一半时间。 但是，性能在一定数量的executor中达到峰值，高于此值时，增加数量不会改善性能并且可能产生不利影响。

在大多数情况下，使用一半的集群容量（executor数量的一半）可以提供良好的性能。 为了获得最佳性能，最好使用所有可用的executor。 例如，设置spark.executor.instances = 280。 对于基准测试和性能测量，强烈建议这样做。

4. 动态executor申请

虽然将spark.executor.instances设置为最大值通常可以最大限度地提高性能，但不建议在多个用户运行Hive查询的生产环境中这样做。 避免为用户会话分配固定数量的executor，因为如果executor空闲，executor不能被其他用户查询使用。 在生产环境中，应该好好计划executor分配，以允许更多的资源共享。

Spark允许您根据工作负载动态扩展分配给Spark应用程序的集群资源集。 要启用动态分配，请按照动态分配中的步骤进行操作。 除了在某些情况下，强烈建议启用动态分配。

5. 并行度

要使可用的executor得到充分利用，必须同时运行足够的任务（并行）。在大多数情况下，Hive会自动确定并行度，但也可以在调优并发度方面有一些控制权。 在输入端，map任务的数量等于输入格式生成的split数。对于Hive on Spark，输入格式为CombineHiveInputFormat，它可以根据需要对基础输入格式生成的split进行分组。 可以更好地控制stage边界的并行度。调整hive.exec.reducers.bytes.per.reducer以控制每个reducer处理的数据量，Hive根据可用的executor，执行程序内存，以及其他因素来确定最佳分区数。 实验表明，只要生成足够的任务来保持所有可用的executor繁忙，Spark就比MapReduce对hive.exec.reducers.bytes.per.reducer指定的值敏感度低。 为获得最佳性能，请为该属性选择一个值，以便Hive生成足够的任务以完全使用所有可用的executor。

hive配置

Hive on spark 共享了很多hive性能相关的配置。可以像调优hive on mapreduce一样调优hive on spark。 然而，hive.auto.convert.join.noconditionaltask.size是基于统计信息将基础join转化为map join的阈值，可能会对性能产生重大影响。 尽管该配置可以用hive on mr和hive on spark，但是两者的解释不同。

数据的大小有两个统计指标：

totalSize- 数据在磁盘上的近似大小。

rawDataSize- 数据在内存中的近似大小。

hive on mr用的是totalSize。hive on spark使用的是rawDataSize。由于可能存在压缩和序列化，这两个值会有较大的差别。 对于hive on spark 需要将 hive.auto.convert.join.noconditionaltask.size指定为更大的值，才能将与hive on mr相同的join转化为map join。

可以增加此参数的值，以使地图连接转换更具凶猛。 将common join 转换为 map join 可以提高性能。 如果此值设置得太大，则来自小表的数据将使用过多内存，任务可能会因内存不足而失败。 根据群集环境调整此值。

通过参数 hive.stats.collect.rawdatasize 可以控制是否收集 rawDataSize 统计信息。

对于hiveserver2，建议再配置两个额外的参数: hive.stats.fetch.column.stats=true 和 hive.optimize.index.filter=true.

Hive性能调优通常建议使用以下属性：

hive.optimize.reducededuplication.min.reducer=4
hive.optimize.reducededuplication=true
hive.merge.mapfiles=true
hive.merge.mapredfiles=false
hive.merge.smallfiles.avgsize=16000000
hive.merge.size.per.task=256000000
hive.merge.sparkfiles=true
hive.auto.convert.join=true
hive.auto.convert.join.noconditionaltask=true
hive.auto.convert.join.noconditionaltask.size=20M(might need to increase for Spark, 200M)
hive.optimize.bucketmapjoin.sortedmerge=false
hive.map.aggr.hash.percentmemory=0.5
hive.map.aggr=true
hive.optimize.sort.dynamic.partition=false
hive.stats.autogather=true
hive.stats.fetch.column.stats=true
hive.compute.query.using.stats=true
hive.limit.pushdown.memory.usage=0.4 (MR and Spark)
hive.optimize.index.filter=true
hive.exec.reducers.bytes.per.reducer=67108864
hive.smbjoin.cache.rows=10000
hive.fetch.task.conversion=more
hive.fetch.task.conversion.threshold=1073741824
hive.optimize.ppd=true

预启动YARN容器

在开始新会话后提交第一个查询时，在查看查询开始之前可能会遇到稍长的延迟。还会注意到，如果再次运行相同的查询，它的完成速度比第一个快得多。

Spark执行程序需要额外的时间来启动和初始化yarn上的Spark，这会导致较长的延迟。此外，Spark不会等待所有executor在启动作业之前全部启动完成，因此在将作业提交到群集后，某些executor可能仍在启动。 但是，对于在Spark上运行的作业，作业提交时可用executor的数量部分决定了reducer的数量。当就绪executor的数量未达到最大值时，作业可能没有最大并行度。这可能会进一步影响第一个查询的性能。

在用户较长期会话中，这个额外时间不会导致任何问题，因为它只在第一次查询执行时发生。然而，诸如Oozie发起的Hive工作之类的短期绘画可能无法实现最佳性能。

为减少启动时间，可以在作业开始前启用容器预热。只有在请求的executor准备就绪时，作业才会开始运行。这样，在reduce那一侧不会减少短会话的并行性。

要启用预热功能，请在发出查询之前将hive.prewarm.enabled设置为true。还可以通过设置hive.prewarm.numcontainers来设置容器数量。默认值为10。

预热的executor的实际数量受spark.executor.instances（静态分配）或spark.dynamicAllocation.maxExecutors（动态分配）的值限制。 hive.prewarm.numcontainers的值不应超过分配给用户会话的值。

注意：预热需要几秒钟，对于短会话来说是一个很好的做法，特别是如果查询涉及reduce阶段。 但是，如果hive.prewarm.numcontainers的值高于群集中可用的值，则该过程最多可能需要30秒。 请谨慎使用预热。
--------------------- 

基于CDH 5.9.1 搭建 Hive on Spark 及相关配置和调优

 

　　Hive默认使用的计算框架是MapReduce，在我们使用Hive的时候通过写SQL语句，Hive会自动将SQL语句转化成MapReduce作业去执行，但是MapReduce的执行速度远差与Spark。通过搭建一个Hive On Spark可以修改Hive底层的计算引擎，将MapReduce替换成Spark，从而大幅度提升计算速度。接下来就如何搭建Hive On Spark展开描述。

　　注：本人使用的是CDH5.9.1，使用的Spark版本是1.6.0，使用的集群配置为4个节点，每台内存32+G，4 Core。

1.   配置Yarn

　　Yarn需要配置两个参数：yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb。yarn.nodemanager.resource.cpu-vcores代表可以为container分配的CPU 内核的数量。yarn.nodemanager.resource.memory-mb代表可分配给容器的物理内存大小。

1)   配置cpu core

　　为每个服务分配一个core，为操作系统预留2个core，剩余的可用的core分配给yarn。我使用的集群共有16个core，留出4个，剩余的12个core分配给yarn。

 　　

 

2)   配置内存

　　设置Yarn内存为36G

 　　

 

2.   配置Spark

　　给Yarn分配完资源后，需要配置一些Spark的参数，设置Spark可使用的资源。包括executor和Driver的内存，分配executor和设置并行度。

3)   配置executor内存

　　在配置executor的内存大小的时候，需要考虑以下因素:

• 增加executor的内存可以优化map join。但是会增加GC的时间。
• 在某些情况下，HDFS客户端没有并行处理多个写请求，在有多个请求竞争资源的时候会出现一个executor使用过多的core。
• 尽可能的减少空闲的core的个数，cloudera推荐设置spark.executor.cores为4，5，6，这取决于给yarn分配的资源。

　　比如说，因为我们有12个core可用，我们可以设置为4，这样12/4余数为0，设置为5的话会剩余两个空闲。设置4个可使得空闲的core尽可能的少。

　　这样配置之后我们可以同时运行三个executor，每个executor最多可以运行4个任务（每个core一个）。

　　还有一点是要求spark.executor.memoryOverhead和spark.executor.memory的和不能超过yarn.scheduler.maximum-allocation-mb设置的值。我的scheduler请求最大内存分配的是12G。

 　　

 

4)   配置Driver内存

　　Spark Driver端的配置如下：

• spark.driver.memory---当hive运行在spark上时，driver端可用的最大Java堆内存。
• spark.yarn.driver.memoryOverhead---每个driver可以额外从yarn请求的堆内存大小。这个参数加上spark.driver.memory就是yarn为driver端的JVM分配的总内存。

　　Spark在Driver端的内存不会直接影响性能，但是在没有足够内存的情况下在driver端强制运行Spark任务需要调整。

5)   设置executor个数

　　集群的executor个数设置由集群中每个节点的executor个数和集群的worker个数决定，如果集群中有3个worker，则Hive On Spark可以使用的executor最大个数是12个（3 * 4）。

　　Hive的性能受可用的executor的个数影响很明显，一般情况下，性能和executor的个数成正比，4个executor的性能大约是2个executor性能的一倍，但是性能在executor设置为一定数量的时候会达到极值，达到这个极值之后再增加executor的个数不会增加性能，反而有可能会为集群增加负担。

6)   动态分配executor

　　设置spark.executor.instances到最大值可以使得Spark集群发挥最大性能。但是这样有个问题是当集群有多个用户运行Hive查询时会有问题，应避免为每个用户的会话分配固定数量的executor，因为executor分配后不能回其他用户的查询使用，如果有空闲的executor，在生产环境中，计划分配好executor可以更充分的利用Spark集群资源。

　　Spark允许动态的给Spark作业分配集群资源，cloudera推荐开启动态分配。

7)   设置并行度

　　为了更加充分的利用executor，必须同时允许足够多的并行任务。在大多数情况下，hive会自动决定并行度，但是有时候我们可能会手动的调整并行度。在输入端，map task的个数等于输入端按照一定格式切分的生成的数目，Hive On Spark的输入格式是CombineHiveInputFormat，可以根据需要切分底层输入格式。调整hive.exec.reducers.bytes.per.reducer控制每个reducer处理多少数据。但是实际情况下，Spark相比于MapReduce，对于指定的hive.exec.reducers.bytes.per.reducer不敏感。我们需要足够的任务让可用的executor保持工作不空闲，当Hive能够生成足够多的任务，尽可能的利用空闲的executor。

3.   配置Hive

　　Hive on Spark的配置大部分即使不使用Hive，也可以对这些参数调优。但是hive.auto.convert.join.noconditionaltask.size这个参数是将普通的join转化成map join的阈值，这个参数调优对于性能有很大影响。MapReduce和Spark都可以通过这个参数进行调优，但是这个参数在Hive On MR上的含义不同于Hive On Spark。

　　数据的大小由两个统计量标识：

• ·totalSize 磁盘上数据的大小
• ·rawDataSize 内存中数据的大小

　　Hive On MapReduce使用的是totalSize，Spark使用rawDataSize。数据由于经过一系列压缩、序列化等操作，即使是相同的数据集，也会有很大的不同，对于Hive On Spark，需要设置　　　hive.auto.convert.join.noconditionaltask.size，将普通的join操作转化成map join来提升性能，集群资源充足的情况下可以把这个参数的值适当调大，来更多的触发map join。但是设置太高的话，小表的数据会占用过多的内存导致整个任务因为内存耗尽而失败，所有这个参数需要根据集群的资源来进行调整。

　　Cloudera推荐配置两个额外的配置项：

　　hive.stats.fetch.column.stats=true

　　hive.optimize.index.filter=true

　　以下还整理了一些配置项用于hive调优：

hive.optimize.reducededuplication.min.reducer=4 hive.optimize.reducededuplication=true hive.merge.mapfiles=true hive.merge.mapredfiles=false hive.merge.smallfiles.avgsize=16000000 hive.merge.size.per.task=256000000 hive.merge.sparkfiles=true hive.auto.convert.join=true hive.auto.convert.join.noconditionaltask=true hive.auto.convert.join.noconditionaltask.size=20M(might need to increase for Spark, 200M) hive.optimize.bucketmapjoin.sortedmerge=false hive.map.aggr.hash.percentmemory=0.5 hive.map.aggr=true hive.optimize.sort.dynamic.partition=false hive.stats.autogather=true hive.stats.fetch.column.stats=true hive.compute.query.using.stats=true hive.limit.pushdown.memory.usage=0.4 (MR and Spark) hive.optimize.index.filter=true hive.exec.reducers.bytes.per.reducer=67108864 hive.smbjoin.cache.rows=10000 hive.fetch.task.conversion=more hive.fetch.task.conversion.threshold=1073741824 hive.optimize.ppd=true

 

8)   设置Pre-warming Yarn Container

　　我们使用Hive On Spark的时候，提交第一个查询时，看到查询结果可能会有比较长的延迟，但是再次运行相同的SQL查询，完成速度要比第一个查询快得多。

　　当Spark使用yarn管理资源调度时，Spark executor需要额外的时间来启动和初始化，在程序运行之前，Spark不会等待所有的executor准备好之后运行，所有在任务提交到集群之后，仍有一些executor处于启动状态。在Spark上运行的作业运行速度与executor个数相关，当可用的executor的个数没有达到最大值的时候，作业达不到最大的并行性，所有Hive上提交的第一个SQL查询会慢。

　　如果是在长时间会话这个应该问题影响很小，因为只有执行第一个SQL的时候会慢，问题不大，但是很多时候我们写的Hive脚本，需要用一些调度框架去启动（如Oozie）。这时候我们需要考虑进行优化。

　　为了减少启动时间，我们可以开启container pre-warming机制，开启后只有当任务请求的所有executor准备就绪，作业才会开始运行。这样会提升Spark作业的并行度。

 

 

转载于:https://my.oschina.net/hblt147/blog/3002333