shuffle

Shuffle 过程是 MR 的一个核心。 简答了解 Shuffle 的作用: 需求场景： 　　在集群环境下，Map task和Reduce task运行在不同的节点上，这个情况下Reduce执行时需要跨节点从其他节点上拉取Map task的输出结果。如果集群上又很多任务在运行，会在运行时消耗很严重的网络资源（这属于正常现象），这种现象无法改变，只能最大化的减少资源的消耗。在数据拉取过程中怎么改变？ 　　1.完整的从Map task 端拉取数据到Reduce端 　　2.在跨节点拉取数据时，尽可能减少对带宽的不必要消耗 　　3.减少磁盘IO对Task的影响 shuffle在Map阶段的操作： 　　整个流程主要分四部：每个map task都有一个内存的缓冲区，存储着map的输出结果。当缓存区快满的时候需要把缓存区的数据以一个临时文件的方式存储放在 磁盘 。当整个map task结束之后再对磁盘中map task产生的文件进行合并，生成最终的输出文件，等待Reduce的拉取。 map阶段只能做 加1 的相加操作 把Map输出结果写入到文件，把key value 进行分组相加 　　内存缓存区默认 100MB 。如果 map task 的输出结果大于 100M 的时候可能会撑爆内存。所以有一定情况下把临时数据 ( 内存缓存区的数据 ) 写入到磁盘。重新利用这个这块缓存区。内存写入磁盘的过程叫

　　MapReduce确保每个 reducer的输入都按键排序。系统执行排序的过程——将 map输出作为输入传给 reducer——称为 shuffle。 shuffle属于不断被优化和改进的代码库的一部分，从许多方面来看， shuffle是 MapReduce的“心脏”，是奇迹发生的地方。事实上， shuffle这个说法并不准确。因为在某些语境中，它只代表 reduce任务获取 map输出的这部分过程。在这里，我们将其理解为从 map产生输出到 reduce的消化输入的整个过程。 map 端： 　　map函数开始产生输出时，并不是简单地将它写到磁盘。这个过程更复杂，它利用缓冲的方式写到内存缓冲区，并出于效率的考虑进行预排序 ( 步骤 1 )。 map的输出结果是由 collector处理的，所以 map端的 shuffle过程包含在 collect函数对 map输出结果的处理过程中。 　　每个 map任务都有一个环形内存缓冲区，用于存储任务的输出，默认情况下，缓冲区的大小为 100MB，此值可以通过改变 io.sort.mb属性来调整。一旦缓冲内容达到阀值 (io.sort.spill.percent，默认为 0.80，或 80%)，一个后台线程便开始把内容溢写 (spill)到磁盘中。在写磁盘过程中， map输出继续被写到缓冲区，但如果在此期间缓冲区被填满，

一、shuffle定义 　　 shuffle，即为洗牌的意思，在大数据计算中，无论是mapreduce框架还是spark框架，都需要shuffle，那是因为在计算的过程中，具有某种特征的数据最终需要汇聚在一个节点上进行计算，这些数据是分部在集群中不同的节点上由各自节点进行计算。就比如以workcount为例： 　　其中数据是分别保存在节点Node1，Node2，Node3上，经过处理之后，数据最终会汇聚到结点Node a和Node b上进行处理。 　　而这个数据重新打乱然后重新汇聚到不同节点的过程就是shuffle ， 但是实际情况下，shuffle的要比这个复杂的多。 数据量会很大，比如单位为TB或PB的数据分散在几百甚至数千、数万台机器上。 为了将这些数据汇聚到正确的节点，需要将这些数据放到正确的partition，因为数据大小已经大于节点的内存，因此这个过程可能会发生多次的硬盘的续写。 为了节省带宽，这个数据可能需要压缩，如何在压缩率与压缩解压时间中间做一个较好的平衡，是需要我们考虑的。 数据需要通过网络传输，所以数据的序列化与反序列化也变得相对复杂。 　　一般情况下，每个task处理的数据是可以完全载入内存当中的(如果说不能的话，可以减小partition的大小)，所以task可以做到内存中计算，除非非常复杂的计算逻辑，否则，如果为了容错而持久化中间数据，是没有太大的收益的

MapReduce 框架的核心步骤主要分两部分：Map 和Reduce。当你向 MapReduce 框架提交一个计算作业时，它会首先把计算作业拆分成若干个Map 任务，然后分配到不同的节点上去执行，每一个Map 任务处理输入数据中的一部分，当Map 任务完成后，它会生成一些中间文件，这些中间文件将会作为Reduce 任务的输入数据。Reduce 任务的主要目标就是把前面若干个Map 的输出汇总到一起并输出。 本文的重点是剖析 MapReduce 的核心过程—— Shuffle 和 Sort 。在本文中， Shuffle 是指从Map 产生输出开始，包括系统执行排序以及传送Map 输出到Reducer 作为输入的过程。在这里我们将去探究 Shuffle 是如何工作的，因为对基础的理解有助于对 MapReduce 程序进行调优。 首先从Map 端开始分析。 当Map 开始产生输出时，它并不是简单的把数据写到磁盘，因为频繁的磁盘操作会导致性能严重下降。它的处理过程更复杂，数据首先是写到内存中的一个缓冲区，并做了一些预排序，以提升效率。 每个Map 任务都有一个用来写入输出数据的循环内存缓冲区。这个缓冲区默认大小是100MB，可以通过 io.sort.mb 属性来设置具体大小。当缓冲区中的数据量达到一个特定阀值( io.sort.mb * io.sort.spill.percent ，其中

展开 开发完成Spark作业之后，我们在运行Spark作业的时候需要为其配置一些资源参数，比如num-executors，executor-memory等，这些参数基本上都是可以在spark-submit命令中作为参数设置，但是如何设置合适的参数值是需要我们权衡考虑的（集群资源，调优经验，任务大小等）。参数设置的不合适往往会导致集群资源得不到有效的利用，设置的太大可能会导致资源不够而引发异常，太小的话会使得闲置的资源得不到有效利用，作业运行的极为缓慢。所以，如何合理有效的分配Spark作业资源是需要Spark学习者重点考虑的。下面将一些理论知识结合自己的实践进行讲解。 集群资源情况 我们在为自己的Spark作业设置资源参数的时候，需要对公司的集群资源使用情况有一个较为清晰的了解，主要了解以下几个方面： (1)集群总体情况 公司集群的整体配置信息，比如总内存，内存使用情况，节点数等，对集群的资源有一个整体的认识。 可以从Yarn页面来了解集群整体情况，如红线圈出的一些重要信息： (2)资源队列配置 一般使用资源管理器，比如Yarn，都会设置一些资源队列，比如Hadoop,Spark，default队列等。这里以讯飞公司情况为例讲解，讯飞使用Yarn资源管理器，这里采用Capacity Scheduler任务调度模式，设置了两个资源队列：default和Spark

有许多场景下，我们需要进行跨服务器的数据整合，比如两个表之间，通过Id进行join操作，你必须确保所有具有相同id的数据整合到相同的块文件中。那么我们先说一下mapreduce的shuffle过程。 Mapreduce的shuffle的计算过程是在executor中划分mapper与reducer。Spark的Shuffling中有两个重要的压缩参数。 spark.shuffle.compress true ---是否 将会将shuffle中outputs的过程进行压缩 。将 spark.io.compression.codec编码器 设置为压缩数据，默认是 true .同时，通过spark.shuffle.manager 来设置shuffle时的排序算法，有 hash,sort,tungsten-sort 。（用hash会快一点，我不需要排序啊~） Hash Shuffle 使用hash散列有很多缺点，主要是因为每个Map task都会为每个reduce生成一份文件，所以最后就会 有M * R个文件数量 。那么如果在比较多的Map和Reduce的情况下就会出问题，输出缓冲区的大小，系统中打开文件的数量，创建和删除所有这些文件的速度都会受到影响。如下图： 这里有一个优化的参数 spark.shuffle.consolidateFiles ，默认为false, 当设置成true时

为什么使用spark的原因是早期的编程模式MapReduce缺乏对数据共享的高效元语，会造成磁盘I/O 以及序列号等开销，spark提出了统一的编程抽象---弹性分布式数据集（RDD）,该模型可以令并行计算阶段间高效地进行数据共享。spark处理数据时，会将计算转化为一个有向无环图(DAG)的任务集，RDD能够有效的恢复DAG中故障和慢节点执行的任务，并且RDD提供一种基于粗粒度变换的接口，记录创建数据集的“血统”，能够实现高效的容错性。 spark的作业和任务调度系统是其核心，它能够有效的进行调度的根本原因是因为对任务划分DAG和容错。 DAG，有向无环图，Directed Acyclic Graph的缩写，常用于建模。Spark中使用DAG对RDD的关系进行建模，描述了RDD的依赖关系，这种关系也被称之为lineage，RDD的依赖关系使用Dependency维护，参考Spark RDD之Dependency，DAG在Spark中的对应的实现为DAGScheduler。 基础概念 介绍DAGScheduler中的一些概念，有助于理解后续流程。 作业（Job） 调用RDD的一个action，如count，即触发一个Job，spark中对应实现为ActiveJob，DAGScheduler中使用集合activeJobs和jobIdToActiveJob维护Job 调度阶段

前言 在大数据计算领域，Spark已经成为了越来越流行、越来越受欢迎的计算平台之一。Spark的功能涵盖了大数据领域的离线批处理、SQL类处理、流式/实时计算、机器学习、图计算等各种不同类型的计算操作，应用范围与前景非常广泛。在美团•大众点评，已经有很多同学在各种项目中尝试使用Spark。大多数同学（包括笔者在内），最初开始尝试使用Spark的原因很简单，主要就是为了让大数据计算作业的执行速度更快、性能更高。 然而，通过Spark开发出高性能的大数据计算作业，并不是那么简单的。如果没有对Spark作业进行合理的调优，Spark作业的执行速度可能会很慢，这样就完全体现不出Spark作为一种快速大数据计算引擎的优势来。因此，想要用好Spark，就必须对其进行合理的性能优化。 Spark的性能调优实际上是由很多部分组成的，不是调节几个参数就可以立竿见影提升作业性能的。我们需要根据不同的业务场景以及数据情况，对Spark作业进行综合性的分析，然后进行多个方面的调节和优化，才能获得最佳性能。 笔者根据之前的Spark作业开发经验以及实践积累，总结出了一套Spark作业的性能优化方案。整套方案主要分为开发调优、资源调优、数据倾斜调优、shuffle调优几个部分。开发调优和资源调优是所有Spark作业都需要注意和遵循的一些基本原则，是高性能Spark作业的基础；数据倾斜调优

概述 大多数Spark作业的性能主要就是消耗在了shuffle环节，因为该环节包含了大量的磁盘IO、序列化、网络数据传输等操作。因此，如果要让作业的性能更上一层楼，就有必要对shuffle过程进行调优。但是也必须提醒大家的是，影响一个Spark作业性能的因素，主要还是代码开发、资源参数以及数据倾斜，shuffle调优只能在整个Spark的性能调优中占到一小部分而已。因此大家务必把握住调优的基本原则，千万不要舍本逐末。下面我们就给大家详细讲解shuffle的原理，以及相关参数的说明，同时给出各个参数的调优建议。 shuffle的定义 Spark的运行主要分为2部分： 　　一部分是驱动程序，其核心是SparkContext； 　　另一部分是Worker节点上Task,它是运行实际任务的。程序运行的时候，Driver和Executor进程相互交互：运行什么任务，即Driver会分配Task到Executor，Driver 跟 Executor 进行网络传输; 任务数据从哪儿获取，即Task要从 Driver 抓取其他上游的 Task 的数据结果，所以有这个过程中就不断的产生网络结果。其中，下一个 Stage 向上一个 Stage 要数据这个过程，我们就称之为 Shuffle。 HashShuffleManager的运行原理 在Spark的源码中，负责shuffle过程的执行

概述 在开发完Spark作业之后，就该为作业配置合适的资源了。Spark的资源参数，基本都可以在spark-submit命令中作为参数设置。很多Spark初学者，通常不知道该设置哪些必要的参数，以及如何设置这些参数，最后就只能胡乱设置，甚至压根儿不设置。资源参数设置的不合理，可能会导致没有充分利用集群资源，作业运行会极其缓慢；或者设置的资源过大，队列没有足够的资源来提供，进而导致各种异常。总之，无论是哪种情况，都会导致Spark作业的运行效率低下，甚至根本无法运行。因此我们必须对Spark作业的资源使用原理有一个清晰的认识，并知道在Spark作业运行过程中，有哪些资源参数是可以设置的，以及如何设置合适的参数值。 Spark作业基本运行原理 详细原理见上图。我们使用spark-submit提交一个Spark作业之后，这个作业就会启动一个对应的Driver进程。根据你使用的部署模式（deploy-mode）不同，Driver进程可能在本地启动，也可能在集群中某个工作节点上启动。Driver进程本身会根据我们设置的参数，占有一定数量的内存和CPU core。而Driver进程要做的第一件事情，就是向集群管理器（可以是Spark Standalone集群，也可以是其他的资源管理集群，美团•大众点评使用的是YARN作为资源管理集群）申请运行Spark作业需要使用的资源