🌀 Hadoop Shuffle 与优化
🧩 1️⃣ Shuffle 过程
Shuffle 是 MapReduce 中 连接 Map 阶段与 Reduce 阶段 的核心过程，负责将 Map 端的输出结果分发到对应的 Reduce 节点。整个过程可分为以下几个阶段：
🔹 Map 端 Shuffle
-
Map 任务执行完成后输出数据到内存缓冲区（环形缓冲区）；
-
当缓冲区使用率达到阈值（默认 80%）时，会触发溢写（Spill），将缓冲区数据写入本地磁盘；
-
在溢写过程中：
-
会对数据按 key 进行 排序（Sort）；
-
若设置了 Combiner，则先局部聚合；
-
所有溢写文件在 Map 任务结束后，会进行 Merge（多路归并），生成最终输出文件；
-
最终 Map 输出的中间结果会通过 HTTP 传输给 Reduce 端。
🔹 Reduce 端 Shuffle
-
Reduce 任务启动后，首先从多个 Map 端 拉取（Copy） 属于自己的数据；
-
拉取完成后，进行 Merge + Sort；
-
进入 Reduce 函数 进行最终聚合计算；
-
输出结果写入 HDFS。
⚙️ 2️⃣ Shuffle 优化策略
🌱 （1）Map 阶段优化
|
优化项
|
说明
|
|
💾 增大环形缓冲区大小
|
默认 100MB，可调整为 200MB（mapreduce.task.io.sort.mb）。
|
|
📈 提高溢写比例阈值
|
从 0.8 调整到 0.9（mapreduce.map.sort.spill.percent）。
|
|
🔁 减少 merge 次数
|
控制溢写文件数，每次合并 20 个文件。
|
|
🔂 启用 Combiner
|
在 Map 阶段提前聚合，减少 I/O 和网络传输。
|
🌾 （2）Reduce 阶段优化
|
优化项
|
说明
|
|
⚖️ 合理设置 Map/Reduce 数量
|
数量太少会等待、太多会竞争资源。
|
|
⏱ Map 与 Reduce 共存
|
调整参数 mapreduce.job.reduce.slowstart.completedmaps，让 Reduce 在 Map 完成部分后启动。
|
|
🚫 避免不必要的 Reduce 操作
|
对于简单处理任务，可跳过 Reduce，节省网络传输。
|
|
🚀 增加并行拉取数
|
提高 Reduce 拉取 Map 数据的线程数。
|
|
💡 增大 Reduce 缓冲区
|
调整 mapreduce.reduce.shuffle.input.buffer.percent。
|
📡 （3）I/O 与压缩优化
|
优化点
|
说明
|
|
🧱 压缩传输数据
|
减少网络 I/O 时间，推荐安装 Snappy、LZO。
|
|
🗜 Map 输入端压缩
|
支持切片的格式：Bzip2、LZO（需建索引）。
|
|
⚡ Map 输出端压缩
|
注重速度：Snappy、LZO。
|
|
📦 Reduce 输出端压缩
|
长期保存用 Gzip，下一任务输入需支持切片格式。
|
🧮 （4）整体资源与参数优化
|
优化方向
|
参数
|
建议
|
|
🧠 NodeManager 内存
|
yarn.nodemanager.resource.memory-mb
|
例如 128G 机器配置为 100G。
|
|
💾 单任务内存
|
yarn.scheduler.maximum-allocation-mb
|
控制任务最大可分配内存。
|
|
🧰 Map 内存上限
|
mapreduce.map.memory.mb
|
默认 1G，可增至 4–5G。
|
|
🧰 Reduce 内存上限
|
mapreduce.reduce.memory.mb
|
默认 1G，可增至 4–5G。
|
|
☕ Map 堆内存
|
mapreduce.map.java.opts
|
防止 OutOfMemoryError。
|
|
☕ Reduce 堆内存
|
mapreduce.reduce.java.opts
|
同上。
|
|
⚙️ CPU 并行度
|
调整容器核数
|
增加 Map/Reduce 并行能力。
|
|
💽 多目录配置
|
dfs.datanode.data.dir
|
分散 I/O 压力。
|
|
🧵 NameNode 线程池
|
dfs.namenode.handler.count
|
推荐：20 * log2(Cluster Size)。
|
🧠 Yarn 工作机制
YARN（Yet Another Resource Negotiator）是 Hadoop 的 资源管理与调度框架，负责任务的资源分配与监控。
📋 主要组件：
|
组件
|
功能
|
|
🧩 ResourceManager（RM）
|
集群全局资源管理与任务调度中心。
|
|
🔄 NodeManager（NM）
|
每个节点的资源与任务监控执行器。
|
|
📦 ApplicationMaster（AM）
|
每个应用的任务协调者，负责 Map/Reduce 任务生命周期管理。
|
|
🧠 Container
|
承载任务运行的资源单位（CPU + 内存）。
|
🚀 执行流程：
-
Client 提交任务到 ResourceManager；
-
RM 分配 ApplicationMaster；
-
AM 向 RM 申请资源（Container）；
-
NodeManager 启动任务；
-
任务完成后汇报状态给 RM；
-
RM 释放资源。
🧭 Yarn 调度器
🎛️ 1️⃣ 三种调度器类型
|
调度器类型
|
特点
|
是否多队列
|
生产环境
|
|
🕐 FIFO
|
单队列、先进先出
|
❌
|
❌ 不推荐
|
|
🧮 Capacity Scheduler
|
多队列、按容量分配
|
✅
|
✅ 常用
|
|
⚖️ Fair Scheduler
|
多队列、公平共享
|
✅
|
✅ 大厂常用
|
👉 Apache 默认：Capacity Scheduler
👉 CDH 默认：Fair Scheduler
🗂️ 2️⃣ 多队列配置与优势
多队列配置方式：
-
按框架划分（Hive、Spark、Flink）
-
按业务模块划分（注册、下单、推荐等）
优势：
-
防止单个任务占满全部资源；
-
保障核心业务优先级；
-
支持资源降级调度；
-
任务隔离性更好。
⚡ Hadoop 性能测试（Benchmark）
搭建 Hadoop 集群后应执行基准测试，验证：
-
HDFS 的读写性能；
-
MapReduce 的计算性能。
测试 JAR 文件在 Hadoop 的 share 目录下，例如：
hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-tests.jar TestDFSIO
💥 Hadoop 宕机与优化
|
场景
|
原因
|
解决方案
|
|
🧨 MR 任务导致系统宕机
|
Yarn 并发任务过多，内存耗尽
|
调整 yarn.scheduler.maximum-allocation-mb 限制单任务最大内存
|
|
💾 写入过快导致 NameNode 宕机
|
Kafka→HDFS 写入压力过大
|
限制 Flume 批次大小（batchsize）或 Kafka 缓冲区大小
|
⚖️ Hadoop 数据倾斜问题与解决方案
数据倾斜 是指部分 key 的数据量过大，导致个别 Reducer 处理时间过长。
🎯 原因
-
某些 key 数据分布极不均衡；
-
Map 输出 key 数量分布不均；
-
自定义分区函数不合理。
💡 解决方案
|
方法
|
原理
|
场景
|
|
🧮 Combiner
|
在 Map 阶段局部聚合，减少 Shuffle 传输数据量
|
适用于聚合类操作（sum/count）
|
|
🔀 随机前缀法
|
在 key 前加随机前缀，使其分散到不同 Reducer；再进行二次聚合
|
大量集中 key
|
|
⚙️ 增加 Reducer 数量
|
提高并行度，减少单节点压力
|
数据量大时
|
|
🧩 自定义分区器
|
根据 key 的特征设计分区函数
|
key 分布不均时
|
|
🔁 两阶段 MR 聚合
|
第一次局部随机散列，第二次全局聚合
|
超大规模倾斜数据
|
🧮 集群资源分配问题
现象：
集群 30 台机器，但所有 Map 任务集中在同一台机器上。
原因：
YARN 默认允许单节点运行多个任务副本，未做资源均衡分配。
解决方案：
yarn.scheduler.fair.assignmultiple = false
关闭该参数可让任务在节点间更均匀分配。
