hive建表没使用LZO存储格式,但是数据是LZO格式时遇到的问题,hivelzo


       今天微博大数据平台发邮件来说,他们有一个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 END
from brand_ad_2hop_3 a
LEFT OUTER join ods_bas_user_interact_score_to_thin_3 b
on (a.uid = b.fid and a.friend = b.tid);
该hql很简单,就是两个表关联,然后输出到另外一个表中,是一个普通的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存储格式


hive下导入数据,生成表后的压缩率大致有多大?

hive不做压缩的,只是在hdfs中移动数据,或是从本地文件系统移动到hdfs。原来是多大就是多大。
如果要压缩,可以先压缩好再导入,hive是不会替你做这步的。hive支持gz格式和lzo格式。gz格式原生支持。lzo格式需要某个特殊的serde。
 

国内外著名的互联网公司使用hadoop都做了什?谈HADOOP在大规模数据处理领域的具体应用

节点数: 15台机器的构成的服务器集群服务器配置: 8核CPU,16G内存,1.4T硬盘容量。 HADOOP在百度:HADOOP主要应用日志分析,同时使用它做一些网页数据库的数据挖掘工作。节点数:10 - 500个节点。主要使用了2个集群:一个由1100台节点组成的集群,包括8800核CPU(即每台机器8核),和12000TB的原始存储(即每台机器12T硬盘)一个有300台节点组成的集群,包括2400核CPU(即每台机器8核),和3000TB的原始存储(即每台机器12T硬盘)由此基础上开发了基于SQL语法的项目:HIVE HADOOP在HULU 主要用于日志存储和分析13台机器构成的集群 (8核PUC,单台机器:4TB硬盘)基于HBASE数据库 HADOOP在TWITTER 使用HADOOP用于存储微博数据,日志文件和许多中间数据使用基于HADOOP构件的Cloudera's CDH2系统,存储压缩后的数据文件(LZO格式) HADOOP在雅虎:主要用于支持广告系统及网页搜索机器数:25000,CPU:8核集群机器数: 4000 个节点 (2*4cpu boxes w 4*1TB disk & 16GB RAM)
 

相关内容