Update README.md

README.md

@@ -546,6 +546,7 @@ reduceByKey(_+_)，在某个action触发job的时候，DAGScheduler，会负责
 3.shuffle前半部分的task在写入数据到磁盘文件之前，都会先写入一个一个的内存缓冲，内存缓冲满溢之后，再spill溢写到磁盘文件中。
 ### Shuffle调优之合并map端输出文件
 **如果不合并map端输出文件会怎么样?**
+
 前置条件：每个executor有2个cpu core。4个task。task是线程执行的。所以先并行跑2个task，再跑剩下2个task。
 ![合并map端输出文件](合并map端输出文件.png)
 问题来了：默认的这种shuffle行为，对性能有什么样的恶劣影响呢？
@@ -565,11 +566,13 @@ shuffle中的写磁盘的操作，基本上就是shuffle中性能消耗最为严
 磁盘IO对性能和spark作业执行速度的影响，是极其惊人和吓人的。
 
 基本上，spark作业的性能，都消耗在shuffle中了，虽然不只是shuffle的map端输出文件这一个部分，但是这里也是非常大的一个性能消耗点。
+
 **开启map端输出文件合并**
+
 new SparkConf().set("spark.shuffle.consolidateFiles", "true")
 
 开启shuffle map端输出文件合并的机制；默认情况下，是不开启的，就是会发生如上所述的大量map端输出文件的操作，严重影响性能。
-![map端文件合并](map端文件合并.png)
+![map端文件合并](map端合并文件.png)
 开启了map端输出文件的合并机制之后：
 
 第一个stage，同时就运行cpu core个task，比如cpu core是2个，并行运行2个task；每个task都创建下一个stage的task数量个文件；
@@ -598,13 +601,91 @@ map端输出文件，在生产环境中，立减5倍！
 合并map端输出文件，对咱们的spark的性能有哪些方面的影响呢？
 
 1、map task写入磁盘文件的IO，减少：100万文件 -> 20万文件
-2、第二个stage，原本要拉取第一个stage的task数量份文件，1000个task，第二个stage的每个task，都要拉取1000份文件，走网络传输；合并以后，100个节点，每个节点2个cpu core，第二个stage的每个task，主要拉取100 * 2 = 200个文件即可；网络传输的性能消耗是不是也大大减少
 
-分享一下，实际在生产环境中，使用了spark.shuffle.consolidateFiles机制以后，实际的性能调优的效果：对于上述的这种生产环境的配置，性能的提升，还是相当的客观的。spark作业，5个小时 -> 2~3个小时。
+2、第二个stage，原本要拉取第一个stage的task数量份文件，1000个task，第二个stage的每个task，都要拉取1000份文件，走网络传输；
+
+合并以后，100个节点，每个节点2个cpu core，第二个stage的每个task，主要拉取100 * 2 = 200个文件即可；网络传输的性能消耗是不是也大大减少
+
+分享一下，实际在生产环境中，使用了spark.shuffle.consolidateFiles机制以后，实际的性能调优的效果：对于上述的这种生产环境的配置，
+
+性能的提升，还是相当的客观的。spark作业，5个小时 -> 2~3个小时。
 
-大家不要小看这个map端输出文件合并机制。实际上，在数据量比较大，你自己本身做了前面的性能调优，executor上去->cpu core上去->并行度（task数量）上去，shuffle没调优，shuffle就很糟糕了；大量的map端输出文件的产生。对性能有比较恶劣的影响。
+大家不要小看这个map端输出文件合并机制。实际上，在数据量比较大，你自己本身做了前面的性能调优，executor上去->cpu core上去->并行度（task数量）上去，
+shuffle没调优，shuffle就很糟糕了；大量的map端输出文件的产生。对性能有比较恶劣的影响。
 
 这个时候，去开启这个机制，可以很有效的提升性能。
+### Shuffle调优之调节map端内存缓冲与reduce端占比
+**未调优之前**
+
+spark.shuffle.file.buffer，默认32k
+
+spark.shuffle.memoryFraction，0.2
+
+map端内存缓冲，reduce端内存占比；很多资料、网上视频，都会说，这两个参数，是调节shuffle性能的不二选择，很有效果的样子，实际上，不是这样的。
+
+以实际的生产经验来说，这两个参数没有那么重要，往往来说，shuffle的性能不是因为这方面的原因导致的
+
+但是，有一点点效果的，broadcast，数据本地化等待时长；这两个shuffle调优的小点，其实也是需要跟其他的大量的小点配合起来使用，一点一点的提升性能，
+
+最终很多个性能调优的小点的效果，汇集在一起之后，那么就会有可以看见的还算不错的性能调优的效果
+![map端内存缓冲与reduce端](map端内存缓冲与reduce端占比.png)
+**原理描述**
+
+reduce端task，在拉取到数据之后，会用hashmap的数据格式，来对各个key对应的values进行汇聚。
+
+针对每个key对应的values，执行我们自定义的聚合函数的代码，比如_ + _（把所有values累加起来）
+
+reduce task，在进行汇聚、聚合等操作的时候，实际上，使用的就是自己对应的executor的内存，executor（jvm进程，堆），默认executor内存中划分给reduce task进行聚合的比例，是0.2。
+
+问题来了，因为比例是0.2，所以，理论上，很有可能会出现，拉取过来的数据很多，那么在内存中，放不下；这个时候，默认的行为，就是说，将在内存放不下的数据，都spill（溢写）到磁盘文件中去。
+
+原理说完之后，来看一下，默认情况下，不调优，可能会出现什么样的问题？
+
+默认，map端内存缓冲是每个task，32kb。
+
+默认，reduce端聚合内存比例，是0.2，也就是20%。
+
+如果map端的task，处理的数据量比较大，但是呢，你的内存缓冲大小是固定的。可能会出现什么样的情况？
+
+每个task就处理320kb，32kb，总共会向磁盘溢写320 / 32 = 10次。
+每个task处理32000kb，32kb，总共会向磁盘溢写32000 / 32 = 1000次。
+
+在map task处理的数据量比较大的情况下，而你的task的内存缓冲默认是比较小的，32kb。可能会造成多次的map端往磁盘文件的spill溢写操作，发生大量的磁盘IO，从而降低性能。
+
+reduce端聚合内存，占比。默认是0.2。如果数据量比较大，reduce task拉取过来的数据很多，那么就会频繁发生reduce端聚合内存不够用，频繁发生spill操作，
+
+溢写到磁盘上去。而且最要命的是，磁盘上溢写的数据量越大，后面在进行聚合操作的时候，很可能会多次读取磁盘中的数据，进行聚合。
+
+默认不调优，在数据量比较大的情况下，可能频繁地发生reduce端的磁盘文件的读写。
+
+这两个点之所以放在一起讲，是因为他们俩是有关联的。数据量变大，map端肯定会出点问题；reduce端肯定也会出点问题；出的问题是一样的，都是磁盘IO频繁，变多，影响性能。
+
+**优化思路**
+
+调节map task内存缓冲：spark.shuffle.file.buffer，默认32k（spark 1.3.x不是这个参数，后面还有一个后缀，kb；spark 1.5.x以后，
+
+变了，就是现在这个参数）调节reduce端聚合内存占比：spark.shuffle.memoryFraction，0.2
+
+在实际生产环境中，我们在什么时候来调节两个参数？
+
+看Spark UI，如果你的公司是决定采用standalone模式，那么狠简单，你的spark跑起来，会显示一个Spark UI的地址，8080的端口，进去看，依次点击进去，
+
+可以看到，你的每个stage的详情，有哪些executor，有哪些task，每个task的shuffle write和shuffle read的量，shuffle的磁盘和内存，读写的数据量；
+
+如果是用的yarn模式来提交，课程最前面，从yarn的界面进去，点击对应的application，进入Spark UI，查看详情。
+
+如果发现shuffle 磁盘的write和read，很大。这个时候，就意味着最好调节一些shuffle的参数。进行调优。首先当然是考虑开启map端输出文件合并机制。
+
+调节上面说的那两个参数。调节的时候的原则。spark.shuffle.file.buffer，每次扩大一倍，然后看看效果，64，128；spark.shuffle.memoryFraction，
+
+每次提高0.1，看看效果。
+
+不能调节的太大，太大了以后过犹不及，因为内存资源是有限的，你这里调节的太大了，其他环节的内存使用就会有问题了。
+
+调节了以后，效果？map task内存缓冲变大了，减少spill到磁盘文件的次数；reduce端聚合内存变大了，减少spill到磁盘的次数，而且减少了后面聚合
+
+读取磁盘文件的数量。
+
 ## troubleshooting
 ### troubleshooting之控制shuffle reduce端缓冲大小避免OOM
 shuffle过程中优map端的task是不断的输出数据的，数据量可能是很大的，但是，其实reduce端的task，并不是等到map端task将属于自己的那份数据全部
@@ -634,6 +715,7 @@ spark作业，首先，第一要义，就是一定要让它跑起来，然后再
 如果资源特别充分，可以尝试增加reduce端缓冲大小，这样就可以减少拉取次数，减少网络传输。
 
 配置的参数，spark.reducer.maxSizeInflight
+
 ### troubleshooting之shuffle文件拉取失败
 有时候会出现一种情况，非常普遍;shuffle file cannot find，在spark的作业中，这是非常普遍，而且有时候，他会偶尔出现，但是重现提交task后，