shuffle

Shuffle简介 Shuffle描述着数据从map task输出到reduce task输入的这段过程。shuffle是连接Map和Reduce之间的桥梁，Map的输出要用到Reduce中必须经过shuffle这个环节，shuffle的性能高低直接影响了整个程序的性能和吞吐量。因为在分布式情况下，reduce task需要跨节点去拉取其它节点上的map task结果。这一过程将会产生网络资源消耗和内存，磁盘IO的消耗。通常shuffle分为两部分：Map阶段的数据准备和Reduce阶段的数据拷贝处理。一般将在map端的Shuffle称之为Shuffle Write，在Reduce端的Shuffle称之为Shuffle Read. Hadoop MapReduce Shuffle Apache Spark 的 Shuffle 过程与 Apache Hadoop 的 Shuffle 过程有着诸多类似，一些概念可直接套用，例如，Shuffle 过程中，提供数据的一端，被称作 Map 端，Map 端每个生成数据的任务称为 Mapper，对应的，接收数据的一端，被称作 Reduce 端，Reduce 端每个拉取数据的任务称为 Reducer，Shuffle 过程本质上都是将 Map 端获得的数据使用分区器进行划分，并将数据发送给对应的 Reducer 的过程。 map端的Shuffle简述

Shuffle过程是MapReduce的核心，描述着数据从map task输出到reduce task输入的这段过程。 Hadoop的集群环境，大部分的map task和reduce task是执行在不同的节点上的，那么reduce就要取map的输出结果。那么集群中运行多个Job时，task的正常执行会对集群内部的网络资源消耗严重。虽说这种消耗是正常的，是不可避免的，但是，我们可以采取措施尽可能的减少不必要的网络资源消耗。另一方面，每个节点的内部，相比于内存，磁盘IO对Job完成时间的影响相当的大，。 所以：从以上分析，shuffle过程的基本要求： 　　1.完整地从map task端拉取数据到reduce task端 　　2.在拉取数据的过程中，尽可能地减少网络资源的消耗 　　3.尽可能地减少磁盘IO对task执行效率的影响 那么，Shuffle的设计目的就要满足以下条件： 　　1.保证拉取数据的完整性 　　2.尽可能地减少拉取数据的数据量 　　3.尽可能地使用节点的内存而不是磁盘 一、map阶段 map节点执行map task任务生成map的输出结果 shuffle的工作内容： 从运算效率的出发点，map输出结果优先存储在map节点的内存中。每个map task都有一个内存缓冲区，存储着map的输出结果，当缓冲区块满时，需要将缓冲区中的数据以一个临时文件的方式存到磁盘

1.1 Shuffle和排序 Shuffle：系统执行排序，将map输出作为输入传给reduce的过程称为shuffle。 1.1.1 Map端缓存排序输出 （1） 写入缓冲区 ：map输出结果先输出到内存缓冲区（默认100M，通过属性mapreduce.Task.io.sort.mb设置） （2） 分区排序 ：线程将内存中的数据划分成相应的分区（partion），按键进行预排序； （3） 溢出文件 ：combine函数在排序后的输出上运行，直到缓冲器超过80%（属性mapreduce.map.sort.spill.percent），就会新建一个溢出文件，一个后台线程将结果输出到磁盘，缓冲区满了，map会阻塞等待缓冲区写入磁盘。； （4） 执行 Combine 函数减小数据量： 如果溢出文件数量超出mapreduce.map.combine.minspills属性设置的阈值（默认3），可以对溢出文件再次执行combine函数，以减少写入磁盘的数据。如果溢出文件数量少于3，属于小规模数据，则调用combine函数带来的开销更大，不会执行combine。 （5） 压缩减少数据量 ：还可以对输出结果进行压缩，以写入磁盘的数据量和传给reduce的数据量。通知属性mapreduce.map.output.compress设置true来开启压缩。 （6） 合并溢出文件

Spark性能调优之Shuffle调优 • Spark底层shuffle的传输方式是使用netty传输，netty在进行网络传输的过程会申请堆外 内存（netty是零拷贝），所以使用了 堆外内存 。 • shuffle过程中常出现的问题 常见问题一：reduce oom? 问题原因： reduce task 去map端获取数据，reduce一边拉取数据一边聚合，reduce端有一块聚合内存（executor memory * 0.2）,也就是这块内存不够 解决办法： 1.增加reduce 聚合操作的内存的比例 2.增加Executor memory的大小 --executor-memory 5G 3.减少reduce task每次拉取的数据量 设置 spak.reducer.maxSizeInFlight 24m, 拉取的次数就多了，因此建立连接的次数增多，有可能会连接不上（正好赶上map task端进行GC） 常见问题二：错误描述--shuffle file cannot find or executor lost • 什 么时候需要调节Executor的堆外内存大小？ • shuffle file cannot find （DAGScheduler，resubmitting task） • executor lost • task lost • out of memory

文章目录 一、spark 分区 partition的理解 二、coalesce 与 repartition的区别（我们下面说的coalesce都默认shuffle参数为false的情况） 三、实例 四、总结 一、spark 分区 partition的理解 spark中是以vcore级别调度task 如果读取的是hdfs，那么有多少个block，就有多少个partition 举例来说： sparksql 要读表T, 如果表T有1w个小文件，那么就有1w个partition 这时候读取效率会较低。假设设置资源为 --executor-memory 2g --executor-cores 2 --num-executors 5 。 步骤是： 拿出1-10号10个小文件（也就是10个partition） 分别给5个executor读取（spark调度会以vcore为单位，实际就是5个executor，10个task读10个partition） 如果5个executor执行速度相同，再拿11-20号文件 依次给这5个executor读取 而实际执行速度不会完全相同，那就是哪个task先执行完，哪个task领取下一个partition读取执行，以此类推。这样往往读取文件的调度时间大于读取文件本身，而且会频繁打开关闭文件句柄，浪费较为宝贵的io资源，执行效率也大大降低。 二、coalesce 与

OutOfRangeError (see above for traceback): RandomShuffleQueue ‘_35_shuffle_batch_4/random_shuffle_queue’ is closed and has insufficient elements (requested 11, current size 0) [[Node: shuffle_batch_4 = QueueDequeueManyV2[component_types=[DT_FLOAT, DT_INT64], timeout_ms=-1, _device="/job:localhost/replica:0/task:0/device:CPU:0"](shuffle_batch_4/random_shuffle_queue, shuffle_batch_4/n)]] 这里有一篇关于这个问题的解释，但是我尝试了上面的方法，问题没解决。 https://blog.csdn.net/weixin_39750084/article/details/85239002 看到下面这篇，发现是自己的路径设置错误 https://github.com/tkuanlun350/Tensorflow-SegNet/issues/6 来源： CSDN 作者： weixin_44878860 链接：

数据倾斜 在执行shuffle操作过程中，map端按照key分配数据输出，reduce端同样也按照key进行拉取、聚合。通常每一个key对应的数据量不对等，经常出些某些key数据量比其他key多很多。这种现象导致的后果，轻则拖慢job执行时间（执行时间由最慢的task决定），重则直接OOM（数据量太大，处理完成前不能回收内存） 原因 我觉得是两个必要条件，缺一个都不发生数据倾斜，而我们打破其中一个或全部打破来解决数据倾斜。 每个key对应的数据量天然不均 发生shuffle操作 那么怎么定位代码中哪里出现了数据倾斜？ 凭经验猜测会发生shuffle的算子 运行慢时。若是client模式，查看本地日志，当前还在运行的Stage、Task是哪个；若是cluster模式，查看UI，主要确定Stage中Task的数据量 报OOM时查看log抛错堆栈，可以定位到某一行代码，从而知道哪一个stage，哪个一个算子。 解决办法 数据源预处理 业务中，hive文件或其他数据源文件大小不均，有大有小。小文件处理很快，而大文件处理慢。如果提前对数据源数据进行一定的清洗、过滤、去重、重分区等操作，将原来不均匀的数据重新均匀放在多个文件中。 同理，针对key分布不均的情况，可以考虑将Spark 运算中业务时效不敏感的shuffle操作提前放到ETL进行预处理（比如预聚合、逻辑压缩等

对于大数据计算框架而言，Shuffle阶段的设计优劣是决定性能好坏的关键因素之一。本文将介绍目前Spark的shuffle实现，并将之与MapReduce进行简单对比。本文的介绍顺序是：shuffle基本概念，MapReduce Shuffle发展史以及Spark Shuffle发展史。 （1） shuffle基本概念与常见实现方式 shuffle，是一个算子，表达的是多对多的依赖关系，在类MapReduce计算框架中，是连接Map阶段和Reduce阶段的纽带，即每个Reduce Task从每个Map Task产生数的据中读取一片数据，极限情况下可能触发M*R个数据拷贝通道（M是Map Task数目，R是Reduce Task数目）。通常shuffle分为两部分：Map阶段的数据准备和Reduce阶段的数据拷贝。首先，Map阶段需根据Reduce阶段的Task数量决定每个Map Task输出的数据分片数目，有多种方式存放这些数据分片： 1） 保存在内存中或者磁盘上（Spark和MapReduce都存放在磁盘上）； 2） 每个分片一个文件（现在Spark采用的方式，若干年前MapReduce采用的方式），或者所有分片放到一个数据文件中，外加一个索引文件记录每个分片在数据文件中的偏移量（现在MapReduce采用的方式）。 在Map端，不同的数据存放方式各有优缺点和适用场景。一般而言