今天微博大数据平台发邮件来说。他们有一个hql执行失败。可是从gateway上面的日志看不出来是什么原因导致的，我帮忙看了一下。最后找到了问题的解决办法，下面是分析过程：

1、执行失败的hql：

INSERT OVERWRITE TABLE brand_ad_user_with_interact_score_3 select a.uid, a.brand, a.friend, CASE b.weight WHEN NULL THEN '0.000000' ELSE b.weight ENDfrom brand_ad_2hop_3 aLEFT OUTER join ods_bas_user_interact_score_to_thin_3 bon (a.uid = b.fid and a.friend = b.tid);

该hql非常easy，就是两个表关联。然后输出到另外一个表中。是一个普通的common join，没有group by等操作。所以不存在map的数据倾斜问题

2、查看job日志

依据50030页面查看了一下该job的状态和日志信息，job的状态是被kill掉的，map任务还未执行完毕就被kill掉了，被kill掉的map任务执行时间都超过了10个小时。例如以下图所看到的：

依据1中得分析。该job从hql上面看是不存储数据倾斜的，那为什么会出现单个map执行时间超过10小时的情况呢，查看了一下被kill掉map任务的counter信息，例如以下：

居然单个map任务从hdfs上面读了10G的数据。不应该啊。难不成被处理的数据文件没被分片，单个map任务处理了单个的大文件。怀揣着这种推測，我去检查了一下hql里面两个表文件夹以下的文件，果不其然，以下全是lzo格式的文件，可是都没有建索引。并且

brand_ad_2hop_3表以下个别单个文件达到了10G+，应该就是这个原因了：lzo格式的文件没有建索引。数据文件不能被分片，导致在执行的时候，单个的文件仅仅能由一个map任务处理，假设单个文件非常大的情况下。map任务就会处理非常长时间。

在检查了一下brand_ad_2hop_3的建表语句，发现存储格式为Text。

既然找到了问题原因，下面就是解决的方法了：

（1）、给lzo文件建立索引

（2）、建表的时候请使用LZO存储格式