hive调优原理详解：案例解析参数配置(第17天）

系列文章目录

一、Hive常问面试函数（掌握）
二、Hive调优如何配置（重点）

文章目录

前言

本文主要概述hive调优配置，案例解析。

一、Hive函数（掌握）

11、JSON数据处理

知识点:

 get_json_object：解析json内容
        优点：能够解析嵌套的json
        缺点：每次只能解析一个
    
 json_tuple:
        优点：每次能够同时解析多个字段
        缺点：不能解析嵌套的json。如果需要解析嵌套的，那么只能一层层解析

示例:

createdatabase day09;use day09;/*
 get_json_object：解析json内容
    优点：能够解析嵌套的json
    缺点：每次只能解析一个
 */select
     get_json_object('{"name":"zhangshan","age":18,"addr":{"province":"广东省","city":"广州市"}}','$.name')as name,
     get_json_object('{"name":"zhangshan","age":18,"addr":{"province":"广东省","city":"广州市"}}','$.addr.province')as province;/*
    json_tuple:
        优点：每次能够同时解析多个字段
        缺点：不能解析嵌套的json。如果需要解析嵌套的，那么只能一层层解析
 */select
    json_tuple('{"name":"zhangshan","age":18,"addr":{"province":"广东省","city":"广州市"}}','name','age','addr');select
    json_tuple('{"name":"zhangshan","age":18,"addr":{"province":"广东省","city":"广州市"}}','name','age','addr')as(name,age,addr);with tmp_1 as(select json_tuple('{"name":"zhangshan","age":18,"addr":{"province":"广东省","city":"广州市"}}','addr')as addr
)select get_json_object(addr,'$.province')from tmp_1;with tmp_1 as(select json_tuple('{"name":"zhangshan","age":18,"addr":{"province":"广东省","city":"广州市"}}','addr')as addr
)select json_tuple(addr,'province')from tmp_1;

12、炸裂函数

知识点：

把一个容器的多个数据炸裂出单独展示: explode(字段名称)

炸裂函数配合侧视图使用如下
格式:
    select 字段,侧视图中字段名称 from 原始表名
    lateral view UDTF函数名称(原始表名中的字段) 侧视图别名 as 侧视图中字段名称1,侧视图中字段名称
    
解释: 
    1- 侧视图别名、侧视图中字段名称自己取名字
    2- 侧视图别名前面不能有as
    3- 侧视图里面只需要定义字段名称即可，不要设置数据类型

简单示例:

use day09;-- 基础使用select array(1,2,3,4,5);select explode(array(1,2,3,4,5));select map('a',1,'b',2,'c',3);select explode(map('a',1,'b',2,'c',3));

实战：

-- NBA例子createtable nba(
    team_name string,
    year_str array<string>)row format delimited fieldsterminatedby','
collection items terminatedby'|';-- 加载导入数据loaddata inpath '/dir/The_NBA_Championship.txt'intotable nba;-- 验证数据select*from nba;-- 炸裂select explode(year_str)as`year`from nba;-- UDTF函数一般会和侧视图一起出现/*
 侧视图语法
    select 字段,侧视图中字段名称 from 原始表名
    lateral view UDTF函数名称(原始表名中的字段) 侧视图别名 as 侧视图中字段名称1,侧视图中字段名称2....
 */select team_name,yearfrom nba
lateral view explode(year_str) years asyear;-- 侧视图和json_tuple配合使用with tmp_1 as(select json_tuple('{"name":"zhangshan","age":18,"addr":{"province":"广东省","city":"广州市"}}','addr')as addr
)select json_tuple(addr,'province')from tmp_1;with tmp_1 as(select1as id,'{"name":"zhangshan","age":18,"addr":{"province":"广东省","city":"广州市"}}'as info
)select id,name,age from tmp_1
lateral view json_tuple(info,'name','age') info_view as name,age

13、高频面试题

13.1 行转列

知识点:

collect_set(字段名): 把多个数据放到一个set集合中，会对数据进行去重处理
collect_list(字段名): 把多个数据放到一个list集合中，不会对数据进行去重处理

把多个子串用指定分隔符拼接成一个大字符串: concat_ws("分隔符号",字段名称1,字段名称2..)
注意: concat_ws只能针对字符串内容进行拼接，不支持数值，需要使用cast进行类型转换。

需求:

示例:

use day09;-- 行转列createtable row_2_column(
    col1 string,
    col2 string,
    col3 int)row format delimited fieldsterminatedby'\t';-- 导入数据loaddata inpath '/dir/r2c2.txt'intotable row_2_column;-- 验证数据select*from row_2_column;-- 行转列/*
    sql编写思路：先写整体，再对局部地方进行细化。先易后难，先写你会的，再写你不会
 */describefunctionextended collect_list;select
    col1,col2,
    collect_set(col3)as set_col3s,
    collect_list(col3)as list_col3s,
    concat_ws("_",collect_list(cast(col3 as string)))as col3_str
from row_2_column
groupby col1, col2;

13.2 列转行

知识点：

把字符串按照指定分隔符切割: split(字段名称,分隔符号)

需求：

示例：

-- 列转行：explode+lateral viewcreatetable column_2_row(
    col1 string,
    col2 string,
    col3 string
)row format delimited fieldsterminatedby'\t';-- 导入数据loaddata inpath '/dir/c2r2.txt'intotable column_2_row;-- 验证数据select*from column_2_row;-- 列转行：explode+lateral viewselect
    col1,col2,new_col3
from column_2_row
lateral view explode(split(col3,",")) col3_view as new_col3;-- 细节测试语句select
    explode(split(col3,","))as col3s -- split切分以后得到是array数据类型from column_2_row;

笔试题：https://blog.csdn.net/weixin_43648241/article/details/109125978

14、开窗函数（先了解，再熟悉）

官网链接：https://cwiki.apache.org/confluence/display/ASTERIXDB/Window+Functions

14.1 基础使用

知识点：

开窗函数格式: 开窗函数 over(partition by 分组字段名 [order by 排序字段名 asc|desc] [rows between 开窗开始 and 开窗结束])

partition by: 按照谁进行分组
order by: 对分组后的数据进行排序
rows between and: 限定窗口统计数据范围

开窗函数分类:
    第一类: 编号相关。
        row_number(): 123456。不管数据有没有重复，单调递增往后进行编号
        rank(): 123446。如果遇到相同数据，那么会重复编号，并且会占用后续的编号
        dense_rank(): 123445。如果遇到相同数据，那么会重复编号，但是不会占用后续的编号
        
    第二类: 聚合函数。count()、sum()、avg()、max()、min()....
    第三类: 取值函数。ntile()、lag()、lead()、first_value()、last_value()

示例：

use day09;-- 创建表createtable pv_tb(
    cookieid string,
    datestr string,
    pv int)row format delimited fieldsterminatedby',';-- 导入数据loaddata inpath '/dir/website_pv_info.txt'intotable pv_tb;-- 验证数据select*from pv_tb;-- 编号相关的窗口函数select
    cookieid,
    datestr,
    pv,-- row_number：用的最多。单调递增的进行编号，不管重复数据
    row_number()over(partitionby cookieid orderby pv asc)as rs1,-- rank：单调递增的进行编号，如果遇到重复数据，编号是相同，同时会占用后面的编号资格
    rank()over(partitionby cookieid orderby pv asc)as rs2,-- dense_rank：单调递增的进行编号，如果遇到重复数据，编号是相同，同时不会占用后面的编号资格
    dense_rank()over(partitionby cookieid orderby pv asc)as rs3
from pv_tb;select
    cookieid,
    datestr,
    pv,
    row_number()over(partitionby cookieid orderby pv asc)as rn,-- 如果有order by那么窗口的大小是慢慢逐渐放大的sum(pv)over(partitionby cookieid orderby pv asc)as sum_result,-- 如果没有order by那么窗口的大小直接彻底放大到最大sum(pv)over(partitionby cookieid)as sum_result2
from pv_tb;

窗口的运行原理：

针对sum(pv) over(partition by cookieid order by pv asc) as sum_result语句

14.2 控制数据范围

知识点：

开窗函数控制范围: rows between 范围开始 and 范围结束

具体的语法含义:
    1- 范围开始
        unbounded preceding: 从窗口开始
        数字 preceding: 前几行数据
        
    2- 范围结束
        unbounded following: 到窗口结束
        数字 following: 后几行数据
    
    3- 特殊的，既能够作为范围开始，也能够作为范围结束
        current row: 当前行

示例：

-- 控制窗口统计的数据范围select
    cookieid,
    datestr,
    pv,sum(pv)over(partitionby cookieid orderby pv rowsbetweenunboundedprecedingandcurrentrow)as rs1,sum(pv)over(partitionby cookieid orderby pv rowsbetween2precedingandcurrentrow)as rs2,sum(pv)over(partitionby cookieid orderby pv rowsbetweenunboundedprecedingandunboundedfollowing)as rs3,sum(pv)over(partitionby cookieid orderby pv rowsbetween2precedingandunboundedfollowing)as rs4,sum(pv)over(partitionby cookieid orderby pv rowsbetween2precedingand2following)as rs5,sum(pv)over(partitionby cookieid orderby pv rowsbetweencurrentrowandunboundedfollowing)as rs6
from pv_tb;

14.3 其他开窗函数

知识点：

ntile(n): 将窗口内的数据分配到n个桶里面去，返回的结果是桶的编号。可以使用在数据抽样中

lag: 取窗口中上一行的数据
lead: 取窗口中下一行的数据

first_value: 取窗口中第一行的数据
last_value : 取窗口中最后一行的数据

示例：

-- 其他函数select
    cookieid,
    datestr,
    pv,
    row_number()over(partitionby cookieid orderby pv asc)as rn,-- ntile(n)：将窗口内的数据分配到n个桶里面去，返回的结果是桶的编号
    ntile(3)over(partitionby cookieid orderby pv asc)as rs1,-- 取窗口中上一行的数据
    lag(pv)over(partitionby cookieid orderby pv asc)as rs2,-- 取窗口中下一行的数据
    lead(pv)over(partitionby cookieid orderby pv asc)as rs3,-- 取窗口中第一行的数据
    first_value(pv)over(partitionby cookieid orderby pv asc)as rs4,-- 取窗口中最后一行的数据
    last_value(pv)over(partitionby cookieid orderby pv asc)as rs5
from pv_tb;

二、Hive调优（熟悉）

hive官方配置url: https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties

1、调优方式

hive参数配置的意义: 开发Hive应用/调优时，不可避免地需要设定Hive的参数。设定Hive的参数可以调优HQL代码的执行效率，或帮助定位问题。然而实践中经常遇到的一个问题是，为什么我设定的参数没有起作用？这是对hive参数配置几种方式不了解导致的!

hive参数设置范围（从大到小）: 配置文件 > 命令行参数 > set参数声明
hive参数设置优先级（从高优先级到低优先级）: set参数声明 > 命令行参数 > 配置文件

注意: 在工作中，推荐使用set参数声明，因为最简单最方便。而且同一个大数据集群除了你了还有其他的人或者项目组在使用。

2、hive数据压缩

Hive底层是运行MapReduce，所以Hive支持什么压缩格式本质上取决于MapReduce。

2.1 压缩对比

在后续可能会使用GZ(GZIP), 保证压缩后的数据更小, 同时压缩和解压的速度比较OK的,

但是大部分的选择主要会选择另一种压缩方案, snappy, 此种方案可以保证在合理的压缩比下, 拥有更高的解压缩的速度，在大数据领域中主要是关注数据的处理速度

http://google.github.io/snappy/
On a single core of a Core i7 processor in 64-bit mode, Snappy compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or more.

2.2 开启压缩

开启map输出阶段压缩可以减少job中map和Reduce task间数据传输量. 当Hive将输出写入到表中时，输出内容同样可以进行压缩。用户可以通过在查询语句或执行脚本中设置这个值为true，来开启输出结果压缩功能。

-- 创建数据库createdatabase hive05;-- 使用库use hive05;-- 开启压缩(map阶段或者reduce阶段)--开启hive支持中间结果的压缩方案set hive.exec.compress.intermediate;-- 查看默认set hive.exec.compress.intermediate=true;--开启hive支持最终结果压缩set hive.exec.compress.output;-- 查看默认set hive.exec.compress.output=true;--开启MR的map端压缩操作set mapreduce.map.output.compress;-- 查看默认set mapreduce.map.output.compress=true;--设置mapper端压缩的方案set mapreduce.map.output.compress.codec;-- 查看默认set mapreduce.map.output.compress.codec= org.apache.hadoop.io.compress.SnappyCodec;-- 开启MR的reduce端的压缩方案set mapreduce.output.fileoutputformat.compress;-- 查看默认set mapreduce.output.fileoutputformat.compress=true;-- 设置reduce端压缩的方案set mapreduce.output.fileoutputformat.compress.codec;-- 查看默认set mapreduce.output.fileoutputformat.compress.codec = org.apache.hadoop.io.compress.SnappyCodec;--设置reduce的压缩类型set mapreduce.output.fileoutputformat.compress.type;-- 查看默认set mapreduce.output.fileoutputformat.compress.type=BLOCK;

3、hive数据存储

3.1 行列存储原理

行存储的特点: 将数据以行的形式整体进行存放
列存储的特点: 将相同字段的值作为整体放在一起进行存放

行存储:
    优点: 如果要查询整行数据内容，速度比较快。适合进行数据的insert/update操作
    缺点: 如果数据分析的时候，只想针对某几个字段进行处理，那么这个效率低。因为会将不需要的字段内容也会加载出来
    使用: textfile和sequencefile
    
列存储: 
    优点: 如果数据分析的时候，只想针对某几个字段进行处理，那么效率高，因为你要什么，我就给你返回什么
    缺点: 如果要查询整行数据内容，速度比较慢。不适合进行数据的insert/update操作
    使用: orc和parquet。推荐使用orc
    
注意: 在工作中推荐ORC+Snappy压缩一起使用，更加能够减少HDFS的磁盘占用。
格式:
    stored as orc -- 设置数据的存储格式
    tblproperties ("orc.compress"="SNAPPY"); -- 设置数据的压缩格式

ORC

3.2 存储压缩比

-- 数据的存储和压缩方式-- textfile：占用空间18.13 MB（如果是HDFS需要乘以3）createtable log_text(
    track_time string,
    url string,
    session_id string,
    referer string,
    ip string,
    end_user_id string,
    city_id string
)ROW FORMAT DELIMITED FIELDSTERMINATEDBY'\t'
stored as textfile;-- 表默认的存储格式就是不压缩并且使用行式存储中的textfile存储-- 导入数据loaddata inpath '/dir/log.data'intotable log_text;-- 数据验证select*from log_text;selectcount(*)as cnt from log_text;-- 列式存储：ORC，占用空间2.78 MBcreatetable log_orc(
    track_time string,
    url string,
    session_id string,
    referer string,
    ip string,
    end_user_id string,
    city_id string
)ROW FORMAT DELIMITED FIELDSTERMINATEDBY'\t'
stored as orc;-- 加载数据insert overwrite table log_orc select*from log_text;selectcount(*)as cnt from log_orc;-- 列式存储：ORC+snappy。占用空间3.75 MB，这里相对ORC反而多占用了1MB空间，是因为数据量太小，同时压缩以后，压缩文件里面需要存储和压缩相关元数据信息（例如：使用的压缩算法具体是哪一个）-- https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDLcreatetable log_orc_snappy(
    track_time string,
    url string,
    session_id string,
    referer string,
    ip string,
    end_user_id string,
    city_id string
)ROW FORMAT DELIMITED FIELDSTERMINATEDBY'\t'
stored as orc -- 设置数据的存储格式
tblproperties ("orc.compress"="SNAPPY");-- 设置数据的压缩格式-- 加载数据insert overwrite table log_orc_snappy select*from log_text;selectcount(*)as cnt from log_orc_snappy;-- 列式存储：parquet。占用空间13.09MBcreatetable log_orc_parquet(
    track_time string,
    url string,
    session_id string,
    referer string,
    ip string,
    end_user_id string,
    city_id string
)ROW FORMAT DELIMITED FIELDSTERMINATEDBY'\t'
stored as parquet;-- 加载数据insert overwrite table log_orc_parquet select*from log_text;selectcount(*)as cnt from log_orc_parquet;

拓展dfs -du -h

-- 查看hdfs文件大小除了去页面查看,还可以通过命令
dfs -du -h '/user/hive/warehouse/hive05.db/log_text/log.data' ;
dfs -du -h '/user/hive/warehouse/hive05.db/log_orc/000000_0' ;
dfs -du -h '/user/hive/warehouse/hive05.db/log_orc_snappy/000000_0' ;
dfs -du -h '/user/hive/warehouse/hive05.db/log_parquet/000000_0' ;

4、fetch抓取

核心点: 在执行SQL, 能不走MR, 尽量不走MR

回想, 在之前执行什么样查询的SQL的时候,没有走MR呢?

1) 全表扫描
2) 查询某个列数据
3) 执行一些简单查询操作
4) 执行limit操作

而这些操作, 没有走MR原因, 就是hive默认以及开启本地抓取的策略方案:

hive.fetch.task.conversion:   设置本地抓取策略
可选:
    more (默认值): 可以保证在执行全表扫描、查询某几个列、简单的limit查询、简单的条件过滤不会变成MapReduce
    minimal: 可以保证在执行全表扫描、查询某几个列、简单的limit查询不会变成MapReduce
    none: 全部的HiveSQL语句都要变成MapReduce

示例:

-- 不会变成MapReduce几类SQL演示-- 默认是more,底层自动调优set hive.fetch.task.conversion;-- 默认值moreselect*from log_text;-- 全表扫描select url from log_text;-- 查询某个列的数据select*from log_text where city_id=-10;-- 简单的where过滤查询select*from log_text limit10;-- 执行limit程序select*from log_text orderby url desclimit100,10;-- 复杂limit会变成MapReduceset hive.fetch.task.conversion=minimal;set hive.fetch.task.conversion;select*from log_text;-- 全表扫描select url from log_text;-- 查询某个列的数据select*from log_text limit10;-- 执行limit程序select*from log_text where city_id=-10;-- 简单的where过滤查询set hive.fetch.task.conversion=none;set hive.fetch.task.conversion;-- 这里也要变成MapReduceselect*from log_text;-- 全表扫描select url from log_text;-- 查询某个列的数据select*from log_text limit10;-- 执行limit程序select*from log_text where city_id=-10;-- 简单的where过滤查询

5、本地模式

核心点:让MR能走本地模式, 尽量走本地MR(大白话: 小活能自己干就不要麻烦别人)

如何开启:
    set hive.exec.mode.local.auto=true;  默认值为: false

开启本地模式后, 在什么情况下执行本地MR:   只有当输入的数据满足以下两个特性后, 才会执行本地MR
    set hive.exec.mode.local.auto.inputbytes.max=51234560;    
        默认为128M。设置本地MR最大处理的数据量
    set hive.exec.mode.local.auto.input.files.max=10; 
        默认值为4。设置本地MR最大处理的文件的数量

示例:

-- 4.开启本地mr(默认false,如果小数据任务进行调优开启,小任务能自己干就自己干)set hive.exec.mode.local.auto;-- 默认关闭set hive.exec.mode.local.auto=false;-- 手动关闭set hive.exec.mode.local.auto=true;-- 手动开启--设置local mr的最大输入数据量，当输入数据量小于这个值时采用local  mr的方式，默认为134217728，即128Mset hive.exec.mode.local.auto.inputbytes.max;-- 查看set hive.exec.mode.local.auto.inputbytes.max=134217728;--设置local mr的最大输入文件个数，当输入文件个数小于这个值时采用local mr的方式，默认为4set hive.exec.mode.local.auto.input.files.max;-- 查看set hive.exec.mode.local.auto.input.files.max=4;-- 执行sql语句-- 没有开启本地执行24秒,开启后1.5秒select*from log_text orderby city_id desc;-- 注意: 有的同学开启本地模式后执行上述sql语句,会报code 2...错误-- 错误:[08S01][2] Error while processing statement: FAILED: Execution Error, return code 2 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask-- 如何解决? /export/server/hive/hive-env.sh  修改 export HADOOP_HEAPSIZE=2048-- 注意: 修改完后需要重启hive服务

6、join的优化操作

思考: 在通过hive执行多表查询的SQL, 最终hive翻译的MR,是如何完成join的工作的呢?

默认的join行为, 基于reduce端的join工作

思考, 请问上述join存在哪些问题?

1) 导致reduce的压力剧增, 所有的数据全部都打向reduce中
2) 当有了多个reduce后, 如果某个join字段的值出现大量的重复, 会导致大量key发往同一个reduce, 从而导致数据倾斜

那么如何解决reduce端join遇到问题? 可以通过底层map 端 join实现,还可以sql语句join之前提前过滤数据或者转换数据实现

通过 map join 即可解决掉 reduce join所出现的所有的问题, 也可以这么 mapjoin有解决数据倾斜的作用

存在什么弊端: 
    小表数据需要存储在内存中, 随着mapTask越多, 存储在内存的小表数据份数也会越多
        当这个小表数据比较大的, 可能无法放置到内存中

所以说, mapJoin有一定使用范围: 仅适用于小表 和大表 进行join的情况

• 1. 大表和小表进行join:- 解决方案: map join- 如何开启这种操作呢?set hive.auto.convert.join = true; -- 默认为true 开启mapJoin支持 set hive.mapjoin.smalltable.filesize= 25000000; 设置 小表的最大的数据量 23.84m- 在执行SQL, 应该将小表放置前面呢, 还是大表放置在前面呢,还是都可以呢 ?(hive1) : 要求 必须将小表在前大表在后 ,只有这样才可能走Map Join(hive2): 无所谓, 谁在前, 谁在后, 没有任何的影响, hive会自动判断
• 1. 大表和大表join- 解决方案:1) 能在join之前过滤操作, 一定要在join前过滤, 以减少join的数据量, 从而提升效率2) 如果join字段上, 有很多的空值null值,获取其他无效数据, 这些值越多 就会导致出现数据倾斜 方案一: 提前过滤掉 select * from (select * from 表1 where 字段名 is not null) 别名1 join (select * from 表2 where 字段名 is not null) 别名2 on 关联条件; 方案二: 将null值替换为随机数, 从而减少数据倾斜影响 select * from (select case when 字段名 is null then rand() else 字段名 end from 表1) 别名1 join (select case when 字段名 is null then rand() else 字段名 end from 表2) 别名2 on 关联条件;3) 基于分桶表(大文件分为多个小文件)

7、列裁剪

Hive在读数据的时候，可以只读取查询中所需要用到的列，而忽略其他列

例如:

假设有一个表A: a b c d e   5个字段, 请查看以下SQL
select  a,b from A where a=xxx;

在这条SQL, 发现没有使用c d e 字段, 在from A表时候, 读取数据, 只需要将a列 和 b列数据读取出来即可, 不需要读取cde列字段, 这样可以减少读取的数据量, 从而提升效率

如何配置呢?

-- -=【列裁剪(只读取sql语句需要的字段,节省读取开销,提升效率)set hive.optimize.cp=true;-- 默认就是true  (在hive 2.x中无需在配置了, 直接为固定值: true)

8、分区裁剪

执行查询SQL的时候, 能在join之前提前进行条件过滤的操作, 一定要提前过滤, 不要在join后进行过滤操作

如果操作的表是一张分区表, 那么建议一定要带上分区字段, 以减少扫描的数据量, 从而提升效率,

例如:

select*from A join B where A.id=xxx;
优化后:
select*from(select*from A where id= xxx) A join B;

如何配置呢?

-- 7.分区裁剪set hive.optimize.pruner=true;--默认为就是true (在hive 2.x中无需在配置了, 直接为固定值: true)

9、group by 操作（Map端聚合）

方案一:  
    （1）是否在Map端进行聚合，默认为True
    set hive.map.aggr = true;
    （2）在Map端进行聚合操作的条目数目
    set hive.groupby.mapaggr.checkinterval = 100000;

方案二:  官方称为 负载均衡
    （3）有数据倾斜的时候进行负载均衡（默认是false）
    set hive.groupby.skewindata = true;
    第一个MR Job中，Map的输出结果会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的Group By Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的；
    第二个MR Job再根据预处理的数据结果按照Group By Key分布到Reduce中（这个过程可以保证相同的Group By Key被分布到同一个Reduce中），最后完成最终的聚合操作。

10、count(distinct)

说明 : count(distinct) 在数据量比较大的情况下, 效率并不高

思考: 你知道是为什么吗?

原因如下: 
    请问1: 执行count操作的时候, hive翻译的MR, reduce数量是否可以有多个? 必然不会有多个, 只能有一个, 因为全局求最终结果
    此时如果执行统计的时候, 需要进行去重,那么去重工作是由reduce执行去重操作,  由于reduce只有一个, 所有的数据都在一个reduce中, 此时reduce的压力比较大
        
    希望执行去重工作可能有多个reduce一起来执行操作, 此时可以将SQL优化: 
        原有:
            select count(distinct ip) from ip_tab;
        优化: 
            select 
                count(ip)
            from
               (select ip from ip_tab group by ip) tmp;
    
        请注意: 这样的做法, 虽然会运行两个MR, 但是当数据量足够庞大的时候, 此操作绝对是值得的, 如果数据量比较少, 此操作效率更低

-- count(distinct)优化set hive.optimize.countdistinct;-- 默认就是trueset hive.optimize.countdistinct =true;/*
SELECT count(DISTINCT id) FROM 大表;
结果：
SELECT count(id) FROM (SELECT id FROM 大表 GROUP BY id) a;
*/selectcount(distinct devicetype)from device1;selectcount(devicetype)from(select devicetype from device1 groupby devicetype) a;-- 注意: 小表拆分两个mr反而效率低,以后大表的时候才会真正提升效率

11、笛卡尔积

什么是笛卡尔积呢? 在进行join的时候, 两个表乘积之后结果就是笛卡尔积的结果

比如: 一个表有5条, 一个表有3条数据, 笛卡尔积结果就有15条数据 , 笛卡尔积中有大量数据都是无用数据

什么时候会产生笛卡尔积呢?

在多表join的时候, 关联条件缺少或者使用错误的关联条件以及将关联条件放置在where中都会导致笛卡尔积

在实际使用中, 建议:

12、动态分区

需求: 请将下面的一个分区表数据, 拷贝到另一个分区表, 保证对应区数据放置到另一个表的对应区下

如何配置呢?

作用:  帮助一次性灌入多个分区的数据
参数: 
    set hive.exec.dynamic.partition.mode=nonstrict;  -- 开启非严格模式 默认为 strict(严格模式)
    set hive.exec.dynamic.partition=true;  -- 开启动态分区支持, 默认就是true
    
可选的参数:
    set  hive.exec.max.dynamic.partitions=1000; -- 在所有执行MR的节点上，最大一共可以创建多少个动态分区。
    set hive.exec.max.dynamic.partitions.pernode=100; -- 每个执行MR的节点上，最大可以创建多少个动态分区
    set hive.exec.max.created.files=100000; -- 整个MR Job中，最大可以创建多少个HDFS文件

示例:

13、如何调整map和reduce的数量

1>是不是map数越多越好？
答案是否定的。如果一个任务有很多小文件（远远小于块大小128m），则每个小文件也会被当做一个块，用一个map任务来完成，而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。而且，同时可执行的map数是受限的。

2>是不是保证每个map处理接近128m的文件块，就高枕无忧了？
答案也是不一定。比如有一个127m的文件，正常会用一个map去完成，但这个文件只有一个或者两个小字段，却有几千万的记录，如果map处理的逻辑比较复杂，用一个map任务去做，肯定也比较耗时。

3>是不是reduce数越多越好？
答案是否定的。如果reduce设置的过大，对整个作业会产生一定的影响。
①过多的启动和初始化reduce也会消耗时间和资源；
②另外，有多少个reduce，就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题；

4>在什么情况下, 只能有一个reduce呢?

以下几种, 不管如何设置, 最终翻译后reduce只能有一个
​ 1) 执行order by操作
​ 2) 执行不需要group by直接聚合的操作
​ 3) 执行笛卡尔积

• 如何调整mapTask数量:小文件场景:当input的文件都很小,把小文件进行合并归档,减少map数, 设置map数量:-- 每个Map最大输入大小(这个值决定了合并后文件的数量)set mapred.max.split.size=256000000;-- 一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并)set mapred.min.split.size.per.node=1;-- 一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并)set mapred.min.split.size.per.rack=1;-- 执行Map前进行小文件合并默认CombineHiveInputFormatset hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;大文件场景:当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，可以考虑增加Map数，来使得每个map处理的数据量减少，从而提高任务的执行效率。> 举例:如果表a只有一个文件，大小为120M，但包含几千万的记录，如果用1个map去完成这个任务，肯定是比较耗时的，> ​ 这种情况下，我们要考虑将这一个文件合理的拆分成多个，这样就可以用多个map任务去完成。> ​ set mapred.reduce.tasks=10;> ​ create table a_1 as select * from tab_info distribute by rand(123);> ​ 这样会将a表的记录，随机的分散到包含10个文件的a_1表中，再用a_1代替上面sql中的a表，则会用10个map任务去完成。
• 如何reduce的数量:-- 查看reduces数量-- 该值默认为-1，由hive自己根据任务情况进行判断。set mapred.reduce.tasks;set mapreduce.job.reduces;-- （1）每个Reduce处理的数据量默认是256MB左右set hive.exec.reducers.bytes.per.reducer=256000000;-- （2）每个任务最大的reduce数，默认为1009;set hive.exec.reducers.max=1009;

14、并行执行

​ 在执行一个SQL语句的时候, SQL会被翻译为MR, 一个SQL有可能被翻译成多个MR, 那么在多个MR之间, 有些MR之间可能不存在任何的关联, 此时可以设置让这些没有关联的MR 并行执行, 从而提升效率 , 默认是 一个一个来

如何配置:

set hive.exec.parallel=false;--打开任务并行执行,默认关闭set hive.exec.parallel.thread.number=8;--同一个sql允许最大并行度，默认为8。

前提:
    服务器必须有资源, 如果没有 即使支持并行, 也没有任何作用

案例:

select  * from A ....
union all
select * from B ...;

例如:
    select from (select * from A group by ...) tmp1 join (select * from B group by xxx) on ...

15、严格模式

​ hive提供一种严格模式, 主要目的, 是为了限制一些 效率极低的SQL 放置其执行时间过长, 影响其他的操作

屏蔽一下操作:
1) 执行order by 不加 limit
2) 出现笛卡尔积的现象SQL
3) 查询分区表, 不带分区字段

前提: 数据量足够大, 如果数据量比较少, 严格模式对此三项内容不生效

如何配置:

set hive.mapred.mode= strict;--开启严格模式 set hive.mapred.mode= nostrict;--开启非严格模式   最新默认

16、JVM 重用

此操作, 在hive2.x已经不需要配置了, 默认支持

jvm重用: 默认情况下, container资源容器  只能使用一次,不能重复使用, 开启JVM重用, 运行container容器可以被重复使用,在hive2.x已经默认支持了

17、推测执行

Hadoop采用了推测执行（Speculative Execution）机制，它根据一定的法则推测出“拖后腿”的任务，并为这样的任务启动一个备份任务，让该任务与原始任务同时处理同一份数据，并最终选用最先成功运行完成任务的计算结果作为最终结果。
hadoop中默认两个阶段都开启了推测执行机制。
hive本身也提供了配置项来控制reduce-side的推测执行：

set hive.mapred.reduce.tasks.speculative.execution=true;

关于调优推测执行机制，还很难给一个具体的建议。如果用户对于运行时的偏差非常敏感的话，那么可以将这些功能关闭掉。如果用户因为输入数据量很大而需要执行长时间的map或者Reduce task的话，那么启动推测执行造成的浪费是非常巨大。

18、执行计划explain

使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。帮助我们了解底层原理,hive调优,排查数据倾斜等有很有帮助 

使用示例：explain [...]  sql查询语句;

explain sql语句: 查看执行计划的基本信息

（1）stage dependencies：各个stage之间的依赖性
包含多个stage阶段,例如 Stage-1和Stage-0，Stage-1 是根stage，Stage-0 依赖 Stage-1，
（2）stage plan：各个stage的执行计划
包含两部分: map端执行计划树和reduce端执行计划树