Spark核心之05:sparkOnYarn、资源参数、调度模式、资源分配策略、shuffle机制??
spark内存计算框架
一、主题
- spark on yarn原理和机制(★★★★★)
- collect算子操作剖析
- spark任务的资源参数剖析(★★★★★)
- spark任务的调度模式
- spark任务的资源分配策略
- spark的shuffle原理分析(★★★★★)
二、要点
1. spark on yarn
- 可以把spark程序提交到yarn中去运行,此时spark任务所需要的计算资源由yarn中的老大ResourceManager去分配
- 官网资料地址
- http://spark.apache.org/docs/2.3.3/running-on-yarn.html
- 环境准备
- 1、安装hadoop集群
- 2、安装spark环境
- 注意这里不需要安装spark集群
- 只需要解压spark安装包到任意一台服务器
- 修改文件 spark-env.sh
- 只需要解压spark安装包到任意一台服务器
- 注意这里不需要安装spark集群
#指定java的环境变量
export JAVA_HOME=/kkb/install/jdk1.8.0_141
#指定hadoop的配置文件目录
export HADOOP_CONF_DIR=/kkb/install/hadoop-2.6.0-cdh5.14.2/etc/hadoop
- 按照Spark应用程序中的driver分布方式不同,Spark on YARN有两种模式:
yarn-client
模式、yarn-cluster
模式
1.1 yarn-cluster模式
- yarn-cluster模式下提交任务示例
spark-submit --class org.apache.spark.examples.SparkPi \
--master yarn \
--deploy-mode cluster \
--driver-memory 1g \
--executor-memory 1g \
--executor-cores 1 \
/kkb/install/spark/examples/jars/spark-examples_2.11-2.3.3.jar \
10
-
如果运行出现错误,可能是虚拟内存不足,可以添加参数
- vim yarn-site.xml
<!--容器是否会执行物理内存限制默认为True--> <property> <name>yarn.nodemanager.pmem-check-enabled</name> <value>false</value> </property> <!--容器是否会执行虚拟内存限制 默认为True--> <property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property>
1.2 yarn-client模式
- yarn-client模式下提交任务示例
spark-submit --class org.apache.spark.examples.SparkPi \
--master yarn \
--deploy-mode client \
--driver-memory 1g \
--executor-memory 1g \
--executor-cores 1 \
/kkb/install/spark/examples/jars/spark-examples_2.11-2.3.3.jar \
10
1.3 两种模式的原理
- yarn-cluster模式
- yarn-client模式
⭐️1.4 两种模式的区别
-
yarn-cluster模式
- spark程序的Driver程序在YARN中运行,运行结果不能在客户端显示,并且客户端可以在启动应用程序后消失应用的。
- 最好运行那些将结果最终保存在外部存储介质(如HDFS、Redis、Mysql),客户端的终端显示的仅是作为YARN的job的简单运行状况。
-
yarn-client模式
- spark程序的Driver运行在Client上,应用程序运行结果会在客户端显示,所有适合运行结果有输出的应用程序(如spark-shell)
-
总结
最大的区别就是Driver端的位置不一样。 yarn-cluster: Driver端运行在yarn集群中,与ApplicationMaster进程在一起。 yarn-client: Driver端运行在提交任务的客户端,与ApplicationMaster进程没关系,经常 用于进行测试
2. collect 算子操作剖析
- collect算子操作的作用
- 1、它是一个action操作,会触发任务的运行
- 2、它会把RDD的数据进行收集之后,以数组的形式返回给Driver端
-
总结:
-
默认Driver端的内存大小为1G,由参数 spark.driver.memory 设置
-
如果某个rdd的数据量超过了Driver端默认的1G内存,对rdd调用collect操作,这里会出现Driver端的内存溢出,所有这个collect操作存在一定的风险,实际开发代码一般不会使用。
-
实际企业中一般都会把该参数调大,比如5G/10G等
-
可以在代码中修改该参数,如下
new SparkConf().set("spark.driver.memory","5G")
-
-
比如说rdd的数据量达到了10G
rdd.collect这个操作非常危险,很有可能出现driver端的内存不足
⭐️3. spark任务中资源参数剖析
- 通过开发工具开发好spark程序后达成jar包最后提交到集群中运行
- 提交任务脚本如下
spark-submit \
--master spark://node01:7077,node02:7077 \
--class com.kaikeba.WordCountOnSpark \
--executor-memory 1g \
--total-executor-cores 4 \
original-spark_class03-1.0-SNAPSHOT.jar \
/words.txt /out
-
–executor-memory
- 表示每一个executor进程需要的内存大小,它决定了后期操作数据的速度
比如说一个rdd的数据量大小为5g,这里给定的executor-memory为2g, 在这种情况下,内存是存储不下,它会把一部分数据保存在内存中,还有一部分数据保存在磁盘,后续需要用到该rdd的结果数据,可以从内存和磁盘中获取得到,这里就涉及到一定的磁盘io操作。 ,这里给定的executor-memory为10g,这里数据就可以完全在内存中存储下,后续需要用到该rdd的数据,就可以直接从内存中获取,这样一来,避免了大量的磁盘io操作。性能得到提升。 在实际的工作,这里 --executor-memory 需要设置的大一点。 比如说10G/20G/30G等
-
–total-executor-cores
- 表示任务运行需要总的cpu核数,它决定了任务并行运行的粒度
比如说要处理100个task,注意一个cpu在同一时间只能处理一个task线程。 如果给定的总的cpu核数是5个,这里就需要100/5=20个批次才可以把这100个task运行完成,如果平均每个task运行1分钟,这里最后一共运行20分钟。 如果给定的总的cpu核数是20个,这里就需要100/20=5个批次才可以把这100个task运行完成,如果平均每个task运行1分钟,这里最后一共运行5分钟。 如果如果给定的总的cpu核数是100个,这里就需要100/100=1个批次才可以把这100个task运行完成,如果平均每个task运行1分钟,这里最后一共运行1分钟。 在实际的生产环境中,--total-executor-cores 这个参数一般也会设置的大一点, 比如说 30个/50个/100个
-
总结
后期对于spark程序的优化,可以从这2个参数入手,无论你把哪一个参数调大,对程序运行的效率来说都会达到一定程度的提升 加大计算资源它是最直接、最有效果的优化手段。 在计算资源有限的情况下,可以考虑其他方面,比如说代码层面,JVM层面等
4. spark任务的调度模式
- Spark中的调度模式主要有两种:FIFO 和 FAIR
- FIFO(先进先出)
- 默认情况下Spark的调度模式是FIFO,谁先提交谁先执行,后面的任务需要等待前面的任务执行。
- FAIR(公平调度)
- 支持在调度池中为任务进行分组,不同的调度池权重不同,任务可以按照权重来决定执行顺序。避免大任务运行时间长,占用了大量的资源,后面小任务无法提交运行。
- FIFO(先进先出)
5. spark任务的分配资源策略
-
给application分配资源选择worker(executor),现在有两种策略
- 尽量的打散,即一个Application尽可能多的分配到不同的节点。这个可以通过设置spark.deploy.spreadOut来实现。默认值为true,即尽量的打散(默认)
- 可以充分的发挥数据的本地性,提升执行效率
- 尽量的集中,即一个Application尽量分配到尽可能少的节点。
- 尽量的打散,即一个Application尽可能多的分配到不同的节点。这个可以通过设置spark.deploy.spreadOut来实现。默认值为true,即尽量的打散(默认)
⭐️6. spark的shuffle原理分析
6.1 shuffle概述
Shuffle就是对数据进行重组,由于分布式计算的特性和要求,在实现细节上更加繁琐和复杂。
在MapReduce框架,Shuffle是连接Map和Reduce之间的桥梁,Map阶段通过shuffle读取数据并输出到对应的Reduce;而Reduce阶段负责从Map端拉取数据并进行计算。在整个shuffle过程中,往往伴随着大量的磁盘和网络I/O。所以shuffle性能的高低也直接决定了整个程序的性能高低。Spark也会有自己的shuffle实现过程。
6.2 spark中的shuffle介绍
在DAG调度的过程中,Stage阶段的划分是根据是否有shuffle过程,也就是存在wide Dependency宽依赖的时候,需要进行shuffle,这时候会将作业job划分成多个Stage,每一个stage内部有很多可以并行运行的task。
stage与stage之间的过程就是shuffle阶段,在Spark的中,负责shuffle过程的执行、计算和处理的组件主要就是ShuffleManager,也即shuffle管理器。ShuffleManager随着Spark的发展有两种实现的方式,分别为
//HashShuffleManager和SortShuffleManager,
因此spark的Shuffle有Hash Shuffle和Sort Shuffle两种。
⭐️6.3 HashShuffle机制
6.3.1 HashShuffle概述
在Spark 1.2以前,默认的shuffle计算引擎是HashShuffleManager。
该ShuffleManager-HashShuffleManager有着一个非常严重的弊端,就是会产生大量的中间磁盘文件,进而由大量的磁盘IO操作影响了性能。因此在Spark 1.2以后的版本中,默认的ShuffleManager改成了SortShuffleManager。
SortShuffleManager相较于HashShuffleManager来说,有了一定的改进。主要就在于每个Task在进行shuffle操作时,虽然也会产生较多的临时磁盘文件,但是最后会将所有的临时文件合并(merge)成一个磁盘文件,因此每个Task就只有一个磁盘文件。在下一个stage的shuffle read task拉取自己的数据时,只要根据索引读取每个磁盘文件中的部分数据即可。
- Hash shuffle
- HashShuffleManager的运行机制主要分成两种
- 一种是普通运行机制
- 另一种是合并的运行机制。
- 合并机制主要是通过复用buffer来优化Shuffle过程中产生的小文件的数量。
- Hash shuffle是不具有排序的Shuffle。
- HashShuffleManager的运行机制主要分成两种
6.3.2 普通机制的Hash shuffle
- 图解
这里我们先明确一个假设前提:每个Executor只有1个CPU core,也就是说,无论这个Executor上分配多少个task线程,同一时间都只能执行一个task线程。
图中有3个ReduceTask,从ShuffleMapTask 开始那边各自把自己进行 Hash 计算(分区器:hash/numreduce取模),分类出3个不同的类别,每个 ShuffleMapTask 都分成3种类别的数据,想把不同的数据汇聚然后计算出最终的结果,所以ReduceTask 会在属于自己类别的数据收集过来,汇聚成一个同类别的大集合,每1个 ShuffleMapTask 输出3份本地文件,这里有4个 ShuffleMapTask,所以总共输出了4 x 3个分类文件 = 12个本地小文件。
- shuffle Write阶段
主要就是在一个stage结束计算之后,为了下一个stage可以执行shuffle类的算子(比如reduceByKey,groupByKey),而将每个task处理的数据按key进行“分区”。所谓“分区”,就是对相同的key执行hash算法,从而将相同key都写入同一个磁盘文件中,而每一个磁盘文件都只属于reduce端的stage的一个task。在将数据写入磁盘之前,会先将数据写入内存缓冲中,当内存缓冲填满之后,才会溢写到磁盘文件中去。
那么每个执行shuffle write的task,要为下一个stage创建多少个磁盘文件呢? 很简单,下一个stage的task有多少个,当前stage的每个task就要创建多少份磁盘文件。比如下一个stage总共有100个task,那么当前stage的每个task都要创建100份磁盘文件。如果当前stage有50个task,总共有10个Executor,每个Executor执行5个Task,那么每个Executor上总共就要创建500个磁盘文件,所有Executor上会创建5000个磁盘文件。由此可见,未经优化的shuffle write操作所产生的磁盘文件的数量是极其惊人的。
- shuffle Read阶段
shuffle read,通常就是一个stage刚开始时要做的事情。此时该stage的每一个task就需要将上一个stage的计算结果中的所有相同key,从各个节点上通过网络都拉取到自己所在的节点上,然后进行key的聚合或连接等操作。由于shuffle write的过程中,task给Reduce端的stage的每个task都创建了一个磁盘文件,因此shuffle read的过程中,每个task只要从上游stage的所有task所在节点上,拉取属于自己的那一个磁盘文件即可。
shuffle read的拉取过程是一边拉取一边进行聚合的。每个shuffle read task都会有一个自己的buffer缓冲,每次都只能拉取与buffer缓冲相同大小的数据,然后通过内存中的一个Map进行聚合等操作。聚合完一批数据后,再拉取下一批数据,并放到buffer缓冲中进行聚合操作。以此类推,直到最后将所有数据到拉取完,并得到最终的结果。
- 注意
(1)buffer起到的是缓存作用,缓存能够加速写磁盘,提高计算的效率,buffer的默认大小32k。
(2)分区器:根据hash/numRedcue取模决定数据由几个Reduce处理,也决定了写入几个buffer中
(3)block file:磁盘小文件,从图中我们可以知道磁盘小文件的个数计算公式:
block file=M*R
(4) M为map task的数量,R为Reduce的数量,一般Reduce的数量等于buffer的数量,都是由分区器决定的
- Hash shuffle普通机制的问题
(1).Shuffle阶段在磁盘上会产生海量的小文件,建立通信和拉取数据的次数变多,此时会产生大量耗时低效的 IO 操作 (因为产生过多的小文件)
(2).可能导致OOM,大量耗时低效的 IO 操作 ,导致写磁盘时的对象过多,读磁盘时候的对象也过多,这些对象存储在堆内存中,会导致堆内存不足,相应会导致频繁的GC,GC会导致OOM。由于内存中需要保存海量文件操作句柄和临时信息,如果数据处理的规模比较庞大的话,内存不可承受,会出现 OOM 等问题
6.3.3 合并机制的Hash shuffle
合并机制就是复用buffer缓冲区,开启合并机制的配置是spark.shuffle.consolidateFiles。该参数默认值为false,将其设置为true即可开启优化机制。通常来说,如果我们使用HashShuffleManager,那么都建议开启这个选项。
- 图解
这里有6个这里有6个shuffleMapTask,数据类别还是分成3种类型,因为Hash算法会根据你的 Key 进行分类,在同一个进程中,无论是有多少过Task,都会把同样的Key放在同一个Buffer里,然后把Buffer中的数据写入以Core数量为单位的本地文件中,(一个Core只有一种类型的Key的数据),每1个Task所在的进程中,分别写入共同进程中的3份本地文件,这里有6个shuffleMapTasks,所以总共输出是 2个Cores x 3个分类文件 = 6个本地小文件。
- 注意
(1).启动HashShuffle的合并机制ConsolidatedShuffle的配置
spark.shuffle.consolidateFiles=true
(2).block file=Core*R
Core为CPU的核数,R为Reduce的数量
- Hash shuffle合并机制的问题
如果 Reducer 端的并行任务或者是数据分片过多的话则 Core * Reducer Task 依旧过大,也会产生很多小文件。
⭐️6.4 Sort shuffle
- SortShuffleManager的运行机制主要分成两种,
- 一种是普通运行机制
- 另一种是bypass运行机制
6.4.1 Sort shuffle的普通机制
- 图解
在该模式下,数据会先写入一个数据结构,聚合算子写入Map,一边通过Map局部聚合,一边写入内存。Join算子写入ArrayList直接写入内存中。然后需要判断是否达到阈值(5M),如果达到就会将内存数据结构的数据写入到磁盘,清空内存数据结构。
在溢写磁盘前,先根据key进行排序,排序过后的数据,会分批写入到磁盘文件中。默认批次为10000条,数据会以每批一万条写入到磁盘文件。写入磁盘文件通过缓冲区溢写的方式,每次溢写都会产生一个磁盘文件,也就是说一个task过程会产生多个临时文件
。
最后在每个task中,将所有的临时文件合并,这就是merge过程,此过程将所有临时文件读取出来,一次写入到最终文件。意味着一个task的所有数据都在这一个文件中。同时单独写一份索引文件,标识下游各个task的数据在文件中的索引start offset和end offset。
这样算来如果第一个stage 50个task,每个Executor执行一个task,那么无论下游有几个task,就需要50*2=100个磁盘文件。
- 好处
1. 小文件明显变少了,一个task只生成一个file文件
2. file文件整体有序,加上索引文件的辅助,查找变快,虽然排序浪费一些性能,但是查找变快很多
6.4.2 bypass模式的sortShuffle
- bypass机制运行条件
- shuffle map task数量小于spark.shuffle.sort.bypassMergeThreshold参数的值
- 不是聚合类的shuffle算子(比如reduceByKey)
- 好处
该机制与sortshuffle的普通机制相比,在shuffleMapTask不多的情况下,首先写的机制是不同,其次不会进行排序。这样就可以节约一部分性能开销。
- 总结
在shuffleMapTask数量小于默认值200时,启用bypass模式的sortShuffle(原因是数据量本身比较少,没必要进行sort全排序,因为数据量少本身查询速度就快,正好省了sort的那部分性能开销。)
该机制与普通SortShuffleManager运行机制的不同在于:
第一: 磁盘写机制不同;
第二: 不会进行sort排序;
三、总结
-
1、spark on yarn 原理和机制(★★★★★)
- yarn-client
- yarn-cluster
-
2、collect算子操作作用
- 第一点
- 它是一个action触发任务的真正运行
- 第二点
- 它会把rdd的数据进行收集之后,以数组的形式返回给Driver端
- 第一点
-
3、spark中计算资源的参数说明(★★★★★)
- –executor-memory
- –total-executor-cores
-
4、spark的shuffle原理分析(★★★★★)
- HashShuffle
- 普通的hashShuffle
- 合并机制的hashShuffle
- 重复利用buffer缓冲区,减少生成的磁盘文件个数
- sort Shuffle
- 普通的sortShuffle
- 后期会进行数据的排序,并且一个task生成一个磁盘文件和一个索引文件
- bypass模式的sortShuffle
- 这里可以通过参数去控制是否需要排序。
- spark.shuffle.sort.bypassMergeThreshold<=200
- 普通的sortShuffle
- HashShuffle