技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 查看专题: shuffle
    Spark的性能优化有一些特殊的地方,比如实时性一般不在考虑范围之内,通常我们用Spark来处理的数据,都是要求异步得到结果的数据;再比如数据量一般都很大,要不然也没有必要在集群上操纵这么一个大家伙,等等。事实上,我们都知道没有银弹,但是每一种性能优化场景都有一些特定的“大boss”,通常抓住和解决大boss以后,能解决其中一大部分问题。比如对于portal来说,是页面静态化,对于web service来说,是高并发(当然,这两种可以说并不确切,这只是针对我参与的项目总结的经验而已),而对于Spark来说,这个大boss就是shuffle。
    在做Shuffle阶段的优化过程中,遇到了数据倾斜的问题,造成了对一些情况下优化效果不明显。主要是因为在Job完成后的所得到的Counters是整个Job的总和,优化是基于这些Counters得出的平均值,而由于数据倾斜的原因造成map处理数据量的差异过大,使得这些平均值能代表的价值降低。Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个reduce中,就是解决数据倾斜的根本所在。规避错误来更好的运行比解决错误更高效。在查看了一些资料后,总结如下。 1数据倾斜的原因 1.1操作: 关键词 情形 后果 Join 其中一个表较小, 但是key集中 分发到某一个或几个Reduce上的数据远高于平均值 大表与大表,但是分桶的判断字段0值或空值过多 这些空值都由一个reduce处理,灰常慢 group by group by
[ 共2篇文章 ][ 第1页/共1页 ][ 1 ]
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1