数据分析课程笔记 - 19 - HiveSQL 常用优化技巧

大家好呀,这节课学习 HiveSQL 的常用优化技巧。由于 Hive 主要用来处理非常大的数据,运行过程由于通常要经过 MapReduce 的过程,因此不像 MySQL 一样很快出结果。而使用不同方法写出来的 HiveSQL 语句执行效率也是不一样的,因此为了减少等待的时间,提高服务器的运行效率,我们需要在 HiveSQL 的语句上进行一些优化。

本节课的主要内容

引言
1、技巧一:列裁剪和分区裁剪
(1)列裁剪
(2)分区裁剪
2、技巧二:排序技巧——sort by代替order by
3、技巧三:去重技巧——用group by来替换distinct
4、技巧四:聚合技巧——grouping sets、cube、rollup
(1)grouping sets
(2)cube
(3)rollup
5、技巧五:换个思路解题
6、技巧六:union all时可以开启并发执行
7、技巧七:表连接优化
8、技巧八:遵循严格模式

引言

Hive 作为大数据领域常用的数据仓库组件,在平时设计和查询时要特别注意效率。影响Hive效率的几乎从不是数据量过大,而是数据倾斜、数据冗余、job 或 I/O 过多、MapReduce 分配不合理等等。对 Hive 的调优既包含对HiveSQL 语句本身的优化,也包含 Hive 配置项和 MR 方面的调整。

技巧一:列裁剪和分区裁剪

1、列裁剪

列裁剪就是在查询时只读取需要的列。当列很多或者数据量很大时,如果select 所有的列或者不指定分区,导致的全表扫描和全分区扫描效率都很低。Hive中与列裁剪优化相关的配置项是 hive.optimize.cp,默认是 true

2、分区裁剪

分区裁剪就是在查询时只读需要的分区。Hive中与分区裁剪优化相关的则是 hive.optimize.pruner,默认是 true

技巧二:排序技巧——sort by 代替 order by

HiveSQL中的 order by 与其他 SQL 语言中的功能一样,就是将结果按某个字段全局排序,这会导致所有map端数据都进入一个 reduce 中,在数据量大时可能会长时间计算不完。

如果使用 sort by,那么就会视情况启动多个 reducer 进行排序,并且保证每个 reducer 内局部有序。为了控制 map 端数据分配到 reduce 的 key,往往还要配合 distribute by 一同使用。如果不加 distribute by 的话,map 端数据就会随机分配给 reducer。

-- 未优化写法
select a,
    b,
    c
from table
where xxx
order by a
limit 10;

-- 优化写法
select a,
    b,
    c
from table
where xxx
distribute by user_id
sort by a
limit 10;

这里需要解释一下,distribute bysort by 结合使用是如何相较于 order by 提升运行效率的。

假如我们要对一张很大的用户信息表按照年龄进行分组,优化前的写法是直接 order by age。使用 distribute bysort by 结合进行优化的时候,sort by 后面还是 age 这个排序字段,distribute by 后面选择一个没有重复值的均匀字段,比如 user_id

这样做的原因是,通常用户的年龄分布是不均匀的,比如20岁以下和50岁以上的人非常少,中间几个年龄段的人又非常多,在 Map 阶段就会造成有些任务很大,有些任务很小。那通过 distribute by 一个均匀字段,就可以让系统均匀地进行“分桶”,对每个桶进行排序,最后再组合,这样就能从整体上提升 MapReduce 的效率。

技巧三:去重技巧——用 group by 来替换 distinct

取出 user_trade 表中全部支付用户:

user_trade表结构
-- 原有写法
SELECT distinct user_name
FROM user_trade
WHERE dt>'0';

-- 优化写法
SELECT user_name
FROM user_trade
WHERE dt>'0'
GROUP BY user_name;

原有写法的执行时长:

image.png

优化写法的执行时长:

image.png

考虑对之前的案例进行优化:

-- 在2019年购买后有退款的用户

--优化前
SELECT a.user_name
FROM
    (SELECT distinct user_name
    FROM user_trade
    WHERE year(dt)=2019)a
    JOIN
    (SELECT distinct user_name
    FROM user_refund
    WHERE year(dt)=2019)b 
    on a.user_name=b.user_name;

-- 优化写法:
SELECT a.user_name
FROM
    (SELECT user_name
    FROM user_trade
    WHERE year(dt)=2019
    GROUP BY user_name)a
    JOIN
    (SELECT user_name
    FROM user_refund
    WHERE year(dt)=2019
    GROUP BY user_name)b 
    on a.user_name=b.user_name;

注意: 在极大的数据量(且很多重复值)时,可以先 group by 去重,再count() 计数,效率高于直接 count(distinct **)

技巧四:聚合技巧——grouping sets、cube、rollup

1、grouping sets

如果我们想知道用户的性别分布、城市分布、等级分布,你会怎么写?

user_info表结构

通常写法:

--性别分布--
SELECT sex,
    count(distinct user_id)
FROM user_info
GROUP BY sex;

--城市分布--
SELECT city,
    count(distinct user_id)
FROM user_info
GROUP BY city;

--等级分布--
SELECT level,
    count(distinct user_id)
FROM user_info
GROUP BY level;

缺点:要分别写三次SQL,需要执行三次,重复工作,且费时。

那该怎么优化呢?

-- 性别、城市、等级用户分布
SELECT sex,
    city,
    level,
count(distinct user_id)
FROM user_info
GROUP BY sex,city,level
GROUPING SETS (sex,city,level);
-- grouping sets指定分组的维度
结果

注意:这个聚合结果相当于纵向地堆在一起了(Union all),分类字段用不同列来进行区分,也就是每一行数据都包含 4 列,前三列是分类字段,最后一列是聚合计算的结果。

GROUPING SETS():在 group by 查询中,根据不同的维度组合进行聚合,等价于将不同维度的 group by 结果集进行 union all。聚合规则在括号中进行指定。

拓展

如果我们想知道用户的性别分布以及每个性别的城市分布,你会怎么写?

-- 性别分布
SELECT sex,
    count(distinct user_id)
FROM user_info
GROUP BY sex;

-- 每个性别的城市分布
SELECT sex,
    city,
    count(distinct user_id)
FROM user_info
GROUP BY sex,
    city;

那该怎么优化呢?

-- 性别、性别&城市的用户分布
SELECT sex,
city,
count(distinct user_id)
FROM user_info
GROUP BY sex,city
GROUPING SETS (sex,(sex,city));
image.png

注意: 第二列为NULL的,就是性别的用户分布,其余有城市的均为每个性别的城市分布。

2、cube

cube:根据 group by 维度的所有组合进行聚合

-- 性别、城市、等级的各种组合的用户分布
SELECT sex,
    city,
    level,
    count(distinct user_id)
FROM user_info
GROUP BY sex,city,level
GROUPING SETS (sex,city,level,(sex,city),(sex,level),(city,level),(sex,city,level));

-- 优化写法

-- 性别、城市、等级的各种组合的用户分布--
SELECT sex,
    city,
    level,
    count(distinct user_id)
FROM user_info
GROUP BY sex,city,level
with cube;

注意:跑完数据后,整理很关键!!!

3、rollup

rollup:以最左侧的维度为主,进行层级聚合,是cube的子集。

如果我想同时计算出,每个月的支付金额,以及每年的总支付金额,该怎么办?

-- 优化前的写法
SELECT a.dt,
    sum(a.year_amount),
    sum(a.month_amount)
FROM
    (SELECT substr(dt,1,4) as dt,
        sum(pay_amount) year_amount,
        0 as month_amount
    FROM user_trade
    WHERE dt>'0'
    GROUP BY substr(dt,1,4)
    UNION ALL
    SELECT substr(dt,1,7) as dt,
        0 as year_amount,
        sum(pay_amount) as month_amount
    FROM user_trade
    WHERE dt>'0'
    GROUP BY substr(dt,1,7)
    ) a
GROUP BY a.dt;
image.png

那应该如何优化呢?

-- 优化写法
SELECT year(dt) as year,
    month(dt) as month,
    sum(pay_amount)
FROM user_trade
WHERE dt>'0'
GROUP BY year(dt),
    month(dt)
    with rollup;
-- 相当于grouping sets(year,(year,month))
image.png

技巧五:换个思路解题

条条大路通罗马,写SQL亦是如此,能达到同样效果的SQL有很多种,要学会思路转换,灵活应用。

来看一个我们之前做过的案例:

--在2017年和2018年都购买的⽤户--
SELECT a.user_name
FROM
    (SELECT distinct user_name
    FROM user_trade
    WHERE year(dt)=2017)a
    JOIN
    (SELECT distinct user_name
    FROM user_trade
    WHERE year(dt)=2018)b on
    a.user_name=b.user_name;

有没有别的写法呢?

-- 方式一
SELECT a.user_name
FROM
    (SELECT user_name,
        count(distinct year(dt)) as year_num
    FROM user_trade
    WHERE year(dt) in (2017,2018)
    GROUP BY user_name) a
WHERE a.year_num=2;

-- 方式二
SELECT user_name,
    count(distinct year(dt)) as year_num
FROM user_trade
WHERE year(dt) in (2017,2018)
GROUP BY user_name
having count(distinct year(dt))=2;

技巧六:union all 时可以开启并发执行

Hive 中互相没有依赖关系的 job 间是可以并行执行的,最典型的就是
多个子查询union all。在集群资源相对充足的情况下,可以开启并
行执行。参数设置:set hive.exec.parallel=true;

-- 每个用户的支付和退款金额汇总
SELECT a.user_name,
    sum(a.pay_amount),
    sum(a.refund_amount)
FROM
    ( SELECT user_name,
        sum(pay_amount) as pay_amount,
        0 as refund_amount
    FROM user_trade
    WHERE dt>'0'
    GROUP BY user_name
    UNION ALL
    SELECT user_name,
        0 as pay_amount,
        sum(refund_amount) as refund_amount
    FROM user_refund
    WHERE dt>'0'
    GROUP BY user_name
    ) a
GROUP BY a.user_name;

时间对比:

image.png

技巧七:表连接优化

  • 小表在前,大表在后
    Hive假定查询中最后的一个表是大表,它会将其它表缓存起来,然后扫描最后那个表。
  • 使用相同的连接键
    当对3个或者更多个表进行join连接时,如果每个on子句都使用相同的连接键的话,那么只会产生一个MapReduce job。
  • 尽早的过滤数据
    减少每个阶段的数据量,对于分区表要加分区,同时只选择需要使用到的字段。

技巧八:遵循严格模式

所谓严格模式,就是强制不允许用户执行3种有风险的 HiveSQL 语句,一旦执行会直接报错。

  • 查询分区表时不限定分区列的语句(例如 where dt)。
  • 两表 join 产生了笛卡尔积的语句(不写连接条件就会产生笛卡尔积)。
  • 要 order by 来排序但没有指定 limit 的语句。

要开启严格模式,需要将参数 hive.mapred.mode 设为 strict

好啦,这节课的内容就是这些。以上优化技巧需要大家在平时的练习和使用中有意识地去注意自己的语句,不断改进,就能掌握最优的写法。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容