HiveSQL调优06

本文详细介绍了Hive中的窗口函数及其应用、参数设置技巧、存储和压缩方式选择,以及一系列性能调优方法,包括Fetch抓取、本地模式、JOIN优化、SQL优化、动态分区等。
摘要由CSDN通过智能技术生成

1.窗口函数--结合其它函数使用

1. LAG 用于统计窗口内往上第n行值

2. LEAD 用于统计窗口内往下第n行值

3. FIRST_VALUE 取分组内排序后,截止到当前行,第一个值

4. LAST_VALUE  取分组内排序后,截止到当前行,最后一个值

2.Hive参数设置问题

1. set方式, 格式为:   set 属性名=属性值;

2. 命令行方式, 就是在启动 hiveserver2服务的时候, 设置的参数.

3. 配置文件方式.

3.Hive调优--存储和压缩方式

1.Hive压缩方式:

 2.Hive表存储方式

3.代码演示 压缩协议 + 存储方式

1. 开启hive的压缩方式.

2.开启MR的mapper端压缩操作

3.设置reduce端压缩的方案

4.建表: 默认压缩协议(无) + 默认的存储方式(textfile)

5. 建表: 列存储(Orc) + Orc自带的压缩协议(Zlib)

6. 给上述的 log_orc表添加数据.

8.列存储orc + 指定压缩协议: snappy

9. 插数据.

4.Hive调优--Fetch抓取

5.Hive调优--本地模式

6.Hive调优--join优化

7.Hive调优--SQL优化

1. 列裁剪.

2. 分区裁剪

3. 开启负载均衡.

4.关于去重统计的问题.

5.关于笛卡尔积.

8.Hive调优--动态分区

9.Hive调优--并行度和并行执行机制

10.Hive调优--严格模式

11.Hive调优--JVM重用

12.Hive调优--推测执行

13.Hive调优--explain执行计划

14.Hive调优--总结


1.窗口函数--结合其它函数使用

1. LAG 用于统计窗口内往上第n行值

需求: 显示用户上一次的访问时间.

获取上1个createtime列的值,  根据cookieid分组   根据createtime升序排列

 lag(createtime) over(partition by cookieid order by createtime) lag_time
from
    website_url_info;

根据cookieID分组, createtime升序排序, 获取当前行 向上2行的createtime列的值, 找不到就用默认值(张三)填充.

select
    *,
     获取createtime列向上第2个值, 如果没有就用 张三 作为默认值进行填充.
     参1: 要操作的列,   参2: 向上第几个.  参3: 默认值.
    lag(createtime, 2, '张三') over(partition by cookieid order by createtime) lag_time2
from
    website_url_info;

2. LEAD 用于统计窗口内往下第n行值

select
    *,
     获取createtime列向上第2个值, 如果没有就用 张三 作为默认值进行填充.
     参1: 要操作的列,   参2: 向下第几个.  参3: 默认值.
    lead(createtime, 2, '张三') over(partition by cookieid order by createtime) lead_time
from
    website_url_info;

3. FIRST_VALUE 取分组内排序后,截止到当前行,第一个值

select
    *,
    first_value(createtime) over(partition by cookieid order by createtime) first_time
from
    website_url_info;

4. LAST_VALUE  取分组内排序后,截止到当前行,最后一个值

select
    *,
    last_value(createtime) over(partition by cookieid order by createtime) last_time
from
    website_url_info;

2.Hive参数设置问题

Hive的参数设置问题:

hive的参数配置, 就是在那里配置hive的参数信息, 根据配置地方不同, 作用范围也不一样.

配置方式:

 1. set方式进行设置.
 2. 命令行方式进行设置.
 3. 配置文件方式进行设置.

实际开发中, 推荐使用 set方式进行临时设置.

优先级问题:

set方式 > 命令行方式 > 配置文件方式
作用范围:
set方式 < 命令行方式 < 配置文件方式

1. set方式, 格式为:   set 属性名=属性值;

 例如: set mapreduce.job.reduces=n;

2. 命令行方式, 就是在启动 hiveserver2服务的时候, 设置的参数.

nohup hive --service hiveserver2 --hiveconf hive.root.logger=DEBUG,console &

3. 配置文件方式.

就是去node1机器中修改  /export/server/hive/conf/hive-site.xml  hive-default.xml文件

3.Hive调优--存储和压缩方式

1.Hive压缩方式:

压缩方式就类似于windows的压缩包, 可以降低传输, 提高磁盘利用率.

区分压缩协议好坏的参考维度:

1. 压缩比, 即: 压缩后文件大小.
2. 解压速度, 即: 读的速度.
3. 压缩速度, 即: 写的速度.

推荐使用:

GZIP:       压缩后文件相对较小, 压缩 和 解压速度相对较慢.
Snappy:     压缩后文件相对大一点, 压缩 和 解压速度非常快.

问题: 建表的时候, 如何指定压缩方式呢?

答案: tblproperties('com.precess'='snappy');

 2.Hive表存储方式

分为 行存储 和 列存储两种.   

具体划分:

行存储: TextFile(默认), SequenceFile
列存储: ORC(推荐), Parquet

面试题: 行存储 和 列存储的区别?

        行存储:
            优点:  select * 效率高.
            缺点:  select 列 效率低,  每列数据类型不一致, 密集度较低, 占用资源较多(CPU, 磁盘, 内存)
        列存储:
            优点: select 列 效率高,  每列数据类型一致, 密集度较高, 占用资源较少(CPU, 磁盘, 内存)
            缺点: select * 效率低.
结论:
        以后建表, 不知道具体如何选择的时候, 推荐: orc(列存储) + snappy(压缩协议)

3.代码演示 压缩协议 + 存储方式

1. 开启hive的压缩方式.

开启hive支持中间结果的压缩方案
set hive.exec.compress.intermediate=true ;
开启hive支持最终结果压缩
set hive.exec.compress.output=true;

2.开启MR的mapper端压缩操作

set mapreduce.map.output.compress=true;
设置mapper端压缩的方案
set mapreduce.map.output.compress.codec= org.apache.hadoop.io.compress.SnappyCodec;
开启MR的reduce端的压缩方案
set mapreduce.output.fileoutputformat.compress=true;

3.设置reduce端压缩的方案

set mapreduce.output.fileoutputformat.compress.codec = org.apache.hadoop.io.compress.SnappyCodec;
设置reduce的压缩类型
set mapreduce.output.fileoutputformat.compress.type=BLOCK;

4.建表: 默认压缩协议(无) + 默认的存储方式(textfile)

drop table if exists log_text;
create table if not exists log_text  (
    track_time string,
    url string,
    session_id string,
    referer string,
    ip string,
    end_user_id string,
    city_id string
)
row format delimited fields terminated by '\t'
stored as textfile ;        
该行可以省略不写, 默认就是: textfile(行存储)
给上述的 log_text表上传数据, 然后查看结果.
select * from log_text;  表内有10W条数据, 18.13 MB, 而且我们可以直接在HDFS中查看文件内容.

5. 建表: 列存储(Orc) + Orc自带的压缩协议(Zlib)

drop table if exists log_orc;
create table if not exists log_orc (
    track_time string,
    url string,
    session_id string,
    referer string,
    ip string,
    end_user_id string,
    city_id string
)
row format delimited fields terminated by '\t'
stored as orc ;    
orc(列存储)

6. 给上述的 log_orc表添加数据.

列存储方式的表, 不支持load data直接加载数据, 只能 insert into的方式插入.
insert into table log_orc select * from log_text;
然后查看结果.
select * from log_orc;      表内有10W条数据, 2.78 MB, 我们不可以直接在HDFS中查看文件内容.

8.列存储orc + 指定压缩协议: snappy

drop table if exists log_orc_snappy;
create table if not exists 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 fields terminated by '\t'
stored as orc tblproperties('orc.compress'='snappy');        -- orc(列存储) + snappy协议

9. 插数据.

列存储方式的表, 不支持load data直接加载数据, 只能 insert into的方式插入.
insert into table log_orc_snappy select * from log_text;

4.Hive调优--Fetch抓取

核心点:

在执行HiveSQL的时候, 能不转MR, 就不转MR.

设置方式:

set hive.fetch.task.conversion=fetch抓取的模式;

Fetch抓取模式介绍:

more:       默认的, 全表扫描, 查询指定的列, limit分页查询, 简单查询不走MR, 其它的要转MR任务.
minimal:    全表扫描, 查询指定的列, limit分页查询不走MR, 其它的要转MR任务.
    none:       所有的HiveSQL, 底层都要转MR.

5.Hive调优--本地模式

核心点:

如果HiveSQL必须要转成MR任务来执行, 则尽量在本机(本地)直接执行, 而不是交由Yarn来调度执行, 针对于数据量比较小的需求, 可以提高效率.

相关设置:

开启本地mr
set hive.exec.mode.local.auto=true;
设置local mr的最大输入数据量,当输入数据量小于这个值时采用local  mr的方式,默认为134217728,即128M
set hive.exec.mode.local.auto.inputbytes.max=134217728;
设置local mr的最大输入文件个数,当输入文件个数小于这个值时采用local mr的方式,默认为4
set hive.exec.mode.local.auto.input.files.max=4;

6.Hive调优--join优化

小表join大表:

开启Map段的join, 在内存中完成处理, 避免把join的动作交给ReduceTask段来处理, 出现数据倾斜的情况.
参考如下配置, 即: 设置map端join
set hive.auto.convert.join = true;              -- 默认为true  开启mapJoin支持
set hive.mapjoin.smalltable.filesize= 25000000; --设置 小表的最大的数据量  20多M

大表join大表:

思路1: 空key过滤, 降低处理的数据量.
思路2: 空key转换, 必须大量的null值, 提高数据的处理数据.

7.Hive调优--SQL优化

1. 列裁剪.

能写 select 列1, 列2... 就不要写 select *

2. 分区裁剪

编写SQL的时候, 能使用分区条件, 建立一定要写分区字段.

3. 开启负载均衡.

    如果key分布不均, 就可能导致数据倾斜的问题(Group by数据倾斜), 可以通过 开启负载均衡解决.
    开启负载均衡之后, 如果遇到了GroupBy数据倾斜问题, 程序的底层会开启两个MR任务,
    第1个MR负责将(发生数据倾斜的)数据随机打散, 交由不同的ReduceTask任务来处理, 获取结果.
    第2个MR会将 第1个MR的结果当做数据源来处理, 进行最终的合并动作, 获取最终结果.
    开启负载均衡的代码如下:
    set hive.groupby.skewindata=true;

4.关于去重统计的问题.

   如果数据量相对较小, 可以直接写: select count(distinct id列) from 表名; 去重统计, 底层会转成1个MR任务.
    如果数据量相对较大, 上述的SQL语句, 可能会执行失败, 就可以通过 group by + count的思路来解决, 具体如下:
    select count(id列) from (select id from 表名 group by id) t1; 底层会转2个MR任务.

5.关于笛卡尔积.

    实际开发中, 尽量避免出现笛卡尔积的情况, 可以节约资源, 提高查询效率.
    例如:
        1. 写join连接的时候, 别忘记写关联条件, 且关联条件别写错.
        2. 关联条件尽量写到on中, 而不是where中, 即: 尽量使用显式连接, 而不是隐式内连接.
        3. 如果join的时候, 关联字段不清楚, 记得找 业务人员, 需求方, 数据库管理员对接.

8.Hive调优--动态分区

 建议动态分区的时候, 关闭严格模式(默认开启), 严格模式要求: 动态分区的时候, 至少指定1个静态分区.
格式:
    动态分区: partition(分区字段)
    静态分区: partition(分区字段=值)

重点参数:

  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文件

9.Hive调优--并行度和并行执行机制

并行度解释:

    即: 根据业务要求, 增大或者减少MapTask 和 ReduceTask的任务数.
    例如: 大量的小文件, 就会有大量的Block块, 就有大量的MapTask任务, 针对于这种情况: 我们可以使用归档技术, 把多个小文件合并成1个大文件, 降低MapTask任务数.
    例如: 1个Block块 = 1个MapTask任务, 但是业务逻辑较复杂, 1个MapTask处理速度肯定较慢, 可以增大MapTask任务数.
    例如: 1个ReduceTask任务 = 1个最终的结果文件, 增大或者减少ReduceTask任务数, 可以调整最终落盘到磁盘上的结果文件数.
并行执行:
    默认Hive同一时间只能执行1个阶段, 如果多个阶段之间的依赖度比较低, 就可以开启并行执行, 让多个阶段同时执行, 降低MR job任务的执行时间.
        set hive.exec.parallel=true;                -- 打开任务并行执行 默认false
        set hive.exec.parallel.thread.number=16;    -- 同一个sql允许最大并行度,默认为8。

10.Hive调优--严格模式

核心点:

禁用低效的SQL.
设置方式:
    set hive.mapred.mode=strict | nonstrict;
细节:
    1. 这个严格模式是禁用低效的SQL, 和动态分区的严格模式没有任何关系.
    2. 严格模式是禁用低效的SQL, 例如, 如下的SQL是禁止执行的:
        A. 分区表, 查询时, 没有写分区字段.
        B. order by全局排序时, 没有写limit
        C. 禁用笛卡尔积.

11.Hive调优--JVM重用

核心点:

    当MR任务执行结束后, Yarn创建的Container资源容器不会立即销毁, 而是可以重复使用.
原因:
    如果遇到大量生命周期短的MR任务时, 频繁的创建和销毁Container资源容器是非常消耗资源的.

12.Hive调优--推测执行

核心点:

    类似于木桶效应(装多少水取决于最短的哪个木板), job任务执行多长时间, 取决于执行最慢的哪个任务.
    针对于这种情况, 可以基于哪些"拖后腿"(执行速度过于慢)的任务, 可以搞1个它的备份任务, 让这个备份任务,
    和它处理同一份数据, 谁先执行完毕, 就将其结果作为最终结果.
建议:
    默认是开启的, 建议关闭, 具体: 看需求.

13.Hive调优--explain执行计划

格式:

explain HiveSQL语句
作用:
    可以查看HiveSQL语句的执行计划, 即: 把该SQL分成了几个阶段来执行, 阶段越少, 相对执行速度越快.

14.Hive调优--总结

Hive调优总结:

    1. 改硬件.
    2. 开启或者增大某些设置(配置).      负载均衡, 严格模式(禁用低效SQL), 动态分区数...
    3. 关闭或者减小某些设置(配置).      严格模式(动态分区), 推测执行...
    4. 减少IO传输.                   Input(输入)/Output(输出),  列存储orc, 压缩协议snappy, join优化

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值