批处理作业的 shuffle 阶段对网络带宽消耗极大，本质上是数据在分布式节点间“搬家”产生的必然代价，想要降本增效，就得从压缩、减量和调度三个维度同时下手。
为什么说 shuffle 阶段是网络带宽的“隐形刺客”？
很多刚接触分布式计算的同学都容易陷入一个误区：以为批处理作业最耗时的是 map 阶段的计算逻辑，实际跑过几百个任务后你会发现，shuffle 阶段才是真正让集群网络“喘不过气”的环节，它不像 map 或 reduce 那样有清晰的进度条，但内部的数据传输量往往是中间结果的数倍。
shuffle 到底干了什么？map 端等半天，reduce 端疯狂拉取
把 shuffle 拟人化来看：map 任务像个勤恳的仓库分拣员，把自己处理完的中间结果按照分区号写进本地磁盘，而 reduce 任务则像个收件员，必须跑到每一台 map 任务的机器上去“取货”，取货的过程就是网络传输，而且是全量、无序、多对多的。
- map 任务完成后，reduce 任务会通过 HTTP 或 RPC 主动发起拉取请求。
- 每个 reduce 分区都可能对应全部 map 任务的输出，所以节点之间会形成全连接交叉传输。
- 数据在传输前如果没有压缩,那写多少字节，网络里就流多少字节，带宽消耗直接翻倍。
在这个环节里,网络带宽的消耗不取决于你的业务逻辑有多复杂，而取决于中间结果的总大小，据统计，在典型的数据仓库批处理场景中，shuffle 阶段消耗的时间能占到整个作业运行时间的相当一部分，而网络带宽开销也常常成为集群资源瓶颈的“第一名”。
哪些场景会让带宽消耗雪上加霜？
日常运维里,有几类情况特别容易把 shuffle 带宽“点燃”：
- 数据倾斜：某个 key 的数据量超大，导致对应的 reduce 任务需要单独拉取几乎所有 map 的输出，网络流量瞬间集中到少数节点。
- 小文件过多：map 输出分到上千个小文件，reduce 拉取时连接数暴增，网络握手开销大于实际传输开销。
- 未做预聚合：map 端直接输出原始明细，没有 Combiner，原本可以在本地合并的几百行变成几百次网络请求。
- 默认 JVM 堆内存过小：reduce 端缓冲区不够，数据频繁溢写并重复拉取，造成额外的带宽浪费。
shuffle 阶段网络带宽消耗怎么解决？三类方法亲测有效
如果正在为 shuffle 带宽告警头疼，别急着加物理网卡，行业共识认为，优先做压缩、减量、调参这三步，往往能把带宽消耗降一个量级。
第一招：从上往下压压缩与序列化
压缩是降低 shuffle 网络带宽消耗最直接的手段，map 端先把输出压缩再写磁盘，reduce 端拉取到的是压缩流，解压后再处理，虽然增加了少量 CPU 开销，但换来的带宽节省非常可观。
- Hadoop MapReduce 中，开启 map 输出压缩并指定 Snappy 算法：
mapreduce.map.output.compress=true
mapreduce.map.output.compress.codec=org.apache.hadoop.io.compress.SnappyCodec- Spark 中开启 shuffle 压缩：
spark.shuffle.compress=true
spark.io.compression.codec=snappy- 同时建议使用更高效的序列化器,Kryo，替代默认的 Java 序列化，Kryo 序列化后的字节数更小，传输更快，对 CPU 开销也友好。
第二招：从源头减Combiner 与提前过滤
压缩是“把体积变小”，而 Combiner 是“把数量变少”，Combiner 在 map 端本地先做一次合并，wordcount 中把同一单词的计数先求和，这样到 shuffle 阶段传输的数据条数就能显著下降。
| 优化方式 | 核心作用 | 适用场景 |
|---|---|---|
| Map 端 Combiner | 本地聚合，减少输出条数 | 求和、去重、取最值等可结合操作 |
| 提前过滤（Filter） | 在 map 阶段丢弃无用数据 | 数据清洗、条件筛选 |
| 列裁剪 | 只保留需要的字段 | 宽表，行式存储 |
| 输出分桶 | 按最终聚合 key 分区 | 与下游 join 对齐，减少二次传输 |
实操中,把过滤条件尽量下推，比如在 Hive SQL 里用 WHERE 子句提前把无关分区排除掉，比在 reduce 阶段再过滤高效得多，这些操作不需要额外配置，但很多人因为“懒得改业务逻辑”而略过，结果白白烧了带宽。
第三招：从网络抠并发参数与节点本地性
即使数据量和体积都没法再减,通过调整 shuffle 的并发和调度策略，也能让带宽用得更“聪明”。
- 控制 reduce 端拉取的并发数，Hadoop 中
mapreduce.reduce.shuffle.parallelcopies默认是 5，增大到 10-15 可以加速拉取，但如果你的网络已经紧张，反而应该减小这个值，避免连接风暴。 - 调整
mapreduce.job.reduce.slowstart.completedmaps，让 reduce 在 map 完成一定比例后再启动拉取，避免过早抢占带宽。 - 开启节点本地性（Node Local）优先策略，让 reduce 优先从本机磁盘读取 map 输出，只有跨节点时才走网络，Spark 中通过
spark.locality.wait
- 如果集群支持,使用 IO 绑定能力更强的网络协议，RDMA 或 InfiniBand，能明显降低传输延迟，但这种方式受硬件限制，不是通用方案。
Spark shuffle 和 MapReduce 区别：谁更费带宽？
很多团队会纠结从 MapReduce 迁移到 Spark 后，shuffle 带宽是变大还是变小，其实两者机制不同，不能简单定论，这里直接对比着看。
MapReduce 的 Sort-based shuffle：先排序再传输
MapReduce 的 shuffle 天生带有“全排序”基因，map 输出会按 key 排序并分区，reduce 拉取时还需要按 key 合并，排序本身不消耗网络，但排序产生的溢写文件如果太多，reduce 需要拉取多个小文件，然后再做归并排序，这无形中增加了网络连接数。
Spark 的 Shuffle：不同阶段不同选择
Spark 早期版本的 Hash Shuffle 会为每个 reducer 生成一个文件，文件数量等于 map 数乘 reduce 数，网络连接数爆炸，后来引入了 Sort Shuffle，每个 map 只写一个分区文件，配合索引文件，reduce 可以直接通过索引范围拉取数据，这种机制下，传输的网络包更大、更连续，带宽利用率更高。
但在数据量极大、分区数极多的场景下，Spark 的 shuffle 传输同样会压垮网络，尤其是使用默认的 sortByKey 等需要全局排序的操作。
两种引擎带宽消耗对比表
| 对比项 | MapReduce | Spark |
|---|---|---|
| 默认 shuffle 方式 | Sort-based | Sort-based（新版） |
| 中间结果写盘次数 | 至少 2 次（map 溢出+reduce 合并） | 多数情况下 1 次 |
| 网络连接模型 | 多对多拉取小文件 | 索引式范围拉取，连接数少 |
| 压缩支持 | 原生支持 | 原生支持 |
| 适合场景 | 超大作业且对稳定性要求高 | 迭代式作业、交互式查询 |
业内专家指出,在同等数据量和集群规模下，Spark 的 shuffle 网络时长通常更短，但对带宽峰值的要求更集中，如果业务中频繁出现大宽表 join 或 group by，依然需要做好压缩和减量。
一个真实场景：千台节点集群的 shuffle 带宽告警排查
某个调度平台在晚间大批量跑 T+1 报表任务时，偶尔会有任务失败，监控显示部分节点网卡流量瞬间飙升，端口重传率明显上升，排查过程大致如下：
- 现象确认：查看 Yarn 资源管理器，发现失败任务全都卡在 shuffle 阶段，且 map 完成率已到 100%。
- 日志定位：打开 NodeManager 日志，看到大量
Connection refused和Too many open files报错，原因是 reduce 端并发拉取数太大，导致节点连接超时。 - 成本分析：进一步查 map 输出大小，发现未压缩时，单任务中间数据量接近数 GB，而集群启用压缩后，同类任务传输量下降了相当比例。
最终方案分三步落地：
- 开启 map 输出压缩，代码里统一配置 Snappy。
- 修改调度参数,把
parallelcopies从默认的 5 调到 10，同时把slowstart调小，让 reduce 早启动但保持低频拉取。 - 在业务 SQL 中统一加入
distribute by分桶键，让相同 key 的数据尽可能在 map 端合并，减少 reduce 拉取量。
改动后,夜间批处理作业的失败次数归零，网络带宽峰值明显回落，整个集群的吞吐量反而提升了。
shuffle 网络带宽的常见疑问（Q&A）
shuffle 阶段网络带宽消耗过大，调大并行度有用吗？
不一定,调大 reduce 数量会减少每个 reduce 拉取的数据量，但同时会增加 map 端分区的文件数，网络连接次数反而变多，只有适当增加并行度且配合文件合并（如 Spark 的 spark.sql.shuffle.partitions 调整为分区大小的约 2 倍），才能减少单次传输字节，如果盲目调到上千，网络握手开销会大于传输开销，适得其反。
压缩对 shuffle 带宽的改善究竟有多大？
在已经用上 Snappy 或 LZ4 编码的情况下，数据库文件大小通常会缩小到原来的三分之一到四分之一，网络传输量自然同样比例缩减，但压缩率同时受数据内容影响 纯文本和数值型数据压缩收益明显，已经加密或高熵值的序列化对象压缩收益较低，所以压缩不是万能，但它是性价比最高的一步。
用固态硬盘能替代网络优化吗？
不能替代,但能间接缓解，SSD 加快的是 map 端写盘和 reduce 端读溢写文件的速度，而 shuffle 网络传输发生在跨节点的数据拉取，如果数据能通过节点本地性优化让更多拉取落盘，SSD 确实能减少网络压力，但根本的跨节点传输还是依赖网络带宽，始终需要做减量和压缩，最好的实践是 SSD 和网络调优双管齐下。