spark之资源分配
1.分配哪些资源
executor,cpu per executor,memory per executor,driver-memory
2.在哪里分配这些资源
/usr/local/spark/bin/spark-submit \
--class cn.spark.sparktest.core.WordCountCluster \
--num-executors 3\ 配置executor的数量
--driver-memory 100m \ 配置driver的内存（影响不大）
--executor-memory 100 \ 配置每个executor的cpu core数量
--executor-cores 3 \
/usr/local/SparkTest-0.0.1-SNAPSHOT-jar-with-dependencies.jar \
3.调节到多大算大呢？
第一种，Spark Standalone,公司集群上，搭建了一套Spark集群，你心里应该清楚每台机器还能给你使用的，大概有多少内存，多少cup core；那么设置的时候，就根据这个实际的情况，去调节每个spark作业的资源分配。比如说你的每台机器能够给你使用4G内存，2个cup core；20台机器；executor 20；4G内存，2个cup core，平均每个executor
第二种，yarn 资源队列，资源调度。应该去查看你的spark作业，要提交到的资源队列，大概有多少资源？ 500G内存，100个cpu core；executor，50；10G内存，2个cup core，平均每个executor
4.为什么调节资源后，性能可以提升？
1.增加executor
如果executor数量比较少，那么，能够并行执行的task数量就比较少，意味着，我们的application的并行执行的能力就很弱。比如有3个executor，每个executor有2个cup core，那么同时能够并行执行的task，就是6个。6个执行完以后，再换下一批6个task。增加了executor的数量后，可以并行执行的任务就变多了
2.增加每个executor的cpu core ，也是增加执行的并行能力
3.增加每个executor的内存量，增加了内存量以后，对性能的提升，有两点：
1、如果需要对rdd进行cache，那么更多的内存，就可以缓存更多的数据，将更少的数据写入磁盘，甚至不写入磁盘，减少了磁盘io
2、对于shuffle操作，reduce端，会需要更多的内存存放拉取的数据并进行聚合，如果内存不够，也会写入磁盘，如果给executor分配更多内存以后，就有更少的数据写入磁盘，甚至不需要写入磁盘，减少io，提升性能
3、对于task 的执行，可能会创建很多对象，如果内存比较小，可能会频繁导致JVM堆内存满了，然后频繁GC，垃圾回收，minor GC和full GC（速度很慢）。内存加大后，带来更少的GC，垃圾回收，避免了速度变慢
spark优化之调节并行度
1、task数量，至少设置成与Spark application的总cup core数量相同（最理想的情况，比如总共150个cpu core，分配了150个task，一起运行，差不多同一时间运行完毕）
2、官方是推荐，task数量，设置成spark application总cpu core数量的2-3倍，比如150个cpu core ，基本要设值task数量为300-500；
实际情况与理想情况不同，有些task会运行的快点，比如50s就完了，有些task可能会运行的慢点，要1分半才运行完，所以你的task数量，刚好设置的根cpu core数量相同，可能还是会导致资源的浪费，比如150个task，10个先运行完了，剩余140个还在运行，但是这个时候，有10个cpu core空闲出来了，就导致了浪费。
3、如何设置一个Spark Application的并行度？
Spark.default.parallelism
SparkConf conf = new SparkConf().set("Spark.default.parallelism","500")
spark优化之重构RDD架构以及RDD持久化
第一，RDD架构重构与优化
尽量去复用RDD，差不多的RDD，可以抽取为一个共同的RDD，供后面的RDD计算时，反复使用
第二，公共RDD一定要实现持久化
对于多次计算和使用的公共RDD，一定要进行持久化，也就是说，将RDD的数据缓存到内存、磁盘中，以后无论对这个RDD做多少次计算，那么都是直接取这个RDD的持久化的数据
第三，持久化是可以进行序列化的
如果正常将数据持久化内存中，那么可能导致内存的占用过大，这样的话，也许，会导致OOM内存溢出。
当纯内存无法支持公共RDD数据完全存放的时候，就有限考虑，使用序列化的方式在纯内存中存储，将RDD的每个partition的数据，序列化成一个大的字节数组，就一个对象，序列化后，大大减少内存的空间占用。
序列化的方式，唯一的缺点就是，在获取数据的时候，需要反序列，如果序列化纯内存方式还是导致OOM，内存溢出，就只能考虑磁盘的方式
RDD持久化
将数据通过持久化（或缓存）在内存中是Spark的重要功能之一，当你缓存了一个RDD，每个节点都缓存了RDD的所有分区，这样就可以在内存中进行计算，这样可以使以后在RDD上的动作更快（通常可以提高10倍）
RDD通过使用persist或cache方法进行标记，他通过动作操作第一次在RDD上进行计算后，他就会被缓存在节点上的内存中，spark的缓存具有容错性，如果RDD的某一分区丢失，它会自动使用最初创建RDD时的转换操作进行重新计算
持久化方法选择：persist（StorageLevel）
1.第一种选择：persist（StorageLevel.Memory_only）,纯内存，无序列化，可以使用cache()方法代替
2.第二种选择：StorageLevel.Memory_only_ser 纯内存序列化
3.第三种选择：StorageLevel.Memory_and_desk 纯内存加磁盘
4.第四种选择：StorageLevel.Memory_and_desk_ser 纯内存加磁盘序列化
5.第五种选择：StorageLevel.Memory_desk_ser 纯磁盘
第四，为了数据的高可靠性，而且内存充足，可以使用双副本机制，进行持久化
持久化的双副本机制，持久化后的一个副本，因为机器宕机了，副本丢了，就还是得重新计算一次，持久化的每个数据单元，存储一份副本，放在其他节点上面；从而进行容错；一个副本丢了，不用重新计算，还可以使用另外一个副本。
这种方式仅仅针对你的内存资源极度充足
RDD本身（内存中），只有一个副本，如果丢失需要重新计算
RDD落地到hdfs，可以配置副本数：spark.hadoop.dfs.replication=2
spark优化之广播大变量
问题：没有广播的时候遇到了一个大变量map
比如：task执行的算子中，使用了外部的变量，每个task都会获取一份变量的副本，有什么缺点呢？在什么情况下，会出现性能上的恶劣影响呢？
map，本身是不小，存放数据的一个单位是entry，还有可能会用链表的格式来存放entry链条，所有map是比较消耗内存的数据格式。
加入有1000个task，这些task都用到了占用1m内存的map，那么首先，map会拷贝1000份副本，通过网络传输到各个task中，给task使用，总计有1G的数据，会通过网络传输，网络传输的开销，不容乐观！！网络传输也许就会消耗掉你的spark作业运行的总时间的一小部分。
map副本，传输到了各个task上之后是要占用内存的，1个map的确影响不大，1m，1000个map分布在你的集群中，一下子就消耗了1G。造成不必要的内存消耗和占用，导致你在进行rdd持久化到内存，也就就没法完全在内存中放下，就只能写入磁盘，最后导致后续的操作在磁盘io上消耗性能；你的task在创建对象的时候，也许会发现堆内存放不下所有对象，也许就就会导致频繁的垃圾回收器的回收，GC，GC的时候一定会导致工作线程停止，也就是导致spark暂停工作的时间，频繁GC的话对spark作业的速度影响很大
使用了广播变量后呢？
广播变量初始的时候，就在driver上有一份副本。
task在运行的时候，想要使用广播变量中的数据，此时首先会在自己本地的executor对应的blockmanager中，尝试获取变量副本，如果本地没有，那么就从driver远程拉取变量副本，并保存在本地的blockmanager中；此后这个executor上的task，都会直接使用本地的blockmanager上拉取变量副本。
好处：不是每个task一份变量副本，而是变成每个节点的executor才一份副本。
spark优化之使用kryo序列化
1.为什么要进行序列化
在进行stage间的task的shuffle操作时，节点与节点之间的task会互相大量通过网络拉取和传输文件，此时，这些数据既然通过网络传输，也是可能要序列化的，就会使用kryo
2.为什么要使用kryo序列化
默认情况下，spark内部都是使用java的系列化机制，ObjectOutPutStream、ObjectInPutStream，对象输入输出流机制，来进行序列化。这种默认的序列化机制的好处在于，处理起来比较方便，也不需要我们手动去做什么事情，只是，你在算子里面使用的变量，必须是实现serializable接口的，可序列化即可。但是缺点在于，默认的序列化机制的效率不高，序列化的速度比较慢，系列化以后的数据，占用的内存空间相对还是比较大。可以手动进行序列化格式的优化
spark支持使用kryo序列化机制，kryo序列化机制，比默认的java序列化机制，速度要快，序列化后的数据更小，大概是java序列化机制的1/10.所以kryo序列化优化以后，可以让网络传输的数据变少，在集群中耗费的内存资源大大减少。
3.kryo序列化作用在什么地方？
1.算子函数中使用到的外部变量 优化网络传输的性能，可以优化集群中内存的占用和消耗
2.持久化rdd时进行序列化 优化内存中的占用和消耗，持久化rdd占用的内存越少，task执行的时候，创建的对象，就不至于频繁的占满内存，频繁发生GC
3.shuffle 优化网络传输的性能
4.如何实现序列化？
sparkConf.set("spark.serializer","org.apache.spark.serializer.KryoSerializer")
首先第一步，在sparkConf中设置序列化属性，之所以没有作为默认的序列化类库的原因：因为kryo要求，如果要达到它的最佳性能的话，一定要注册你自定义的类
第二步，注册你使用到的，需要通过kryo序列化的，一些自定义类，sparkconf。registerKryoClasses()
项目中的使用：
sparkConf.set("spark.serializer","org.apache.spark.serializer.KryoSerializer").registerKryoClasses(new Class[]{CategorySortKey.class})
如：
SparkSession.builder().master("local").config("spark.serializer","org.apache.spark.serializer.KryoSerializer")
.config("spark.kryo.registrator","MyRegistor")
.appName(Constants.SPARK_APP_NAME_SESSION).getOrCreate()
public class MyRegistor implements KryoRegistrator{
public void registerClasses(Kryoryo){
kryo.register(CategorySortKey.class)
}
}
sprak优化之使用fastUtil？
1.什么是fastutil
fastutil是扩展了java标准集合框架的类库，提供了特殊类型的map，set，list，queue；
fastutil能够提供更小的内存占用，更快的存取速度，我们使用fastutil提供的集合类来替代自己平时使用的jdk原生的map，list，set，好处在于，可以减少内存的占用，并且在进行集合的遍历、根据索引获取元素的值和设置元素的值的时候，提供更快的存取速度；
fastutil也提供了64位的array，set，list，以及高性能快速的，以及实用的io类，来处理二进制和文本类型的文件；
2.spark中应用fastutil的场景
1.如果算子函数使用了外部变量，那么第一，你可以实用broadcast广播变量优化；第二，可以使用kryo序列化类库，提升序列化性能和效率；第三，如果外部变量是某种比较大的集合，那么可以考虑使用fastutil改写外部变量，首先从源头上就减少内存的占用，通过广播变量进一步减少内存占用，再通过kryo序列化类库进一步减少内存占用
2.在你的算子函数里，也就是task要执行的计算逻辑里面，如果有逻辑中出现，要创建比较大的map，list集合，可能会占用较大的内存空间，而且可能涉及到消耗性能的遍历，存取等集合操作；那么此时，可以考虑将这些集合类型使用fastutil类库重写。
3.fastutil的使用
<dependency>
<groupId>fastutil</groupId>
<artifactId>fastutil</artifactId>
<version>5.0.9</version>
</denpendency>
spark优化之调节数据本地化等待时长
1.task数据获取级别
process_local:进程本地化，代码和数据在同一个进程中，也就是在同一个executor中，计算数据的task由executor执行，数据在exector的blockManager；性能最好
node_local:节点本地化，代码和数据在同一个节点中，比如说，数据作为一个hdfsblock块，就在节点上，而task在节点上某个executor中运行，或者是，数据和task在一个节点上的不同executor中，数据需要在进程间进行传输
no_per:对于task来说，数据从哪里获取都一样，没有好坏之分
rack_local:机架本地化，数据和task在一个机架的两个节点上；数据需要通过网络在节点之间进行传输
any：数据和task可能在集群中的任何地方，而且不在一个机架中，性能最差
spark.locality.wait 默认是3s
2.原理
spark在driver上，对于application的每一个stage的task，进行分配之前，都会计算出每个task要计算的是哪个分片数据，RDD的某个partition；spark的task分配算法，优先会希望每个task正好分配到它要计算的数据所在的节点，这样的话，就不用在网络间传输数据；
但是通常来说，事与愿违，可能task没有机会分配到它的数据所在的节点，为什么呢？可能那个节点扥计算资源和计算能力都满了，所有这种时候，通常来说，spark会等待一段时间，默认情况是3s（不是绝对的，还有很多种情况，对不同的本地化级别，都会去等待），到最后实在是等待不了了，就会选择一个比较差的本地化级别，比如说，将task分配到靠它要计算的数据所在节点，比较近的一个节点，然后进行计算。
对于第二种情况，通常来说，肯定要发生数据传输，task会通过其所在节点blockmanager来获取数据，blockmanager发现自己本地没有数据，会通过一个个体Remote()方法，通过TransferService从数据所在节点的blockManager中获取数据，通过网络传输回task所在节点。
3.怎么调节
观察日志，spark作业的运行日志，建议测试的时候先用client模式，在本地就直接可以看到比较全的日志
日志里面会显示，starting task，，，，，procss local ，node local
观察大部分task的数据本地化级别
如果大多数都是process_local ，那就不用调节了。如果好多级别都是node_local,any，那么最好就去调节一下数据本地化的等待时长
调节完，反复观察，看看整个spark作业多的运行时间有没有缩短，如果本地化级别提升了，但是因为等待时长了，运行作业的时间反而增加了，那就不要调节了
怎么调节？
spark.locality.wait,默认是3s，6s，10s
默认情况下，下面3个的等待时长是以spark.localoity.wait为默认值的，都是3s
spark.locality.wait.process
spark.locality.wait.node
spark.locality.wait.rack
new SparkConf().set("spark.locality.wait","10")
spark优化之JVM调优
一、降低cache操作的内存占比
1.性能调优分为哪几块？
常规性能调优：分配资源，并行度。。。。
JVM（java虚拟机）调优：jvm相关的参数，通常情况下，如果你的硬件配置、基础的jvm配置都OK的话，JVM通常不会造成太严重的性能问题；反而更多的是，在troubleshooting中，jvm占了很重要的地位；JVM造成线上的spark作业运行报错，甚至失败，比如OOM等
shuffle调优（相当重要）：spark在执行groupByKey，reduceByKey等操作时，shuffle环节的调优，这个很重要，在spark作业的运行过程中，只要一牵扯到有shuffle的操作，基本上shuffle的性能消耗，要占到整个spark作业的50%-90%，10%来运行map等操作，90%耗费在这两个shuffle操作。groupByKey，countByKey
spark操作调优（spark算子调优，比较重要）：groupByKey，countByKey或aggregateByKey来重构实现，有些算子的性能，是比其他一些算子的性能要高的。foreachPartition替代foreach。如果一旦遇到合适的情况，效果还是不错的
2.JVM主要会存在哪些问题呢？
内存不足，我们rdd的缓存，task运行定义的算子函数，可能会创建很多对象，都可能会占用大量内存，没搞好的话，可能导致JVM出问题
3.原理
堆内存：堆是java虚拟机所管理的内存中最大的一块，被所有线程共享的一块内存区域，在虚拟机启动时创建，此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都是在这里分配内存，也是是垃圾收集器管理的主要区域，因此很多时候也被称为GC堆。
堆的大小可以通过-Xms（最小值）和-Xmx（最大值）参数设置
如果从内存回收的角度看，堆中还可以细分为：新生代和老年代
新生代：程序新创建的对象都是从新生代分配内存，新生代由Eden Space和两块相同大小的Survivor Space构成，可以通过-Xmn参数来指定新生代的大小，也可以通过-XX:SurvivorRation来调整Eden Space及SurvivorSpace的大小
老年代：用于存放经过多次新生代GC仍然存活的对象，例如缓存对象，新建的对象也有可能直接进入老年代，理想情况下，老年代都是放一些声明周期很长的对象，数量应该是很少的，比如数据库连接池。
每一次放对象的时候，都是放入Eden区域，和其中一个survivor区域；另外一个survivor是空闲的。
当eden区域和一个survivor区域放满了以后（spark运行过程中，产生的对象实在太多了），就会触发minor gc，小型垃圾回收，把不再使用的对象，从内存中情况，给后面创建的对象腾出来点地方。
清理掉了不再使用的对象之后，那么也将存活下来的对象（还要继续使用的），放入之前空闲的那一个survivor区域中，这里可能出现一个问题，默认eden，survivorvor1和survivor2的内存占比是8:1:1.问题是，如果存活下来的对象是1.5，一个survivor区域放不下，此时就可能通过JVM的担保机制（不同JVM版本可能对应的行为），将对于的对象直接放入老年代了。
如果你的内存不够大，可能导致频繁的年轻代内存满溢，频繁的进行minor gc，导致短时间内，有些存活对象，多次垃圾回收都没有回收掉，进而导致这种短声明周期（其实不一定要长期使用的）对象，年龄过大，垃圾回收次数太多还没有回收到，跑到老年代。
老年代中可能会因为你内存不足，囤积一大堆，短生命周期的，本来应该在年轻代中的，可能马上要被回收掉的对象，此时，可能导致老年代频繁满溢，频繁进行full gc（全局、全面垃圾回收）。full gc就会去回收老年代中的对象，full gc由于这个算法的设计，是针对的老年代中的对象数量很少，满溢进行full gc的频率应该很少，因此采取了不太复杂的，但是耗费性能和时间的垃圾回收算法，full gc很慢。
minor gc 、full gc 无论是块，还是慢，都导致JVM的工作线程停止工作，也就是说gc的时候，spark停止工作，等待垃圾回收结束
内存不足的时候产生的问题：
1、频繁minor gc，也会导致spark停止工作
2、老年代囤积大量活跃对象（短生命周期的对象），导致频繁full gc，full gc时间很长，短则数十秒，长则数分钟，甚至数小时，可能导致spark长时间停止工作
3、严重影响spark的性能和运行的速度
4.怎么设置
JVM调优的第一个点：降低cache操作的内存占比
spark中，堆内存又被划分成了两块，一块是专门用来给rdd的cache，persist操作进行RDD数据缓存用的，另一块就是我们刚才说的，用来给算子函数的运行使用的，存放函数中自己创建的对象。
默认情况下，给RDD cache操作的内存占比，是0.6.60%的内存都给了cache操作了，但问题是，某些情况下，cache不是那么的紧张，而task算子函数中创建的对象过多，内存又不太大，导致了频繁minor gc，进一步导致full gc，导致spark频繁的停止工作，性能影响很大
针对上述情况，yarn去运行的话，通过yarn界面，去查看spark作业的运行统计，一层一层点击进去，可能看到每个stage的运行情况，包括每个task的运行时间，gc时间等等，如果发现gc太频繁，时间太长，就可以适当调整这个比例。
降低cache操作的内存咱比，大不了用persist操作，将一部分缓存的rdd数据写入磁盘，或者序列化的方式，配合kryo序列化类，减少rdd缓存的内存占用，降低cache操作内存咱比，对应的算子函数的内存占比就提升了，有更多的内存可以使用
spark.storage.memoryFraction 0.6->0.5->0.4
二 调节executor堆外内存与连接等待时长
spark.yarn.executor.memoryOverhead = 2048
spark.core.connection.ack.timeout=300
1.调节executor堆外内存
如果你的spark作业处理的数据量特别特别大，几亿数据量，然后spark一运行，时不时的报错，shuffle file can not find，executor，task lost，out of memory（内存溢出），
可能是说executor的堆外内存不太够用，导致executor在运行的过程中，可能会内存溢出，然后导致后续的stage的task在运行的时候，可能要从一些executor中拉取 shuffle map output 文件，但是executor已经挂掉了，关联的blockManager也没有了，spark作业彻底崩溃
上述情况下，就可以考虑调节一些堆外内存
注意：一定要在spark-submit脚本中去设置
默认情况下，堆外内存上限大概是300多m，调节这个参数，到1G，或者2G，4G，通常这个参数调节上以后，就会避免掉某些jvm oom的异常问题，同时spark作业的性能得到较大的提升
2.连接等待时长
一个executor跑着跑着，突然堆内内存不足了，堆外内存也不足了，可能会oom，挂掉，blockmanager也没有了，数据也丢失掉了。
另一个executro的task虽然通过driver的MapOutputTracker获取到了自己数据的地址，但是实际上去找对方的block manager获取数据的时候，是获取不到的，此时就会在spark-submit运行作业（jar），client（standalone client，yarn client），在本机就会打印log shuffle output file not found。。。DAGSchedular，resubmit task 一直会挂掉，反复挂掉，反复报错几次，spark作业就崩溃了。
但是偶尔有一种情况，输出一串fileid，uuid not found，file lost。很有可能是那份数据的executor在jvm gc，所以拉取数据的时候建立不了连接，然后超过默认的60s以后，直接宣告失败。这个时候可以考虑调节连接的超时时长
spark优化之Shuffle调优
一、shuffle原理
1.1 什么情况下会有shuffle
在spark中，主要是以下几个算子：groupByKey，reduceByKey，countByKey，join等等
1.2 什么是shuffle
groupByKey，要把分布在集群各个节点上的数据中的同一个key，对应的values，都给集中到一块儿，集中到集群中同一个节点上，更严密一点说，就是集中到一个节点的一个executor的一个task中，然后呢，集中一个key对应的values之后，才能交给我们来进行处理<key,Iterable<value>>;
reduceByKey,算子函数区队values集合进行reduce操作，最后变成一个value
countByKey,需要在一个task中，获取到一个key对应的所有的value，然后进行计数，统计总共有多少个value；
join，RDD<key,value>,RDD<key,value>,只要是两个RDD中，key相同对应的2个value，都能到一个节点的executor的task中，给我们进行处理
以reduceByKey为例：
每一个shuffle的前半部分stage的task，每个task都会创建下一个stage的task数量相同的文件，比如下一个stage会有100个task，那么当前stage每个task都会穿件100份文件，会将同一个value对应的values，一定是写入同一个文件中的，不同节点上的task，也一定会将同一个key对应的value，写入下一个stage，同一个task对应的文件中，shuffle的后半部分stage的task，每个task都会从各个节点上的task写的属于自己的那一份文件中，拉取key，value对，然后task会有一个内存缓冲区，然后会用hashmap进行key，values的汇聚；
task会用我们自己定义的聚合函数，比如reduceByKey(_+_)，把所有values进行一对一的累加，聚合出来最终的值，就完成了shuffle
shuffle，一定是分成两个stage来完成的
reduceByKey(_+_)，在某个action触发job的时候，DAGScheduler会负责划分job为多个stage，划分的依据，就是，如果发现有会触发shuffle操作的算子，比如reduceByKey，就将这个操作的前半部分记忆之前所有的rdd和transformation操作，划分为一个stage，shuffle操作的后半部分，以及后面的，直到action为止的rdd和transformation操作划分为另一个stage。
shuffle前半部分的task在写入数据到磁盘文件之前，都会先写入一个一个的内存缓冲，内存缓冲满溢之后，再spill溢写到磁盘文件中
二、合并Map端输出文件
new.SparkConf().set("spark.shuffle.comsolidateFiles","true")
开启shuffle map端输出文件合并的机制，默认情况下，是不开启的
三、Map端内存缓冲与Reduce端内存占比
默认情况下，shuffle的map task，输出到磁盘文件的时候，统一都会先写入每个task自己关联的一个内存缓冲区你，这个缓冲区大小，默认是32kb，每一次，当内存缓冲区满溢之后，才会进行spilt操作，溢写操作，溢写到磁盘文件中去。
reduce端task，在拉取到数据之后，会用hashmap的数据格式，来对各个key对应的values进行汇聚。针对每个key对应的values，执行我们自定义的聚合函数的代码，reduce task，在进行汇聚，聚合等操作的时候，实际上，使用的就是自己对应的executor的内存，默认executor内存中划分给reduce task进行汇聚的比例是0.2.理论上，很有可能会出现，拉取过来的数据很多，，那么在内存中放不下，这个时候，默认的行为，就是将内存中放不下的数据都spill（溢写）到磁盘文件中去。
如何调优？
调节map task内存缓冲：spark.shuffle.file.buffer，默认32k
调节reduce端聚合内存占比：spark.shuffle.memoryPraction 0.2
在实际生产环境中，什么时候来调节两个参数？
进入spark ui，查看详情，如果发现shuffle磁盘的write和read很大，这个时候意味着最好调节一些shuffle的参数，进行调优，首先是考虑开启map端输出文件合并机制，调节上面那两个参数，调节的时候的原则，spark.shuffle.file.buffer 每次扩大一倍，spark.shuffle.memoryPraction每次增加0.1 ，看看效果
4.1 shuffle 原理
HashShuffleManager(spark1.2)->优化后的HashShuffleManager->SortShuffleManager（包括两种机制：1.普通运行机制 2.byPass机制）
spark1.2以后默认SortShuffleManager
1.HashShuffleManager
上游的每一个task都会成为下游的每一个task创建一份文件，这样的话会产生大量的小文件
2.优化后的HashShuffleManager（map端合并）
两个task共用一个buffer，最后小文件的个数为core_number*下游task的数量
3.SortShuffleManager
会对每个reduce task要处理的数据，进行排序（默认的）
4.Bypass
触发的条件：shuffle mao task 数量小于spark.shuffle.sort.bypassMergeThreshold参数的值（默认为200）+不是排序类的shuffle算子（比如reduceByKey）
优点：避免了sort排序，节省了性能开销，而且还能将多个reduce的文件合并成为一份文件，节省了reduce task拉取数据的时候磁盘io的开销
4.2 怎样调优？
1.如果不需要按照key排序，建议使用优化后的HashShuffleManager
2.如果需要数据按key排序，可以选择SortShuffleManager，reduce task 的数量应该超过200，这样sort、merge的机制才能生效
3.如果不需要排序，并且希望每个task输出的文件最终是会合并成一份的，调节spark.shuffle.sort.bypassMergeThreshold > 200
五、参数总结
spark.shuffle.file.buffer 32k buffer大小默认32k maptask端的shuffle 降低磁盘IO
spark.reduce.MaxSizeFlight 48M shuffle read 拉取数据量的大小
spark.shuffle.memoryFraction 0.2 shuffle聚合内存的比率
spark.shuffle.io.maxRetries 拉取数据重试次数
spark.shuffle.io.retryWait 调整到重试间隔时间60s
spark.shuffle.memory hash|sort Spark shuffle的种类
spark.shuffle.consolidateFile false 针对hashShuffle 合并机制
spark.shuffle.sort.bypassMergeThreshold 针对SortShuffle Sortshufffle bypass机制 200次
spark优化之算子调优
一、MapPartitions提升Map类操作性能
spark中最基本的原则，就是每个task处理一个rdd的partition
缺点：可能oom
怎么调优？
当数据量不是特别大的时候，都可以使用这种MapPartition系列操作，性能提升比较明显
二、filter过后使用coalesce算子减少分区
默认情况下，经过filter之后，rdd的每个partition的数据量，可能都不太一样了
问题：
1.每个partition数量变少了，但是在后面进行处理的时候，还是要跟partition数量一样数量的task，来进行处理，有点浪费task计算资源
2.每个partition的数据量不一样，会导致后面的每个task处理每个partition的时候，每个task要处理的数据量就不同，这个时候容易发生数据倾斜。。。比如第一个partition的数据量才100，第二个partition的数据量是900，那么在后面的task处理逻辑一样的情况下，不同的task处理的数据量可以差别达到9倍，导致有些task运行快，有些运行慢。
如何优化？
coalesce算子
主要就是用于在filter算子操作后，针对每个partition的数据量各不相同的情况下，来压缩partition的数量，减少partition的数量，而且让每个partition的数据量都尽量均匀紧凑，从而便于后面的task进行计算操作，在某种程度上，能够一定程度的提升性能
三、使用foreachPartition优化写数据库的性能
默认的foreach的性能缺陷在哪里？
首先，对于每条数据，都要单独去调用一次function，task 为每个数据，都要去执行一次function函数。如果100w条数据（一个partition），调用100w次，性能比较差，另外如果每个数据都去创建一个数据库连接的话，那么就得创建100w次数据库连接，而且数据库连接池的创建和销毁都非常的消耗性能，而且多次通过数据库连接，往申诉局库发送一条sql语句，如果有100w条，就要发送100w次
用了foreachpartition算子之后，好处在哪？
1.对于我们写的function函数，就调用一次，一次传入一个partition所有的数据
2.主要创建或获取一个数据库连接就可以了
3.只要向数据库发送一次sql语句和多组参数即可
缺点：可能OOM
四、使用repartition算子解决sparksql并行度低的问题
并行度设置
1.spark.default.parallelism
2.textFile(),传入第二个参数，指定partition数量（少用）
设置的并行度什么时候才会生效？
Sparksql的那个stage的并行度，没法自己指定，sparksql自己会默认根据hive表对应的hdfs文件的block，自动设置spark sql查询所在的那个stage的并行度，自己通过参数指定的并行度，只会在没有spark sql的stage中生效
解决上述spark sql无法设置并行度和task数量的办法是什么呢？
repartition算子重新进行分区
五、使用reduceByKey本地聚合
1.在本地聚合以后，在map端的数据量就变少了，减少磁盘IO，而且可以减少磁盘空间的占用
2.下一个stage，拉取数据的量也就变少了，减少网络的数据传输的性能消耗
3.在reduce端进行数据缓存的内存占用变少了
4.reduce端，要进行聚合的数据量也变少了
spark调优之troubleShooting
一、控制shuffle reduce端缓冲大小以避免OOM
map端的task是不断的输出数据的，数据量可能是很大的，但是，其实reduce端的task，并不是等到map端的task将属于自己的那份数据全部写入磁盘文件之后，再去拉取的。map端写一点数据，reduce端task就会拉取一小部分数据，立即进行后面的集合，算子的应用。
每次reduce能够拉取多少数据，由buffer来决定，因此拉取过来的数据都先放在buffer中，然后采用后面的executor分配的堆内存占比（0.2）hashmap，去进行后续的集合，函数的执行
可能出现什么问题？
默认大小是48M，大多数是，reduce端task一边拉取，一边计算，不一定一直会拉满48m的数据，可能拉个10m就计算掉了。
但有时候，map端的数据量特别大，然后写出的速度特别快，reduce端所有task，拉取的时候，全部达到自己的缓冲的最大极限值，缓冲 48m 全部填满，这个时候加上执行的聚合函数的代码，可能会创建大量的对象，也许内存一下子就撑不住了。
这个时候应该减少reduce端task缓冲的大小，多拉几次，也可以尝试去增加这个reduce端缓冲大小
二、解决JVM GC导致的shuffle拉取文件失败
比如：executor的jvm进程，可能内存不是很够用了，可能就会执行GC，导致executor内，所有的工作线程全部停止，比如blockmanager，基于netty的网络通信，下一个stage的executor，可能是还没有停止掉的。task想要去上一个stage的task所在的executor，去拉取属于自己的数据，结果对方正在GC，就导致拉取半天没有拉到
解决方法：
spark.shuffle.io.maxRetries 拉取数据重试次数
spark.shuffle.io.retryWait 调整到重试间隔时间60s