Hive数据倾斜总结

倾斜的原因:

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

解决思路:

  Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个reduce中,就是解决数据倾斜的根本所在

具体办法:

内存优化和I/O优化:

  驱动表:使用大表做驱动表,以防止内存溢出;Join最右边的表是驱动表;Mapjoin无视join顺序,用大表做驱动表;StreamTable。

 1. Mapjoin是一种避免避免数据倾斜的手段

  允许在map阶段进行join操作,MapJoin把小表全部读入内存中,在map阶段直接拿另外一个表的数据和内存中表数据做匹配,由于在map是进行了join操作,省去了reduce运行的效率也会高很多

在《hive:join遇到问题》有具体操作

  在对多个表join连接操作时,将小表放在join的左边,大表放在Jion的右边,

  在执行这样的join连接时小表中的数据会被缓存到内存当中,这样可以有效减少发生内存溢出错误的几率

 2. 设置参数

  hive.map.aggr = true

  hive.groupby.skewindata=true 还有其他参数 

3.SQL语言调节

  比如: group by维度过小时:采用sum() group by的方式来替换count(distinct)完成计算

4.StreamTable

  将在reducer中进行join操作时的小table放入内存,而大table通过stream方式读取

5.索引

  Hive从0.80开始才有,提供了一个Bitmap位图索引,索引可以加快GROUP BY查询语句的执行速度,用的较少。

其他优化:

1、 列裁剪(Column pruning):只有需要用到的列才进行输出

2、 谓词下推(Predicate pushdown):尽早进行数据过滤(见图表 7中,下面为先处理的逻
辑),减少后续处理的数据量

3、 分区裁剪(Partition pruning):只读取满足分区条件的文件 
4、 map-join:对于join中一些小文件,可以在map阶段进行join操作,见3.2.2节map-join部分 
5、 join-reordering:将在reducer中进行join操作时的小table放入内存,而大table通过
stream方式读取 
6、 Group-by优化: 进行局部聚合进行优化(包括hash-based和sort-based),对于skew
的key(key的row num和size在reduce时非常不均)可以进行两次map-reduce的方式优化

Hive的配置参数比较保守,所以效率会比较差一点,修改配置会让查询效率有比较大的提升,记录几个对查询效率影响比较重要的参数。

元数据:

嵌套SQL并行执行优化:

set hive.exec.parallel=true;

set hive.exec.parallel.thread.number=16;

四、排序优化

Order by 实现全局排序,一个reduce实现,效率低

Sort by 实现部分有序,单个reduce输出的结果是有序的,效率高,通常和DISTRIBUTE BY关键字一起使用(DISTRIBUTE BY关键字 可以指定map 到 reduce端的分发key)

CLUSTER BY col1 等价于DISTRIBUTE BY col1 SORT BY col1.

五、合并小文件

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

hive.merge.mapfiles = true是否和并 Map 输出文件,默认为 True

hive.merge.mapredfiles = false是否合并 Reduce 输出文件,默认为 False

hive.merge.size.per.task = 256*1000*1000合并文件的大小。

这里的参数没有写到上面的表格里是因为这是可以根据任务不同临时设置的,而不一定非要是全局设置。有时候全局设置了反而对大文件的操作有性能影响。

六、使用分区,RCFile,lzo,ORCFile等

Hive中的每个分区都对应hdfs上的一个目录,分区列也不是表中的一个实际的字段,而是一个或者多个伪列,在表的数据文件中实际上并不保存分区列的信息与数据。Partition关键字中排在前面的为主分区(只有一个),后面的为副分区

静态分区:静态分区在加载数据和使用时都需要在sql语句中指定

例:(stat_date=‘20120625‘,province=‘hunan‘)

动态分区:使用动态分区需要设置hive.exec.dynamic.partition参数值为true,默认值为false,在默认情况下,hive会假设主分区时静态分区,副分区使用动态分区;如果想都使用动态分区,需要设置set hive.exec.dynamic.partition.mode=nostrick,默认为strick

例:(stat_date=‘20120625‘,province)

时间: 2024-08-08 09:28:27

Hive数据倾斜总结的相关文章

HIVE数据倾斜问题

HIVE数据倾斜问题问题状态: 未解决 背景:HDFS对文件进行了压缩,而且不添加索引.主要用HIVE进行开发. 发现的现象:sqoop从Mysql导入数据,根据ID进行平均分割,但是ID分部及其不均匀(我也不知道业务系统怎么搞得).所以导致reduce出来的文件大小严重不均匀,就是所谓的数据倾斜. 导致的问题:写HQL从该表中读取数据,发现整个job很慢.后来我查日志发现,有几个map读取数据非常慢,1G的文件大概需要1个多小时才能读取完毕. 问题分析: 由于hadoop对文件进行了lzo格式

Hive数据倾斜

map/reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条key所在的reduce节点所处理的数据量比其他节点就大很多,从而导致某几个节点迟迟运行不完,此称之为数据倾斜. 1.万能膏药:hive.groupby.skewindata=true 当选项设定为 true,生成的查询计划会有两个 MR Job. 第一个 MR Job 中,Map 的输

Hive数据倾斜的原因及主要解决方法

数据倾斜产生的原因 数据倾斜的原因很大部分是join倾斜和聚合倾斜两大类 Hive倾斜之group by聚合倾斜 原因: 分组的维度过少,每个维度的值过多,导致处理某值的reduce耗时很久: 对一些类型统计的时候某种类型的数据量特别多,其他的数据类型特别少.当按照类型进行group by的时候,会将相同的group by字段的reduce任务需要的数据拉取到同一个节点进行聚合,而当其中每一组的数据量过大时,会出现其他组的计算已经完成而这个reduce还没有计算完成,其他的节点一直等待这个节点的

16、Hive数据倾斜与解决方案

数据倾斜 1.什么是数据倾斜 由于数据分布不均匀,造成数据大量的集中到一点,造成数据热点 2.数据倾斜的现象 在执行任务的时候,任务进度长时间维持在99%左右,查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成.因为其处理的数据量和其他reduce差异过大. 单一reduce的记录数与平均记录数差异过大,通常可能达到3倍甚至更多.最长时长远大于平均时长. 3.数据倾斜的情况 4.数据倾斜的原因 1).key分布不均匀 2).业务数据本身的特性 3).建表时考虑不周 4).某些S

[Hive]Hive数据倾斜(大表join大表)

业务背景 用户轨迹工程的性能瓶颈一直是etract_track_info,其中耗时大户主要在于trackinfo与pm_info进行左关联的环节,trackinfo与pm_info两张表均为GB级别,左关联代码块如下: from trackinfo a left outer join pm_info b on (a.ext_field7 = b.id) 使用以上代码块需要耗时1.5小时. 优化流程 第一次优化 考虑到pm_info表的id是bigint类型,trackinfo表的ext_fiel

浅析 Hadoop 中的数据倾斜

转自:http://my.oschina.net/leejun2005/blog/100922 最近几次被问到关于数据倾斜的问题,这里找了些资料也结合一些自己的理解. 在并行计算中我们总希望分配的每一个task 都能以差不多的粒度来切分并且完成时间相差不大,但是集群中可能硬件不同,应用的类型不同和切分的数据大小不一致总会导致有部分任务极大的拖慢了整个任务的完成时间,硬件不同就不说了,应用的类型不同其中就比如page rank 或者data mining 里面一些计算,它的每条记录消耗的成本不太一

hive大数据倾斜总结

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

Hive语法层面优化之一数据倾斜介绍

数据倾斜:数据分布不均匀,造成数据大量的集中到一点,造成数据热点: 由于数据并不是平均分配的,会导致各个节点上处理的数据量是不均衡的,所以数据倾斜是无法避免的: 造成数据倾斜的最根本原因:key分发不均匀造成的: 常见的数据倾斜的症状 1)  Map阶段快,reduce阶段非常慢: 2)  某些map很快,某些map很慢: 3)  某些reduce很快,某些reduce很慢: 4)  任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成,

Hive语法层面优化之四count(distinct)引起的数据倾斜

当该字段存在大量值为null或空的记录,容易发生数据倾斜: 解决思路: count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1: 如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union. 案例: select count(distinct end_user_id) as user_num from trackinfo; 调整为: select cast(count(