0
点赞
收藏
分享

微信扫一扫

Hive SQL 开发指南(三)优化及常见异常

在大数据领域,Hive SQL 是一种常用的查询语言,用于在 Hadoop上进行数据分析和处理。为了确保代码的可读性、维护性和性能,制定一套规范化的 Hive SQL 开发规范至关重要。本文将介绍 Hive SQL 的基础知识,并提供一些规范化的开发指南,帮助您高效地编写 Hive SQL 查询。

本系列分为

Hive SQL 开发指南(一)数据类型及函数

Hive SQL 开发指南(二)使用(DDL、DML,DQL)

Hive SQL 开发指南(三)优化及常见异常


一、执行日志

在使用Hive进行数据查询和处理时,执行日志是一个重要的组成部分,它帮助开发者和管理员理解SQL执行的细节、性能瓶颈以及可能出现的错误。

1. 开启和查看执行日志

  • Hive CLI(命令行界面):在Hive CLI中执行SQL时,可以直接在控制台输出中看到日志信息。
  • Beeline:使用Beeline连接Hive时,也可以设置不同的日志级别来查看执行过程中的详细信息。
  • HiveServer2日志:如果通过HiveServer2服务执行SQL,可以在HiveServer2的日志文件中找到执行日志。
  • YARN日志:对于提交到YARN上运行的Hive作业,可以通过YARN的ResourceManager界面或使用yarn logs -applicationId <应用ID>命令来查看详细的执行日志。

2. 日志级别
Hive支持不同的日志级别,这些级别从详细到简洁依次为:DEBUG、INFO、WARN、ERROR。在调试SQL性能问题或错误时,DEBUG或INFO级别的日志通常最为有用,但它们会产生大量的输出。在生产环境中,通常使用WARN或ERROR级别以减少日志文件的大小。

3. 配置日志级别
日志级别可以通过多种方式配置:

  • 在Hive CLI或Beeline中临时设置:可以在启动Hive CLI或Beeline时通过--hiveconf hive.root.logger=INFO,console这样的参数来设置日志级别。
  • 修改Hive配置文件:在hive-site.xml中设置hive.root.logger属性来全局改变日志级别。
     

二、提前过滤数据

尽量尽早地过滤数据,减少每个阶段的数据量,对于分区表要加分区,同时只选择需要使用到的字段。

select ... from A
join B
on A.key = B.key
where A.userid>10
     and B.userid<10
     and A.dt='20220417'
     and B.dt='20220417';
-- 应该改写为:
select .... from (select .... from A
                  where dt='202200417'
                    and userid>10
                              ) a
join ( select .... from B
       where dt='202200417'
         and userid < 10   
     ) b
on a.key = b.key;

三、慎用Map Join

慎重使用mapjoin,一般行数小于2000行,大小小于25M(扩容后可以适当放大)的表才能使用,小表要注意放在join的左边。否则会引起磁盘和内存的大量消耗

四、禁止使用笛卡尔积

笛卡尔积只有1个reduce任务,会导致计算超慢,甚至可能计算不出来或者导致节点挂掉。

五、列修剪和分区修剪

在读数据的时候,只读取查询中需要用到的列,而忽略其他列。例如,对于查询:

SELECT a,b FROM T WHERE e < 10;

其中,T 包含 5 个列 (a,b,c,d,e),列 c,d 将会被忽略,只会读取a, b, e 列

在查询的过程中减少不必要的分区。例如,对于下列查询:

SELECT * FROM (SELECT c1, COUNT(1)
  FROM T GROUP BY c1) subq
  WHERE subq.prtn = 100;

SELECT * FROM T1 JOIN
  (SELECT * FROM T2) subq ON (T1.c1=subq.c2)
  WHERE subq.prtn = 100;

会在子查询中就考虑 subq.prtn = 100 条件,从而减少读入的分区数目。

六、explain的使用

explain命令对于我们优化查询语句很重要,针对某些查询语句,我们可以通过它查看各个执行计划,针对耗时的地方,优化之。

语法

EXPLAIN [ EXTENDED | FORMATTED | DEPENDENCY | LOGICAL | AUTHORIZATION |  VECTORIZATION | ANALYZE ] query

 七、union all 改写成join 

当需要把几个数据集的结果合并时,能使用join的话就不要使用union all。因为使用union all时通常需要加入大量的0,这会导致中间结果膨胀,增加系统负担。

八、数据膨胀导致reduce任务数不合理

数据膨胀很多时候也会导致reduce任务个数过少。reduce数目是否合理,可以从任务的mr监控页面发现端倪。请注意job监控页面的一个参数:

一般情况下,reduce任务的个数应大致等于上面这个参数的大小(请换算成GB),如果该参数大小是reduce任务数的数倍,那就意味着reduce任务数不合理。

解决方法:

九、合并小文件

文件数目过多,会给 HDFS 带来压力,并且会影响处理效率,可以通过合并 Map 和 Reduce 的结果文件来消除这样的影响:

十、合理设置reduce个数

1)某些情况下,job运行过程中reduce个数太少,导致任务执行太慢,默认reduce的个数由下面配置控制:

2)调整reduce个数方法一

3)调整reduce个数方法二(一般这样设置就可以了)

4)reduce个数并不是越多越好

5)什么情况下只有一个reduce

十一、排序优化

Order by 实现全局排序,一个reduce实现,效率低,所以order by过程中尽量limit来限制输出条数
Sort by 实现部分有序,单个reduce输出的结果是有序的,效率高,通常和DISTRIBUTE BY关键字一起使用(DISTRIBUTE BY关键字 可以指定map 到 reduce端的分发key)
CLUSTER BY col1 等价于DISTRIBUTE BY col1 SORT BY col1

十二、动态分区

在hive中,有时候会希望根据输入的key,把结果自动输出到不同的目录中,这可以通过动态分区来实现,就是把每一个key当作一个分区。

如果要启动动态分区,则需要进行下面的设置

1、首先需要在hive语句中设置允许动态分区

2、在动态分区有可能很大的情况下,还需要其他的调整

3、最后要注意的是select语句中要把distribute的key也select出来
4、适当设置reduce个数 mapred.reduce.tasks

十三、数据倾斜

数据倾斜的外在表现是执行时间超长。查看任务的监控页面可以发现,除了一个或几个任务外,其他reduce任务都执行的很快。这种情况下,只有一个解释:数据倾斜。

在做Shuffle阶段的优化过程中,遇到了数据倾斜的问题,造成了对一些情况下优化效果不明显。主要是因为在Job完成后的所得到的Counters是整个Job的总和,优化是基于这些Counters得出的平均值,而由于数据倾斜的原因造成map处理数据量的差异过大,使得这些平均值能代表的价值降低。Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个reduce中,就是解决数据倾斜的根本所在。规避错误来更好的运行比解决错误更高效。在查看了一些资料后,总结如下。

数据倾斜原因

操作

关键词

情形

后果

Join

其中一个表较小,

但是key集中

分发到某一个或几个Reduce上的数据远高于平均值

大表与大表,但是分桶的判断字段0值或空值过多

这些空值都由一个reduce处理,灰常慢

group by

group by 维度过小,

某值的数量过多

处理某值的reduce灰常耗时

Count Distinct

某特殊值过多

处理此特殊值的reduce耗时

原因

        a)、key分布不均匀

        b)、业务数据本身的特性

        c)、建表时考虑不周

        d)、某些SQL语句本身就有数据倾斜

表现

        任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。

        单一reduce的记录数与平均记录数差异过大,通常可能达到3倍甚至更多。 最长时长远大于平均时长。

数据倾斜的解决方案

参数调节

SQL语句调整

a) 如何Join:

b) 大小表Join:

c) 大表Join大表:

d) count distinct大量相同特殊值

e) group by维度过小:

f)特殊情况特殊处理:

典型的业务场景

空值产生的数据倾斜

场景:如日志中,常会有信息丢失的问题,比如日志中的 user_id,如果取其中的 user_id 和 用户表中的user_id 关联,会碰到数据倾斜的问题。

解决方法1: user_id为空的不参与关联

select * 
  from log a
  join 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 :赋与空值分新的key值

select *
  from log a
  left outer join users b
    on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id;

结论:方法2比方法1效率更好,不但io少了,而且作业数也少了。解决方法1中 log读取两次,jobs是2。解决方法2 job数是1 。这个优化适合无效 id (比如 -99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数,就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。

不同数据类型关联产生数据倾斜

场景:用户表中user_id字段为int,log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时,默认的Hash操作会按int型的id来进行分配,这样会导致所有string类型id的记录都分配到一个Reducer中。

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

select * from users a
  left outer join logs b
    on a.usr_id = cast(b.user_id as string)

3.3) 小表不小不大,怎么用 map join 解决倾斜问题

使用 map join 解决小表(记录数少)关联大表的数据倾斜问题,这个方法使用的频率非常高,但如果小表很大,大到map join会出现bug或异常,这时就需要特别的处理。 以下例子:

select * from log a
  left outer join users b
    on a.user_id = b.user_id;

users 表有 600w+ 的记录,把 users 分发到所有的 map 上也是个不小的开销,而且 map join 不支持这么大的小表。如果用普通的 join,又会碰到数据倾斜的问题。

解决方法:

select /*+mapjoin(x)*/* from log a
  left outer join (
    select  /*+mapjoin(c)*/d.*
      from ( select distinct user_id from log ) c
      join users d
      on c.user_id = d.user_id
    ) x
  on a.user_id = b.user_id;

假如,log里user_id有上百万个,这就又回到原来map join问题。所幸,每日的会员uv不会太多,有交易的会员不会太多,有点击的会员不会太多,有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。

总结

使map的输出数据更均匀的分布到reduce中去,是我们的最终目标。由于Hash算法的局限性,按key Hash会或多或少的造成数据倾斜。大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。在此给出较为通用的步骤:

1、采样log表,哪些user_id比较倾斜,得到一个结果表tmp1。由于对计算框架来说,所有的数据过来,他都是不知道数据分布情况的,所以采样是并不可少的。

2、数据的分布符合社会学统计规则,贫富不均。倾斜的key不会太多,就像一个社会的富人不多,奇特的人不多一样。所以tmp1记录数会很少。把tmp1和users做map join生成tmp2,把tmp2读到distribute file cache。这是一个map过程。

3、map读入users和log,假如记录来自log,则检查user_id是否在tmp2里,如果是,输出到本地文件a,否则生成<user_id,value>的key,value对,假如记录来自member,生成<user_id,value>的key,value对,进入reduce阶段。

4、最终把a文件,把Stage3 reduce阶段输出的文件合并起写到hdfs。

如果确认业务需要这样倾斜的逻辑,考虑以下的优化方案:

举报

相关推荐

0 条评论