hive任务卡在个别reduce的问题分析

        最近微博有一个任务需要使用日曝光表做统计,发现这个任务很容易在stage1卡在reduce100%阶段不动,发邮件过来让帮找一下问题或者优化一下,和同事一起分析了一下原因,以下是分析过程:

1、分析hql

add file get_recept_mid.sh;
add file get_last_expo_mid.sh;
add file get_real_recept.py;
insert overwrite directory '/user/liangjun/hive-liangjun/' 
select transform(t2.uid,t7.mid,t2.expo_mid) using 'python get_real_recept.py' as uid,real_recept 
from ( 
    select transform(t6.*) using 'sh get_recept_mid.sh' as uid,mid 
    from ( select t3.fans_uid,t4.mid from ( select fans_uid,uid from mds_user_fanslist where    dt=20140926 ) t3 join ( 
    select transform(t5.*) using 'sh get_recept_mid.sh' as uid,mid 
   from ( select uid,mid from mds_bhv_pubblog where dt=20140926 distribute by uid sort by uid ) t5   
    ) t4 on t3.uid=t4.uid distribute by t3.fans_uid sort by t3.fans_uid ) t6 ) t7 join	( 
    select transform(t1.*) using 'sh get_recept_mid.sh' as uid,expo_mid 
    from ( select t8.* from ( 
    select transform(ods_tblog_expo.uid,ods_tblog_expo.mid_list) 
             using 'sh get_last_expo_mid.sh' as uid,mid 
    from ods_tblog_expo where dt=20140926 and interface_id in ('1','5') ) t8 distribute by t8.uid sort  
    by t8.uid ) t1 ) t2 on t7.uid=t2.uid;

该hql有个特点:使用了多个脚本,包括python、shell

2、看是否有报错信息:

没有发现报错,但是卡在selectoperator处:

2014-09-29 10:22:23,162 INFO ExecReducer: ExecReducer: processing 10000000 rows: used memory = 110701640
2014-09-29 10:22:23,162 INFO org.apache.hadoop.hive.ql.exec.ExtractOperator: 2 forwarding 10000000 rows
2014-09-29 10:22:23,162 INFO org.apache.hadoop.hive.ql.exec.SelectOperator: 3 forwarding 10000000 rows

3、看是否有数据倾斜问题

查看了已经运行完成的reduce和卡住的reduce的counter信息,几个重要指标(FILE_BYTES_READFILE_BYTES_WRITTEN、HDFS_BYTES_WRITTEN)都差不多,不存在数据倾斜问题,但是FILE_BYTES_READ一直在动,而HDFS_BYTES_WRITTEN一直没反应。

4、查看了一下卡住的reduce任务java进程使用内存和cpu的情况

根据50030监控页面,找到卡住reduce任务运行所在的节点,根据任务id找到对应的进程id,分别通过jstat -gcutil ${pid} 1000,和top -p ${pid}查看内存和cpu使用情况,发现内存使用很少,cou使用也很低,排除是java进程内存不够和cpu使用过高问题的原因。

5、查看stage1 reduce阶段的执行计划:

Reduce Operator Tree:
        Extract
          Select Operator
            expressions:
                  expr: _col0
                  type: string
                  expr: _col1
                  type: string
            outputColumnNames: _col0, _col1
            Transform Operator
              command: sh get_recept_mid.sh
              output info:
                  input format: org.apache.hadoop.mapred.TextInputFormat
                  output format: org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat
              File Output Operator
                compressed: false
                GlobalTableId: 0
                table:
                    input format: org.apache.hadoop.mapred.SequenceFileInputFormat
                    output format: org.apache.hadoop.hive.ql.io.HiveSequenceFileOutputFormat

从执行计划上面看出,stage1的reduce阶段使用了get_recept_mid.sh脚本,该脚本内容如下:

awk -F"\t" 'BEGIN{last=""}{
	if(last!=$1&&last!=""){
		print last"\t"mids
		mids=""
	}

	if(mids==""){
		mids=$2
	}else{
		mids=mids","$2
	}
	last=$1
}END{
	print last"\t"mids
}' /dev/stdin
是一个awk,按理说awk还是很高效的。

既然使用了awk,在运行的时候肯定会起一个进程,我们来查看一下awk进程的内存和cpu使用情况,登陆到运行卡住recue任务的节点,执行top命令,发现确实有一个awk的进程,top -p ${pid},如下图所示:


发现awk实际使用的内存为13M,而且cpu使用达到100.3%,从这两个信息来看应该awk的问题导致reduce被卡住了,以下是找到的awk相关资料:

      “awk有两种工作方式:交互方式及非交互方式。交互方式即输入数据由用户通过键盘输入,此时awk使用行缓冲区,每接收到一行输入数据立即输出。非交互方式的输入数据通过文件或管道输入,此时只有输入缓冲区满了才会输出,对于一些实时性的应用这种方式会带来困扰“

       既然找到了问题的原因就好办了,解决办法将缓冲区的数据刷出去,修改后的脚本内容:

awk -F"\t" 'BEGIN{last=""}{
        fflush("")
        if(last!=$1&&last!=""){
                print last"\t"mids
                mids=""
        }

        if(mids==""){
                mids=$2
        }else{
                mids=mids","$2
        }
        last=$1
}END{
        print last"\t"mids
}' /dev/stdin
从新提交job,发现很快运行完成,reduce被卡住问题解决。

参考:

http://hi.baidu.com/lyugb/item/3351d6100d7e7dfc756a8499

同事博客地址:http://dj1211.com/


你可能感兴趣的:(hive)