目标1、敏锐发现数据倾斜问题的能力2、快速准确定位数据倾斜产生原因的技巧3、Spark解决数据倾斜问题的六大秘籍4、轻松应对大厂Spark数据倾斜面试的能力概念数据倾斜指的是并行处理海量数据过程中某个或者某些分区的数据显著多于其它分区从而使得该部分的处理速度成为整个数据集处理的瓶颈。下图应该纵向看两个红色部分的任务明显多于其他部分。数据倾斜的危害耗时远高于其他任务轻则造成系统资源的浪费。不能充分发挥分布式系统并行计算的优势造成内存不足使得当前任务失败引发重试多次重试仍不正常导致整个任务失败应用不能按时完成资源不能释放后续的任务不断请求资源系统调用暴增甚至演变为集群雪崩大数据处理步骤Map阶段→shuffle→Reduce阶段Map task数据倾斜输入文件导致的数据倾斜①不可切分的压缩算法②数据文件大小不一致Reduce task数据倾斜最常见①数据中有很多空值被分配到同一分区→过滤数据解决异常数据带来的数据倾斜②ShuffleKey分布不均主要原因→消除shuffle、改变Reduce并行度、加盐打散给key添加随机数强行打散数据分析数据必须先处理数据分析数据主要包括以下内容1、数据的整体规模数据规模有多大、文件有多少个、每个文件的大小、预估资源的开销2、数据的存储格式普通文件格式、列族存储的文件格式、文件是否压缩、压缩格式是什么3、数据列值的分布每一列有值的行数、每个值的行数分布特别是key相关的列、分析列值分布可以通过数据采样完成数据倾斜处理依赖这一步的数据列值分布结果数据倾斜判定条件外在表象①Executor lost、OOM、Shuffle过程频繁出现错误信息②单个Executor执行时间特别久整体任务卡在某个阶段不能结束③正常运行的任务突然失败大多数Task运行正常个别Task运行缓慢或发生OOM最根本的原因资源分配不均如何定位数据倾斜1、借助Spark Web UI2、定位shuffle算子秘籍1——消除map端的数据倾斜文件采用了不支持splittable的压缩算法文件大小不一致。如下图所示常用的压缩算法以及是否支持切分如下图所示。解决办法增加数据预处理秘籍2——过滤异常数据对key进行的数据特征分析可以发现是否有异常数据①null(空值)或是一些无意义的信息之类的大多是这个原因引起②无效数据对结果影响不大的有效数据或是大量重复的测试数据③正常数据业务导致的数据分布对于①②两种情况对数据进行预处理过滤即可。为什么Key分布不均匀①填充默认值②业务本身存在热点③存在恶意数据解决办法①过滤数据解决异常数据带来的数据倾斜②消除shuffle③改变Reduce并行度④加盐。给key添加随机数强行打散数据秘籍3——Map side join正常执行join操作也叫Reduce side join时要对数据进行分区不可避免的带来了shuffle如果是大表与小表做关联可采用map side join彻底消除shuffle进而规避数据倾斜此时解决数据倾斜就要用map端的join,把小数据集发送到大数据集的每个分区当中通过广播变量此时没有shuffle数据没有发生移动且map端移动的数据没有数据倾斜现象。所以整体没有数据倾斜。通俗理解假设你有两张表一张是巨无霸用户行为日志1TB一张是小卡片用户基本信息只有100MB。既然小表那么小干脆把小表复制成无数份发送计算大表的每一个机器节点上这就是广播变量。每一台机器在读取大表的数据块时当场在Map阶段就在本地内存里跟小表进行关联。大表的数据不需要移动小表是被“广播”过去的。通过广播变量高效分发到集群中数据压缩、高效的通信框架Netty、BT协议关于广播变量1、广播变量只读由BlockManager管理2、广播变量要能序列化3、由Driver广播到Executor过程中使用BT传输协议4、广播变量可被Excutor中的多个Task共享5、在SparkSQL中广播变量缺省大小为10M6、广播变量会使Driver的内存膨胀①JVM的存储密度低②广播变量会在内存中分割分割完成之前内存中有两份相同大小的广播变量秘籍4——改变Reduce的并行度调整并行度改变了Shuffle过程中数据的去向下图中左侧部分reduce个数为3右侧部分的reduce个数为4看余数为多少则放到哪个分区秘籍5——两极端聚合1、加盐打散key。给每个key都加上一个随机数如10以内的随机数【加盐】此时key被打散2、局部聚合。对打上随机数的key执行一次聚合操作得到结果3、全局聚合。将key的前缀/后缀去掉再进行一次聚合操作得到最终结果秘籍6——大表加盐小表扩容如果出现数据倾斜的Key比较多无法将这些倾斜Key分拆出来此时更适合直接对存在数据倾斜的数据集全部加上随机前缀然后对另外一个数据集整体扩容加盐打散key消除数据倾斜扩容保证join能正常执行扩容增大了整体的数据量但是由于消除了数据倾斜提高了体系的整体利用率
Spark数据倾斜
目标1、敏锐发现数据倾斜问题的能力2、快速准确定位数据倾斜产生原因的技巧3、Spark解决数据倾斜问题的六大秘籍4、轻松应对大厂Spark数据倾斜面试的能力概念数据倾斜指的是并行处理海量数据过程中某个或者某些分区的数据显著多于其它分区从而使得该部分的处理速度成为整个数据集处理的瓶颈。下图应该纵向看两个红色部分的任务明显多于其他部分。数据倾斜的危害耗时远高于其他任务轻则造成系统资源的浪费。不能充分发挥分布式系统并行计算的优势造成内存不足使得当前任务失败引发重试多次重试仍不正常导致整个任务失败应用不能按时完成资源不能释放后续的任务不断请求资源系统调用暴增甚至演变为集群雪崩大数据处理步骤Map阶段→shuffle→Reduce阶段Map task数据倾斜输入文件导致的数据倾斜①不可切分的压缩算法②数据文件大小不一致Reduce task数据倾斜最常见①数据中有很多空值被分配到同一分区→过滤数据解决异常数据带来的数据倾斜②ShuffleKey分布不均主要原因→消除shuffle、改变Reduce并行度、加盐打散给key添加随机数强行打散数据分析数据必须先处理数据分析数据主要包括以下内容1、数据的整体规模数据规模有多大、文件有多少个、每个文件的大小、预估资源的开销2、数据的存储格式普通文件格式、列族存储的文件格式、文件是否压缩、压缩格式是什么3、数据列值的分布每一列有值的行数、每个值的行数分布特别是key相关的列、分析列值分布可以通过数据采样完成数据倾斜处理依赖这一步的数据列值分布结果数据倾斜判定条件外在表象①Executor lost、OOM、Shuffle过程频繁出现错误信息②单个Executor执行时间特别久整体任务卡在某个阶段不能结束③正常运行的任务突然失败大多数Task运行正常个别Task运行缓慢或发生OOM最根本的原因资源分配不均如何定位数据倾斜1、借助Spark Web UI2、定位shuffle算子秘籍1——消除map端的数据倾斜文件采用了不支持splittable的压缩算法文件大小不一致。如下图所示常用的压缩算法以及是否支持切分如下图所示。解决办法增加数据预处理秘籍2——过滤异常数据对key进行的数据特征分析可以发现是否有异常数据①null(空值)或是一些无意义的信息之类的大多是这个原因引起②无效数据对结果影响不大的有效数据或是大量重复的测试数据③正常数据业务导致的数据分布对于①②两种情况对数据进行预处理过滤即可。为什么Key分布不均匀①填充默认值②业务本身存在热点③存在恶意数据解决办法①过滤数据解决异常数据带来的数据倾斜②消除shuffle③改变Reduce并行度④加盐。给key添加随机数强行打散数据秘籍3——Map side join正常执行join操作也叫Reduce side join时要对数据进行分区不可避免的带来了shuffle如果是大表与小表做关联可采用map side join彻底消除shuffle进而规避数据倾斜此时解决数据倾斜就要用map端的join,把小数据集发送到大数据集的每个分区当中通过广播变量此时没有shuffle数据没有发生移动且map端移动的数据没有数据倾斜现象。所以整体没有数据倾斜。通俗理解假设你有两张表一张是巨无霸用户行为日志1TB一张是小卡片用户基本信息只有100MB。既然小表那么小干脆把小表复制成无数份发送计算大表的每一个机器节点上这就是广播变量。每一台机器在读取大表的数据块时当场在Map阶段就在本地内存里跟小表进行关联。大表的数据不需要移动小表是被“广播”过去的。通过广播变量高效分发到集群中数据压缩、高效的通信框架Netty、BT协议关于广播变量1、广播变量只读由BlockManager管理2、广播变量要能序列化3、由Driver广播到Executor过程中使用BT传输协议4、广播变量可被Excutor中的多个Task共享5、在SparkSQL中广播变量缺省大小为10M6、广播变量会使Driver的内存膨胀①JVM的存储密度低②广播变量会在内存中分割分割完成之前内存中有两份相同大小的广播变量秘籍4——改变Reduce的并行度调整并行度改变了Shuffle过程中数据的去向下图中左侧部分reduce个数为3右侧部分的reduce个数为4看余数为多少则放到哪个分区秘籍5——两极端聚合1、加盐打散key。给每个key都加上一个随机数如10以内的随机数【加盐】此时key被打散2、局部聚合。对打上随机数的key执行一次聚合操作得到结果3、全局聚合。将key的前缀/后缀去掉再进行一次聚合操作得到最终结果秘籍6——大表加盐小表扩容如果出现数据倾斜的Key比较多无法将这些倾斜Key分拆出来此时更适合直接对存在数据倾斜的数据集全部加上随机前缀然后对另外一个数据集整体扩容加盐打散key消除数据倾斜扩容保证join能正常执行扩容增大了整体的数据量但是由于消除了数据倾斜提高了体系的整体利用率
