什么是大数据倾斜

来源:https://www.cnblogs.com/gala1021/p/8552302.html

侵删

什么是数据倾斜 
    简单的讲,数据倾斜就是我们在计算数据的时候,数据的分散度不够,导致大量的数据集中到了一台或者几台机器上计算,这些数据的计算速度远远低于平均计算速度,导致整个计算过程过慢。 
    相信大部分做数据的童鞋们都会遇到数据倾斜,数据倾斜会发生在数据开发的各个环节中,比如:

  • 用Hive算数据的时候reduce阶段卡在99.99%
  • 用SparkStreaming做实时算法时候,一直会有executor出现OOM的错误,但是其余的executor内存使用率却很低。 
        数据倾斜有一个关键因素是数据量大,可以达到千亿级。

    数据倾斜长的表现

以Hadoop和Spark是最常见的两个计算平台,下面就以这两个平台说明:

1、Hadoop中的数据倾斜

Hadoop中直接贴近用户使用使用的时Mapreduce程序和Hive程序,虽说Hive最后也是用MR来执行(至少目前Hive内存计算并不普及),但是毕竟写的内容逻辑区别很大,一个是程序,一个是Sql,因此这里稍作区分。

Hadoop中的数据倾斜主要表现在ruduce阶段卡在99.99%,一直99.99%不能结束。 
这里如果详细的看日志或者和监控界面的话会发现:

  • 有一个多几个reduce卡住
  • 各种container报错OOM
  • 读写的数据量极大,至少远远超过其它正常的reduce 
    伴随着数据倾斜,会出现任务被kill等各种诡异的表现。

经验: Hive的数据倾斜,一般都发生在Sql中Group和On上,而且和数据逻辑绑定比较深。

2、Spark中的数据倾斜

Spark中的数据倾斜也很常见,这里包括Spark Streaming和Spark Sql,表现主要有下面几种:

  • Executor lost,OOM,Shuffle过程出错
  • Driver OOM
  • 单个Executor执行时间特别久,整体任务卡在某个阶段不能结束
  • 正常运行的任务突然失败

补充一下,在Spark streaming程序中,数据倾斜更容易出现,特别是在程序中包含一些类似sql的join、group这种操作的时候。 因为Spark Streaming程序在运行的时候,我们一般不会分配特别多的内存,因此一旦在这个过程中出现一些数据倾斜,就十分容易造成OOM。

数据倾斜的原理

1、数据倾斜产生的原因 
        我们以Spark和Hive的使用场景为例。他们在做数据运算的时候会设计到,countdistinct、group by、join等操作,这些都会触发Shuffle动作,一旦触发,所有相同key的值就会拉到一个或几个节点上,就容易发生单点问题。

2、万恶的shuffle 
        Shuffle是一个能产生奇迹的地方,不管是在Spark还是Hadoop中,它们的作用都是至关重要的。那么在Shuffle如何产生了数据倾斜?

Hadoop和Spark在Shuffle过程中产生数据倾斜的原理基本类似。如下图。

大部分数据倾斜的原理就类似于下图,很明了,因为数据分布不均匀,导致大量的数据分配到了一个节点。

3、从业务计角度来理解数据倾斜

数据往往和业务是强相关的,业务的场景直接影响到了数据的分布。再举一个例子,比如就说订单场景吧,我们在某一天在北京和上海两个城市多了强力的推广,结果可能是这两个城市的订单量增长了10000%,其余城市的数据量不变。然后我们要统计不同城市的订单情况,这样,一做group操作,可能直接就数据倾斜了。

如何解决

数据倾斜的产生是有一些讨论的,解决它们也是有一些讨论的,本章会先给出几个解决数据倾斜的思路,然后对Hadoop和Spark分别给出一些解决数据倾斜的方案。 
一、几个思路 
    解决数据倾斜有这几个思路: 
        1.业务逻辑,我们从业务逻辑的层面上来优化数据倾斜,比如上面的例子,我们单独对这两个城市来做count,最后和其它城市做整合。 
        2.程序层面,比如说在Hive中,经常遇到count(distinct)操作,这样会导致最终只有一个reduce,我们可以先group 再在外面包一层count,就可以了。 
        3.调参方面,Hadoop和Spark都自带了很多的参数和机制来调节数据倾斜,合理利用它们就能解决大部分问题。

二、从业务和数据上解决数据倾斜

很多数据倾斜都是在数据的使用上造成的。我们举几个场景,并分别给出它们的解决方案。 
数据分布不均匀: 
前面提到的“从数据角度来理解数据倾斜”和“从业务计角度来理解数据倾斜”中的例子,其实都是数据分布不均匀的类型,这种情况和计算平台无关,我们能通过设计的角度尝试解决它。

  • 有损的方法: 
                找到异常数据,比如ip为0的数据,过滤掉
  • 无损的方法: 
                对分布不均匀的数据,单独计算 
                先对key做一层hash,先将数据打散让它的并行度变大,再汇集 
    •数据预处理

三、Hadoop平台的优化方法

列出来一些方法和思路,具体的参数和用法在官网看就行了。

1.mapjoin方式 
        2.count distinct的操作,先转成group,再count 
        3.hive.groupby.skewindata=true 
        4.left semi jioin的使用 
        5.设置map端输出、中间结果压缩。(不完全是解决数据倾斜的问题,但是减少了IO读写和网络传输,能提高很多效率)

四、Spark平台的优化方法 
    列出来一些方法和思路,具体的参数和用法在官网看就行了。 
        1.mapjoin方式 
        2.设置rdd压缩 
        3.合理设置driver的内存 
        4.Spark Sql中的优化和Hive类似,可以参考Hive

总结

数据倾斜的坑还是很大的,如何处理数据倾斜是一个长期的过程,希望本文的一些思路能提供帮助。文中一些内容没有细讲,比如Hive Sql的优化,数据清洗中的各种坑,这些留待后面单独的分享,会有很多的内容。另外千亿级别的数据还会有更多的难点,不仅仅是数据倾斜的问题,这一点在后面也会有专门的分享。

原文地址:https://www.cnblogs.com/Tunan-Ki/p/11792972.html

时间: 2024-10-08 04:47:39

什么是大数据倾斜的相关文章

hive大数据倾斜总结

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

大数据优化之数据倾斜

数据倾斜 数据倾斜概念 在做计算的时候,数据的分散度不够(数据的Key分布不均),导致数据分布在一台或几台机器计算 症状:典型的现象就是数据reduce到99%很久不动了 数据倾斜原因 总原因:key分布不均 业务数据的特点(数据的幂律分布) 人为建表的疏忽 join.group by.count distinct等操作触发shuffle操作 一些数据倾斜解决方法 将数据均匀分配到各个reduce中是解决数据倾斜的根本所在 业务逻辑 根据业务特点,单独对特别的业务数据进行聚合 程序 count

全闪存阵列为大数据优化

为了更好地支持大数据应用,富士通推出了针对大数据进行优化的全闪存阵列和大数据一体机,在保证整个系统高性能和高可靠的前提下,进一步提升了数据处理和分析的效率. 大数据是继云计算之后又一项将改变传统商业模式和IT应用方式的重要变革.从存储的角度看,富士通正逐渐将产品的重点向大数据倾斜,近日推出了最新的全闪存阵列ETERNUS DX200F和面向大数据的一体机MHA. 全闪存阵列ETERNUS DX200F是一款面向中小企业用户的入门级存储产品.虽然是一款入门级的产品,但是ETERNUS DX200F

hadoop job解决大数据量关联时数据倾斜的一种办法

转自:http://www.cnblogs.com/xuxm2007/archive/2011/09/01/2161929.html http://www.geminikwok.com/2011/04/02/hadoop-job解å?³å¤§æ?°æ?®é??å?³è??æ—¶æ?°æ?®å?¾æ??ç??ä¸?ç§?å??æ³?/ 数据倾斜是指,map /reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为

大数据数据倾斜

什么是数据倾斜     简单的讲,数据倾斜就是我们在计算数据的时候,数据的分散度不够,导致大量的数据集中到了一台或者几台机器上计算,这些数据的计算速度远远低于平均计算速度,导致整个计算过程过慢.     相信大部分做数据的童鞋们都会遇到数据倾斜,数据倾斜会发生在数据开发的各个环节中,比如: 用Hive算数据的时候reduce阶段卡在99.99% 用SparkStreaming做实时算法时候,一直会有executor出现OOM的错误,但是其余的executor内存使用率却很低.     数据倾斜有

【Spark调优】小表join大表数据倾斜解决方案

[使用场景] 对RDD使用join类操作,或者是在Spark SQL中使用join语句时,而且join操作中的一个RDD或表的数据量比较小(例如几百MB或者1~2GB),比较适用此方案.. [解决方案] 小表join大表转为小表broadcast+map大表实现.具体为: 普通的join是会shuffle的,而一旦shuffle,就相当于会将相同key的数据拉取到一个shuffle read task中再进行join,此时就是reduce join,此时如果发生数据倾斜,影响处理性能,而此时恰好

【Spark调优】大表join大表,少数key导致数据倾斜解决方案

[使用场景] 两个RDD进行join的时候,如果数据量都比较大,那么此时可以sample看下两个RDD中的key分布情况.如果出现数据倾斜,是因为其中某一个RDD中的少数几个key的数据量过大,而另一个RDD中的所有key都分布比较均匀,此时可以考虑采用本解决方案. [解决方案] 对有数据倾斜那个RDD,使用sample算子采样出一份样本,统计下每个key的数量,看看导致数据倾斜数据量最大的是哪几个key. 然后将这几个key对应的数据从原来的RDD中拆分出来,形成一个单独的RDD,并给每个ke

如何解决大数据计算中常见的数据倾斜问题?

数据倾斜是在大数据计算中常见的问题,用最通俗易懂的话来说,数据倾斜无非就是大量的相同key被partition分配到一个分区里,造成了'一个人累死,其他人闲死'的情况,这种情况是我们不能接受的,这也违背了并行计算的初衷,首先一个节点要承受着巨大的压力,而其他节点计算完毕后要一直等待这个忙碌的节点,也拖累了整体的计算时间,可以说效率是十分低下的.以下针对spark具体计算场景,给出数据倾斜解决方案:场 景当RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用gr

Hive数据倾斜总结

倾斜的原因: 使map的输出数据更均匀的分布到reduce中去,是我们的最终目标.由于Hash算法的局限性,按key Hash会或多或少的造成数据倾斜.大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的. 解决思路: Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个reduce中,就是解决数据倾斜的根本所在 具体办法: 内存优化和I/O优化: 驱动表:使用大表做驱动表,以防止内存溢出:Join最右边的表是驱动表: