shuffle

map 的数量不是基于 blk 大小决定的； 基于中间抽象概念，叫切片； 一个切片对应一个 map 进程； 是一个逻辑概念； 大文件，一个切片对应一个 blk 即可，对于小文件，可以对应多个 blk ，即使去其他 datanode 获取，那么文件很小，不会影响太多时间传输； ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ shuffle 某一个具体的map task进程，输出数据是如何缓存、中间是如何排序、如何分组的，然后转发给reduce，这个过程就叫做shullfe过程。shuffle是分布到整个集群协作运行的 partitions实现分组 buffer缓存 inputSplit切片逻辑产生一个map 进程 map结果输出k-v形式 k-v放到自己机器的内存中buffer，buffer缓冲区大小由配置文件指定，默认100M， buffer会把溢出数据放到磁盘中，分组，排序，合并（合并时候同一组还需要重新排序，因为每个分组中的数据排序之间存在135，268）

随着 Spark 的逐渐成熟完善, 越来越多的可配置参数被添加到Spark中来, 在Spark的官方文档http://spark.apache.org/docs/latest/configuration.html 中提供了这些可配置参数中相当大一部分的说明. 但是文档的更新总是落后于代码的开发的, 还有一些配置参数没有来得及被添加到这个文档中, 最重要的是在这个文档中,对于许多的参数也只能简单的介绍它所代表的内容的字面含义, 如果没有一定的实践基础或者对其背后原理的理解, 往往无法真正理解该如何针对具体应用场合进行合理配置。 本文试图通过阐述这其中部分参数的工作原理和配置思路, 和大家一起探讨一下如何根据实际场合对Spark进行配置优化。需要注意的是，理论上，没有绝对正确的配置（否则也就不需要对应的配置参数了，Spark框架内部直接写死就好了），所以请结合自己的实际情况，辩证的看下面的内容。 由于本文主要针对和性能相关的一些配置参数进行阐述，所以基本不会覆盖其它和性能没有太多关系的配置参数。 由于篇幅较长，所以在这里分篇组织，如果要看最新完整的网页版内容，可以戳这里： http://spark-config.readthedocs.org/ ，主要是便于更新内容 Shuffle 相关 Shuffle操作大概是对Spark性能影响最大的步骤之一（因为可能涉及到排序，磁盘IO

什么时候需要 shuffle writer 假如我们有个 spark job 依赖关系如下 我们抽象出来其中的rdd和依赖关系: E <-------n------, C <--n---D---n-----F--s---, A <-------s------ B <--n----`-- G 对应的划分后的RDD结构为： 最终我们得到了整个执行过程： 中间就涉及到shuffle 过程，前一个stage 的 ShuffleMapTask 进行 shuffle write， 把数据存储在 blockManager 上面， 并且把数据位置元信息上报到 driver 的 mapOutTrack 组件中， 下一个 stage 根据数据位置元信息， 进行 shuffle read， 拉取上个stage 的输出数据。 这篇文章讲述的就是其中的 shuffle write 过程。 spark shuffle 演进的历史 Spark 0.8及以前 Hash Based Shuffle Spark 0.8.1 为Hash Based Shuffle引入File Consolidation机制 Spark 0.9 引入ExternalAppendOnlyMap Spark 1.1 引入Sort Based Shuffle，但默认仍为Hash Based Shuffle Spark 1.2

1、流程详解 Map 方法之后，Reduce 方法之前的数据处理过程被称为 Shuffle，具体流程为： (1) MapTask 收集 map() 方法输出的 kv 对，放到内存缓冲区中。 (2) 从内存缓冲区不断溢出本地磁盘文件，可能会溢出多个文件。 (3) 多个溢出文件会被合并成大的溢出文件。 (4) 在溢出过程及合并的过程中，都要调用 Partitioner 进行分区和针对 key 进行排序。 (5) ReduceTask 根据自己的分区号，去各个 MapTask 机器上取相应的结果分区数据。 (6) ReduceTask 会取到同一个分区的来自不同 MapTask 的结果文件，ReduceTask 会将这些文件再进行合并(归并排序)。 (7) 合并成大文件后，Shuffle 的过程也就结束了，后面进入 ReduceTask 的逻辑运算过程(从文件中取出一个一个的键值对 Group，调用用户自定义的 reduce() 方法)。 2、注意点 Shuffle 中的缓冲区大小会影响到 MapReduce 程序的执行效率，原则上说，缓冲区越大，磁盘 io 的次数越少，执行速度就越快。缓冲区的大小可以通过参数调整，参数：io.sort.mb 默认100M。 3、Shuffle 图示 来源： CSDN 作者： 火成哥哥 链接： https://blog.csdn.net

在每个maptask的结束，我们拿到的是<K,V>的队列，在Reduce中，输入的是<K,Iterable V>。在中间有一个被称为Shuffle的工作，将Maptask的数据按Key排序。其主要的工作，大体上讲1.完整地从map task端拉取数据到reduce端。2.在跨节点拉取数据时，尽可能地减少对带宽的不必要消耗。3.减少磁盘IO对task执行的影响。（主要的优化工作在于更多的使用内存而非磁盘IO） 部分转自 https://www.cnblogs.com/sunfie/p/4928662.html ； MapTask的Shuffle 从四个方面来讲Map这块的Shuffle，map结果写入磁盘 ; 缓存数据的分区(Partition)分组(Combiner)排序(Sort) ; 文件合并 (Merge); 1.map结果写入磁盘 对于并行的map工作，产生了许多结果输出，首先我们讲各个节点上得到的结果存到一个环形内存缓冲区里（填到80%就往外拿数据了，不然满了，剩下20%继续读map的数据），当缓冲区全满了，那map就阻塞吧，直到写磁盘结束了再继续。写出去的文件叫做溢出文件（Spill），这个溢写是由单独线程来完成，不影响往缓冲区写map结果的线程，溢写线程启动时不应该阻止map结果的输出。 2.缓存数据的分区(Partition)分组(Combiner)排序(Sort)

图形学渲染流程(管线)说一下 答: 传统的前向渲染管线流程是这样的 顶点和索引到顶点着色器，这里主要是对顶点进行变换，然后是光栅化，这里将剔除视锥体之外的元素，光栅化后三角形内的像素将进入到片元着色器（像素着色器），经过深度测试（模板测试）后写入到Target缓冲区内。 其实还有计算shader,用于曲面细分的三个shader,几何shader,RayTrace shader等，不展开了。 BDRF函数 答：BRDF函数是射出光线的辐照度和摄入光线辐射率的比值，在现代引擎中BRDF一般使用Cook-Torrance 的公式，定义为F菲涅尔(F0,NV) G(L,N,V) 几何函数 D(N,H,Roughness) 法线分布函数(H为L,V的半角向量) 除以4*(NL)*(NV) IBL基本原理 答： 在PBR渲染公式中,我们不仅仅算直接光源，也要考虑来自环境的间接光源，因此把来自环境光的信息储存在cubeMap中供计算，这就是IBL，基于图形的光照，在这种情况下需要对光照方程进行分割，分为环境光和镜面光两部分，为了提高速度一般都会把这些卷积的结果存储在贴图里面，对于漫反射，存不同法线下的卷积结果，对于高光需要先分拆为 预滤波环境贴图和预计算BRDF,这里有一个N=V=R的假设，基于重要性采样，可以把第二项看为参数为NWi和Roughness参数的二维函数，就可以预计算贴图

　　MapRduce保证reducer的输入是按照key进行排过序的,原因和归并排序有关,在reducer接收到不同的mapper输出的有序数据后,需要再次进行排序,然后是分组排序,如果mapper输出的是有序数据,将减少reducer阶段排序的时间消耗. 一般将排序以及 Map 的输出传输到 Reduce 的过程称为混洗（ shuffle).Shuffle是MapReduce过程的核心，了解Shuffle非常有助于理解MapReduce的工作原理。如果你不知道MapReduce里的Shuffle是什么,那么请看下面这张图 　　上图中明显分为两个大部分Map任务和Reduce任务,图中的红色虚线代表数据流的一个过程,下面分两部分进行说明: MAP部分 　　每一个mapper都有一个circular buffer( 环形缓存 ),环形缓冲区是一个先进先出的循环缓冲区,不用频繁的分配内存，而且在大多数情况下，内存的反复使用也使得我们能用更少的内存块做更多的事,默认情况下大小为100M(可以通过mapreduce.task.io.sort.mb来进行修改).Mapper的输出会首先写进这个缓存里面,当里面的内容达到一个阈值(mapreduce.map.sort.spill.percent,默认情况下为80%),一个后台线程就会开始向磁盘 spill 这些内容

sparkUi的4040界面已经有了运行监控指标，为什么我们还要自定义存入redis？ 1.结合自己的业务，可以将监控页面集成到自己的数据平台内，方便问题查找，邮件告警 2.可以在sparkUi的基础上，添加一些自己想要指标统计 一、spark的SparkListener sparkListener是一个接口，我们使用时需要自定义监控类实现sparkListener接口中的各种抽象方法，SparkListener 下各个事件对应的函数名非常直白，即如字面所表达意思。 想对哪个阶段的事件做一些自定义的动作，变继承SparkListener实现对应的函数即可，这些方法会帮助我监控spark运行时各个阶段的数据量，从而我们可以获得这些监控指标数据 abstract class SparkListener extends SparkListenerInterface {//stage完成的时调用 override def onStageCompleted(stageCompleted: SparkListenerStageCompleted): Unit = { } //stage提交时调用 override def onStageSubmitted(stageSubmitted: SparkListenerStageSubmitted): Unit = { } override def

shuffle概念 　　shuffle的本意是洗牌、混洗的意思，把一组有规则的数据尽量打乱成无规则的数据。而在MapReduce中，shuffle更像是洗牌的逆过程，指的是将map端的无规则输出按指定的规则“打乱”成具有一定规则的数据，以便reduce端接收处理。其在MapReduce中所处的工作阶段是map输出后到reduce接收前，具体可以分为map端和reduce端前后两个部分。在shuffle之前，也就是在map阶段，MapReduce会对要处理的数据进行分片（split）操作，为每一个分片分配一个MapTask任务。接下来map()函数会对每一个分片中的每一行数据进行处理得到键值对（key,value），其中key为偏移量，value为一行的内容。此时得到的键值对又叫做“中间结果”。此后便进入shuffle阶段，由此可以看出shuffle阶段的作用是处理“中间结果”。 此处应该想一下，为什么需要shuffle，它的作用是什么？ 在了解shuffle的具体流程之前，应先对以下两个概念有所了解： block块（物理划分） 　　block是HDFS中的基本存储单位，hadoop1.x默认大小为64M而hadoop2.x默认块大小为128M。文件上传到HDFS，就要划分数据成块，这里的划分属于物理的划分（实现机制也就是设置一个read方法