如果有可能的话,尽量避免使用shuffle类算子.因为Spark作业运行过程中,最消耗性能的地方就是shuffle过程.shuffle过程,就是将分布在集群中多个节点上的同一个key,拉取到同一个节点上,进行聚合或join等操作.比如reduceByKey.join等算子,都会触发shuffle操作. shuffle过程中,各个节点上的相同key都会先写入本地磁盘文件中,然后其他节点需要通过网络传输拉取各个节点上的磁盘文件中的相同key.而且相同key都拉取到同一个节点进行聚合操作时,还有可能会

Spark优化一则 - 减少Shuffle 看了Spark Summit 2014的A Deeper Understanding of Spark Internals,视频(要***)详细讲解了Spark的工作原理,Slides的45页给原始算法和优化算法. 破砂锅用自己3节点的Spark集群试验了这个优化算法,并进一步找到更快的算法.测试数据是Sogou实验室的日志文件前10000000条数据.目标是对日志第2列数据,按照第一个字母合并,得到每个首字母有几条记录. 所有的方案都重新启动Spar

Spark的性能分析和调优很有意思,今天再写一篇.主要话题是shuffle,当然也牵涉一些其他代码上的小把戏. 以前写过一篇文章,比较了几种不同场景的性能优化,包括portal的性能优化,web service的性能优化,还有Spark job的性能优化.Spark的性能优化有一些特殊的地方,比如实时性一般不在考虑范围之内,通常我们用Spark来处理的数据,都是要求异步得到结果的数据:再比如数据量一般都很大,要不然也没有必要在集群上操纵这么一个大家伙,等等.事实上,我们都知道没有银弹,但是每一种

通过上面的架构和源码实现的分析,不难得出Shuffle是Spark Core比较复杂的模块的结论.它也是非常影响性能的操作之一.因此,在这里整理了会影响Shuffle性能的各项配置.尽管大部分的配置项在前文已经解释过它的含义,由于这些参数的确是非常重要,这里算是做一个详细的总结. 1.1.1  spark.shuffle.manager 前文也多次提到过,Spark1.2.0官方支持两种方式的Shuffle,即Hash Based Shuffle和Sort Based Shuffle.其中在Sp

回忆一下,每个Stage的上边界,要么需要从外部存储读取数据,要么需要读取上一个Stage的输出:而下边界,要么是需要写入本地文件系统(需要Shuffle),以供childStage读取,要么是最后一个Stage,需要输出结果.这里的Stage,在运行时的时候就是可以以pipeline的方式运行的一组Task,除了最后一个Stage对应的是ResultTask,其余的Stage对应的都是ShuffleMap Task. 而除了需要从外部存储读取数据和RDD已经做过cache或者checkpoin

Shuffle Map Task运算结果的处理 这个结果的处理,分为两部分,一个是在Executor端是如何直接处理Task的结果的:还有就是Driver端,如果在接到Task运行结束的消息时,如何对Shuffle Write的结果进行处理,从而在调度下游的Task时,下游的Task可以得到其需要的数据. Executor端的处理 在解析BasicShuffle Writer时,我们知道ShuffleMap Task在Executor上运行时,最终会调用org.apache.spark.sche

首先介绍一下需要实现的接口.框架的类图如图所示(今天CSDN抽风,竟然上传不了图片.如果需要实现新的Shuffle机制,那么需要实现这些接口. 1.1.1  org.apache.spark.shuffle.ShuffleManager Driver和每个Executor都会持有一个ShuffleManager,这个ShuffleManager可以通过配置项spark.shuffle.manager指定,并且由SparkEnv创建.Driver中的ShuffleManager负责注册Shuffl

一 简介 Shuffle,简而言之,就是对数据进行重新分区,其中会涉及大量的网络io和磁盘io,为什么需要shuffle,以词频统计reduceByKey过程为例, serverA:partition1: (hello, 1), (word, 1)serverB:partition2: (hello, 2) shuffle之后: serverA:partition1: (hello, 1), (hello, 2)serverB:partition2: (word, 1) 最后才能得到结果: (h

[生产实践经验] 生产实践中的切身体会是:影响Spark性能的大BOSS就是shuffle,抓住并解决shuffle这个主要原因,事半功倍. [Shuffle原理学习笔记] 1.未经优化的HashShuffleManager 注:这是spark1.2版本之前,最早使用的shuffle方法,这种shuffle方法不要使用,只是用来对比改进后的shuffle方法.  如上图,上游每个task 都输出下游task个数的结果文件,下游每个task去上游task输出的结果文件中获取对应自己的. 问题: 生

参考详细探究Spark的shuffle实现, 写的很清楚, 当前设计的来龙去脉 Hadoop Hadoop的思路是, 在mapper端每次当memory buffer中的数据快满的时候, 先将memory中的数据, 按partition进行划分, 然后各自存成小文件, 这样当buffer不断的spill的时候, 就会产生大量的小文件 所以Hadoop后面直到reduce之前做的所有的事情其实就是不断的merge, 基于文件的多路并归排序, 在map端的将相同partition的merge到一起,

调优概述 大多数Spark作业的性能主要就是消耗在了shuffle环节,因为该环节包含了大量的磁盘IO.序列化.网络数据传输等操作.因此,如果要让作业的性能更上一层楼,就有必要对shuffle过程进行调优.但是也必须提醒大家的是,影响一个Spark作业性能的因素,主要还是代码开发.资源参数以及数据倾斜,shuffle调优只能在整个Spark的性能调优中占到一小部分而已.因此大家务必把握住调优的基本原则,千万不要舍本逐末.下面我们就给大家详细讲解shuffle的原理,以及相关参数的说明,同时给出各

Shuffle输出追踪者--MapOutputTracker 这个组件作为shuffle的一个辅助组件,在整个shuffle模块中具有很重要的作用.我们在前面一系列的分析中,或多或少都会提到这个组件,比如在DAGScheduler提交一个stage时会将这个stage封装成一个任务集(TaskSet),但是可能有的分区已经计算过了,有了结果(stage由于失败可能会多次提交,其中有部分task可能已经计算完成),这些分区就不需要再次计算,而只需要计算那些失败的分区,那么很显然需要有一个组件来维护

shuffle读过程源码分析 上一篇中,我们分析了shuffle在map阶段的写过程.简单回顾一下,主要是将ShuffleMapTask计算的结果数据在内存中按照分区和key进行排序,过程中由于内存限制会溢写出多个磁盘文件,最后会对所有的文件和内存中剩余的数据进行归并排序并溢写到一个文件中,同时会记录每个分区(reduce端分区)的数据在文件中的偏移,并且把分区和偏移的映射关系写到一个索引文件中. 好了,简单回顾了写过程后,我们不禁思考,reduce阶段的数据读取的具体过程是什么样的?数据读取的

ShuffleManager(一) 本篇,我们来看一下spark内核中另一个重要的模块,Shuffle管理器ShuffleManager.shuffle可以说是分布式计算中最重要的一个概念了,数据的join,聚合去重等操作都需要这个步骤.另一方面,spark之所以比mapReduce的性能高其中一个主要的原因就是对shuffle过程的优化,一方面spark的shuffle过程更好地利用内存(也就是我们前面在分析内存管理时所说的执行内存),另一方面对于shuffle过程中溢写的磁盘文件归并排序和引

摘要: 1 shuffle原理 1.1 mapreduce的shuffle原理 1.1.1 map task端操作 1.1.2 reduce task端操作 1.2 spark现在的SortShuffleManager 2 Shuffle操作问题解决 2.1 数据倾斜原理 2.2 数据倾斜问题发现与解决 2.3 数据倾斜解决方案 3 spark RDD中的shuffle算子 3.1 去重 3.2 聚合 3.3 排序 3.4 重分区 3.5 集合操作和表操作 4 spark shuffle参数调优

依据Spark 1.4版 在哪里会用到它 ExternalSorter是Spark的sort形式的shuffle实现的关键.SortShuffleWriter使用它,把RDD分区中的数据写入文件. override def write(records: Iterator[Product2[K, V]]): Unit = { if (dep.mapSideCombine) {//根据是否需要mqp-side combine创建不同的sorter require(dep.aggregator.isD

开发调优篇 原则一:避免创建重复的RDD 通常来说,我们在开发一个Spark作业时,首先是基于某个数据源(比如Hive表或HDFS文件)创建一个初始的RDD:接着对这个RDD执行某个算子操作,然后得到下一个RDD:以此类推,循环往复,直到计算出最终我们需要的结果.在这个过程中,多个RDD会通过不同的算子操作(比如map.reduce等)串起来,这个“RDD串”,就是RDD lineage,也就是“RDD的血缘关系链”. 我们在开发过程中要注意:对于同一份数据,只应该创建一个RDD,不能创建多个R

一.数据倾斜发生的原理 原理:在进行shuffle的时候,必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理,比如按照key进行聚合或join等操作.此时如果某个key对应的数据量特别大的话,就会发生数据倾斜.数据倾斜只会发生在shuffle过程中.常用的并且可能会触发shuffle操作的算子:distinct.groupByKey.reduceByKey.aggregateByKey.join.cogroup.repartition等. 表现:Spark作业看起来会运行得非常

Apache Spark探秘:Spark Shuffle实现 http://dongxicheng.org/framework-on-yarn/apache-spark-shuffle-details/ 对于大数据计算框架而言,Shuffle阶段的设计优劣是决定性能好坏的关键因素之一.本文将介绍目前Spark的shuffle实现,并将之与MapReduce进行简单对比.本文的介绍顺序是:shuffle基本概念,MapReduce Shuffle发展史以及Spark Shuffle发展史. (1)

本博文的主要内容: 1.Hash Shuffle彻底解密 2.Shuffle Pluggable解密 3.Sorted Shuffle解密 4.Shuffle性能优化 一:到底什么是Shuffle? Shuffle中文翻译为"洗牌",需要Shuffle的关键性原因是某种具有共同特征的数据需要最终汇聚到一个计算节点上进行计算. 二:Shuffle可能面临的问题? 运行Task的时候才会产生Shuffle(Shuffle已经融化在Spark的算子中了). 1. 数据量非常大:[几千甚至上万