文档章节

Hive map阶段优化之一次详细的优化分析过程

问津已非少年
 问津已非少年
发布于 2017/03/27 00:21
字数 3623
阅读 563
收藏 5

#背景 同事写了这样一段HQL(涉及公司数据,表名由假名替换,语句与真实场景略有不同,但不影响分析):

CREATE TABLE tmp AS
SELECT
       t1.exk,
       t1.exv,
       M.makename AS m_makename,
       S.makename AS s_makename,
FROM
  (SELECT
          exk,
          exv
   FROM xx.xxx_log
   WHERE etl_dt = '2017-01-12'
     AND exk IN ('xxID', 'yyID') ) t1
LEFT JOIN xx.xxx_model_info M ON (M.modelid=t1.exv AND t1.exk='xxID')
LEFT JOIN xx.xxx_style_info S ON (S.styleid=t1.exv AND t1.exk='yyID')

任务运行过程中非常缓慢,同事反映说这个任务要跑一个多小时。初步问了下,xx.xxx_log表数据量在分区etl_dt = '2017-01-12'上大概1亿3000万,xx.xxx_model_info大概3000多,xx.xxx_style_info大概4万多。 #分析 ##第一步,分析HQL语句着手 从同事提供的数据量上看,两个left join显然应该是mapjoin,因为数据量差距悬殊。当前只有HQL语句,所以优化第一步当然要从HQL语句本身出发,看HQL语句是否有不恰当的地方。

从语句上看,就是取三张表的数据,按条件进行join,最后创建并插入一张hive表。语句上看没什么问题。

那就来看执行计划吧~ 我们只看建表后面的SELECT语句,如下

STAGE DEPENDENCIES:
  Stage-5 is a root stage
  Stage-4 depends on stages: Stage-5
  Stage-0 depends on stages: Stage-4

STAGE PLANS:
  Stage: Stage-5
    Map Reduce Local Work
      Alias -> Map Local Tables:
        m 
          Fetch Operator
            limit: -1
        s 
          Fetch Operator
            limit: -1
      Alias -> Map Local Operator Tree:
        m 
          TableScan
            alias: m
            Statistics: Num rows: 3118 Data size: 71714 Basic stats: COMPLETE Column stats: NONE
            HashTable Sink Operator
              filter predicates:
                0 {(_col0 = 'xxID')} {(_col0 = 'yyID')}
                1 
                2 
              keys:
                0 UDFToDouble(_col1) (type: double)
                1 UDFToDouble(modelid) (type: double)
                2 UDFToDouble(styleid) (type: double)
        s 
          TableScan
            alias: s
            Statistics: Num rows: 44482 Data size: 1023086 Basic stats: COMPLETE Column stats: NONE
            HashTable Sink Operator
              filter predicates:
                0 {(_col0 = 'xxID')} {(_col0 = 'yyID')}
                1 
                2 
              keys:
                0 UDFToDouble(_col1) (type: double)
                1 UDFToDouble(modelid) (type: double)
                2 UDFToDouble(styleid) (type: double)

  Stage: Stage-4
    Map Reduce
      Map Operator Tree:
          TableScan
            alias: xx.xxx_log
            Statistics: Num rows: 136199308 Data size: 3268783392 Basic stats: COMPLETE Column stats: NONE
            Filter Operator
              predicate: ((exk) IN ('xxID', 'yyID')) (type: boolean)
              Statistics: Num rows: 22699884 Data size: 544797216 Basic stats: COMPLETE Column stats: NONE
              Select Operator
                expressions: exk (type: string), exv (type: string)
                outputColumnNames: _col0, _col1
                Statistics: Num rows: 22699884 Data size: 544797216 Basic stats: COMPLETE Column stats: NONE
                Map Join Operator
                  condition map:
                       Left Outer Join0 to 1
                       Left Outer Join0 to 2
                  filter predicates:
                    0 {(_col0 = 'SerialID')} {(_col0 = 'CarID')}
                    1 
                    2 
                  keys:
                    0 UDFToDouble(_col1) (type: double)
                    1 UDFToDouble(modelid) (type: double)
                    2 UDFToDouble(styleid) (type: double)
                  outputColumnNames: _col0, _col1, _col13, _col32
                  Statistics: Num rows: 49939745 Data size: 1198553901 Basic stats: COMPLETE Column stats: NONE
                  Select Operator
                    expressions: _col0 (type: string), _col1 (type: string), _col13 (type: string), _col32 (type: string)
                    outputColumnNames: _col0, _col1, _col2, _col3
                    Statistics: Num rows: 49939745 Data size: 1198553901 Basic stats: COMPLETE Column stats: NONE
                    File Output Operator
                      compressed: false
                      Statistics: Num rows: 49939745 Data size: 1198553901 Basic stats: COMPLETE Column stats: NONE
                      table:
                          input format: org.apache.hadoop.mapred.TextInputFormat
                          output format: org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat
                          serde: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe
      Local Work:
        Map Reduce Local Work

  Stage: Stage-0
    Fetch Operator
      limit: -1
      Processor Tree:
        ListSink

执行计划上分为三个stage,第一个处理两张小表的,把小表内容处理成HashTable来做mapjoin,这个跟我们上面的分析一致。第二个用于处理大表和小表的mapjoin,最后一个则是关联后的数据输出。

从执行计划上看,似乎也没什么问题,一切很正常~~

既然从SQL本身找不到问题,那说明有可能出现在数据上或机器上,就只能具体问题具体看了。

##第二步,查建表语句,看表的压缩格式是不是不支持分割导致部分map任务处理时间过长 Hive支持多种压缩格式,有的压缩格式支持split,而有的并不支持,比如LZO。当不支持split的时候,数据块有多大,Hive的map任务就得处理多大,而Hive表的分区数据有可能存在不均衡的现象,就会导致有的map快,有的map慢。当遇到LZO格式的时候,最好的方式是建立索引,可以加快处理速度。

show create table从建表语句里看,并没有使用LZO的表。而在hdfs上直接查看三张表的文件大小,最大的那张表加上条件后还有24个分区,每个分区的大小不一样。但是由于任务有40个map,由此可知有些分区的数据是拆成了几个map任务的,所以再一次证明是可切分的,排除不可切分导致的map任务问题。

##第三步,分析任务运行状况 找到运行完的任务,查看运行界面图可以看到,map任务的时间长短不一,最短的1分钟之内,最长的达半个多小时。

乍一看,好像是数据倾斜导致的,要确定是否数据倾斜,我们需要随机挑几个时间长的map任务,和时间短的map任务,看看各自的数据量和数据大小。

对比发现,数据量基本都在100万到130之间,而数据大小也在100多MB左右(不能只看数据量,数据大小也很重要,防止空列这种数据倾斜情况)。

这样一来,map端的数据倾斜其实是不存在的,所以map任务应该基本上是均衡的。那为什么时间上会相差这么大呢?

进而猜测,是不是因为某些慢的任务刚好被挤在某台或某几台机器上,而刚好这几台机器负载重,所以比较慢?

到这里,我们统计下慢的几个map任务都在什么机器上,统计完发现,果然最慢的十几个任务集中分布在两台机器上,一台机器大概六七个的样子。按7个任务算,每个任务读100多MB的文件,怎么说都在几分钟之内可以搞定吧,所以好像真的跟机器负载有关系~

所以机器这里我们也必须去看一看,看看是不是负载导致的。重新跑一下上面的任务,找到map慢的几台机器,做如下查看:

分别从CPU、内存、磁盘IO和网络IO来看,这是服务器状况查看的基本入口:

  • top 命令可以辅助我们查看CPU的状况,结果发现CPU平均负载不过50%
  • iostat -x 5 命令可以辅助我们查看磁盘IO情况,我们发现请求数比较高但是平均等待队列并不高,磁盘读写都跟得上,所以磁盘也不是问题
  • sar -n DEV 5 命令可以辅助我们查看网络IO的情况,服务器至少是千兆网卡,支持至少1Gb/s的速度,而从输出来看,网络远远不是问题

由此,我们排除了机器负载过高导致无法服务的问题,同时问了下同事,说是这个任务跑了好多次都这样,好多次都这样说明机器应该不是问题,因为机器随机分,不可能每次都分到慢的机器上。所以说每次都map慢跟机器无关,而是我们SQL的问题。

##第四步,再触SQL,分段分析 上面的分析已经确认跟机器无关,与数据不可分割也无关,而执行计划上看也没什么问题。那么只好一段一段的来看SQL了。

1、两张小表是要分发到各节点的,所以不考虑,我们按条件读一次大表的数据,统计下行数

SELECT COUNT(1)
FROM xx.xxx_log
WHERE etl_dt = '2017-01-12'
  AND exk IN ('xxID', 'yyID')

结果发现时间只花了2分钟左右,说明SQL不慢在这里。只能慢在join两张小表上了,而小表join是mapjoin,理论上应该不慢才对。

2、考虑只join一张表来看 先选表xx.xxx_model_info

SELECT COUNT(1)
from (
SELECT
       t1.exk,
       t1.exv,
       M.makename AS m_makename
FROM
  (SELECT
          exk,
          exv
   FROM xx.xxx_log
   WHERE etl_dt='2017-01-12'
     AND exk IN ('xxID', 'yyID') ) t1
LEFT JOIN xx.xxx_model_info M ON (M.modelid=t1.exv AND t1.exk='xxID')) tmp

上面是跟3118的一张小表join,可以看到执行计划是mapjoin,而执行时间则出乎意料,用了大概2分钟,与单独计算大表行数差不多。

由此可以想到,mapjoin很慢应该与另一张表有关系,我们下面再执行跟另一张表join的情况,如果还是这么快,那说明两个同时mapjoin在Hive上可能存在缺陷,而如果很慢,则说明mapjoin只跟那张小表有关系。

再选表xx.xxx_style_info

SELECT COUNT(1)
from (
SELECT
       t1.exk,
       t1.exv,
       S.makename AS s_makename
FROM
  (SELECT
          exk,
          exv
   FROM xx.xxx_log
   WHERE etl_dt='2017-01-12'
     AND exk IN ('xxID', 'yyID') ) t1
LEFT JOIN xx.xxx_style_info S ON (S.styleid=t1.exv AND t1.exk='yyID') ) tmp

这下执行结果奇慢无比,map阶段进展很缓慢。由此说明大表与这张小表的mapjoin存在问题,可是mapjoin为啥还存在问题呢? 问题又在哪呢?

##第五步,仍不放弃执行计划 当看到上面问题的时候,一头雾水,所以着重再看执行计划是一个不错的方案。很容易想到,同是两个数据量相差不大的小表,mapjoin的运行速度为什么会不一样?是字段类型导致join连接出问题?

当我们仔细再去看最上面的执行计划的时候,我们会发现我们之前忽视的一个细节,那就是执行计划里有UDFToDouble这个转换,很奇怪我们并没有调用这样的UDF啊,怎么会有这样的转换呢? 唯一的解释只能是join字段匹配。

我们查一下join字段发现,大表的exv字段是string类型,两个小表的关联字段都是int,它们在join的时候,居然都先转成了double型??? 这是什么鬼? 难道不应该都往string类型转换,然后再join吗?

查下Hive官网才发现,类型关系是酱紫的...

hive type|center

double类型是string类型和int类型的公共类型,所以它们都会往公共类型上转!

实际写SQL中,也强烈建议自己做类型匹配的处理,不要拜托给解析器,不然问题很严重。

我们把小表的int类型转换为string类型再做上面第二张表的join,如下:

SELECT COUNT(1)
from (
SELECT
       t1.exk,
       t1.exv,
       S.makename AS s_makename
FROM
  (SELECT
          exk,
          exv
   FROM xx.xxx_log
   WHERE etl_dt='2017-01-12'
     AND exk IN ('xxID', 'yyID') ) t1
LEFT JOIN xx.xx_style_info S ON (cast(S.styleid as string)=t1.exv AND t1.exk='yyID') ) tmp

结果符合预料,2分钟左右的时间可以完成这个SQL任务。而当整个任务也这么改之后,任务跑完也只要几分钟!

由此可见,事情都因细节而起!做join操作的时候,写SQL的人其实是最清楚字段类型的,做上字段类型匹配小菜一碟,可以避免很多问题!!!

##第六步,解开谜团 到这里,我们这个Hive任务的问题已经找到,那就是join两边key的数据类型不对,导致两边的数据类型都要向上做提升才能关联。

但其实还是有问题的,上面第四步的实验提到,当用大表与3118条数据的小表xx.xxx_model_info进行关联的时候,很快可以出结果。但是当用大表与另一张小表xx.xxx_style_info进行关联时,却发现奇慢无比,也即问题跟它有很大关系。大表无论与哪张小表关联,都要做类型提升,两张小表的数据量相比大表而言,其实相差不大,但为啥数据量稍大的小表关联就出问题呢?

我们单独对三张表做类型转换,转为double类型,结果发现三张表的类型转换都很快,并不存在因为数据不同导致转换速度不一样的情况,由此排除是类型提升时出的问题。因而问题最有可能出现在MapJoin身上!

在MapJoin阶段,会把小表的内容加载到内存中,使用容器HashMap做存储,然后对大表的关联列进行扫描,每扫描一行都会去查看HashMap中有没有对应的关联列。这样做起来其实是很快的,同时在Map端也减少了大量数据输出到Reduce端。

但是当HashMap的碰撞非常严重的时候,它的效率会变得非常低,这时 Hive会把小表的存储由HashMap降级为LinkedList!而HashMap里的hash计算是依赖key对应类型的hashcode的,如果大量不同key的hashcode相同,那么HashMap里的碰撞就会非常严重。

在MapJoin阶段,double类型使用的是DoubleWriteable,它的hashcode实现是一个错误的实现,如下:

return (int)Double.doubleToLongBits(value);

long转为int会产生溢出,因此不同的value很可能得到相同的hashcode,hashcode碰撞非常明显。

这个问题早在 Hadoop-12217 里被提到,因为他们在使用Hive的时候碰到了和我相同的问题,就是类型提升为double时出现MapJoin异常缓慢的情况。其描述如下:

hadoop-12217

其patch里提到正确的更改方式如下:

long dblBits = Double.doubleToLongBits(value);
return (int) (dblBits ^ (dblBits >>> 32));

不过这个bug目前并未修复(当前版本:Hadoop 2.6.0-cdh5.5.1, Hive 1.1.0-cdh5.5.1),由于它导致我们数据量稍大的那张小表在MapJoin阶段由HashMap转为了LinkedList,因此数据扫描及其缓慢。而另一张3118条数据的小表,则刚好不存在hash code碰撞的问题,所以Map Join很快。

所以,最终的问题就在于此,所有的表象皆由它引起。最好的解决办法是在Join之前先做转换,让join时的键关联保持类型一致并不为double类型即可。这个需要在写HQL时时常注意,问题虽小,但是要找到它确实不容易,很是花时间。

欢迎阅读转载,转载请注明出处:https://my.oschina.net/u/2539801/blog/868041

© 著作权归作者所有

问津已非少年
粉丝 18
博文 21
码字总数 33944
作品 0
海淀
程序员
私信 提问
Hive SQL 编译过程详解

Hive是基于Hadoop的一个数据仓库系统,在各大公司都有广泛的应用。美团数据仓库也是基于Hive搭建,每天执行近万次的Hive ETL计算流程,负责每天数百GB的数据存储和分析。Hive的稳定性和性能对...

大数据之路
2014/05/21
1K
0
【十八掌●武功篇】第十掌:Hive之原理与优化

这一篇博文是【大数据技术●降龙十八掌】系列文章的其中一篇,点击查看目录:大数据技术●降龙十八掌 小系列列表 【十八掌●武功篇】第十掌:Hive之基本语法 【十八掌●武功篇】第十掌:Hiv...

chybin500
2017/11/17
0
0
从 MapReduce 到 Hive —— 一次迁移过程小记

1、背景介绍 早先的工作中,有很多比较复杂的分析工作,当时对hive还不熟悉,但是java比较熟悉,所以在进行处理的时候,优先选择了MR. 但是随着工作的数据内容越来越多,越来越复杂,对应的调整也越...

大数据之路
2014/01/10
4.1K
0
关于Hive优化的四种方法总结

一、整体架构优化 现在hive的整体框架如下,计算引擎不仅仅支持Map/Reduce,并且还支持Tez、Spark等。根据不同的计算引擎又可以使用不同的资源调度和存储系统。 整体架构优化点: 1、根据不同...

varchard
2016/12/02
51
0
Mapreduce与Hive比较

1、背景介绍 早先的工作中,有很多比较复杂的分析工作,当时对hive还不熟悉,但是java比较熟悉,所以在进行处理的时候,优先选择了MR. 但是随着工作的数据内容越来越多,越来越复杂,对应的调整也越...

恶魔苏醒ing
2017/03/16
0
0

没有更多内容

加载失败,请刷新页面

加载更多

CentOS7.6中安装使用fcitx框架

内容目录 一、为什么要使用fcitx?二、安装fcitx框架三、安装搜狗输入法 一、为什么要使用fcitx? Gnome3桌面自带的输入法框架为ibus,而在使用ibus时会时不时出现卡顿无法输入的现象。 搜狗和...

技术训练营
昨天
5
0
《Designing.Data-Intensive.Applications》笔记 四

第九章 一致性与共识 分布式系统最重要的的抽象之一是共识(consensus):让所有的节点对某件事达成一致。 最终一致性(eventual consistency)只提供较弱的保证,需要探索更高的一致性保证(stro...

丰田破产标志
昨天
8
0
docker 使用mysql

1, 进入容器 比如 myslq1 里面进行操作 docker exec -it mysql1 /bin/bash 2. 退出 容器 交互: exit 3. mysql 启动在容器里面,并且 可以本地连接mysql docker run --name mysql1 --env MY...

之渊
昨天
10
0
python数据结构

1、字符串及其方法(案例来自Python-100-Days) def main(): str1 = 'hello, world!' # 通过len函数计算字符串的长度 print(len(str1)) # 13 # 获得字符串首字母大写的...

huijue
昨天
6
0
PHP+Ajax微信手机端九宫格抽奖实例

PHP+Ajax结合lottery.js制作的一款微信手机端九宫格抽奖实例,抽奖完成后有收货地址添加表单出现。支持可以设置中奖概率等。 奖品列表 <div class="lottery_list clearfix" id="lottery"> ......

ymkjs1990
昨天
5
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部