简介面向Hadoop初学者与大数据入门开发者这份操作手册完整记录了基于VM虚拟机中Ubuntu Kylin系统从零搭建Hadoop集群、并在Eclipse中完成MapReduce程序开发的全过程。内容按“集群部署、MapReduce开发、开发总结”三大任务组织前两部分逐步讲解SSH无密码登录、Java环境安装、Hadoop部署、集群网络与分布式配置、Eclipse插件配置、HDFS文件操作以及MapReduce项目创建与运行等关键环节每一步骤均配有完整命令、代码与解释并给出预期验证效果方便读者边做边核对。第三部分集中整理了No route to host、Too many fetch-failures、内存溢出、DataNode未启动等高频异常给出定位思路与排除方法能有效避免新手反复试错。资源包共1个doc文件大小约12.37MB文档目录清晰关键节点单独成节并融入了作者在实践中的个性化总结阅读与检索都很方便。目前已有1047人学习下载适合希望快速搭建可复现的Hadoop实验环境、并掌握MapReduce开发验证流程的读者作为实操参考。1. 集群还没搭好就聊个性化等于在沙滩上盖楼这份标题文档到底在解决什么“Hadoop集群搭建部署与MapReduce程序关键点个性化开发”这串词几乎每个做离线计算的团队都绕不过去。多数人把“搭建”理解成跑通一个 WordCount把“个性化开发”理解成改改输出路径真到了生产环境才发现集群网络、内存、文件分片这些基础环节处处卡脖子MR 作业一接真实数据就暴露原形。这篇标题背后真正要解决的事情有两件一是把集群从零拉到能稳定承载业务作业的状态二是把 MR 程序从“能跑”推向“按业务逻辑可定制”从输入读取、分区逻辑到输出格式都握在自己手里。我见过太多团队卡在同一个地方示例跑通了代码一换真实业务就翻车而且翻得莫名其妙日志看起来全正常就是任务卡在 Shuffle 不动。这篇文档对应的落地路径就是把“能跑 HelloWorld”推进到“能承载真实任务”适合刚接手集群但只见过安装文档的运维、写过几个 MR 作业但没深究机制的后端开发以及准备把试验代码改成生产作业的小团队。这篇不聊高可用架构先把最小可用闭环和关键机制拆透。2. 先把地基砸实Hadoop 集群从规划到跑通的最小闭环2.1 硬件与版本选型先定三个数字再动手动手装集群之前先定三个数字节点数、单机内存、副本数。这三个数字直接决定后续所有配置参数怎么填也是集群后期好不好用的分水岭。节点数上我一般建议 3 台起步一台跑 NameNode 和 ResourceManager两台跑 DataNode 和 NodeManager。学习或验证用 3 台足够如果要做 NameNode 高可用至少 4 到 5 台因为需要独立的 JournalNode 节点。单机内存方面实验环境 16GB 可以跑准生产小集群建议 32GB 起步NameNode 所在节点内存可以给到 64GB因为元数据全在内存里。副本数默认 3数据量不大时可以设 2但这个参数要结合存储成本一起算。存储容量的估算公式很简单日新增数据量 × 保留天数 × 副本数 / 压缩比。举个例子每天新增 200GB 日志保留 30 天副本 3压缩比算 0.5那就是200 × 30 × 3 / 0.5 36000GB约 36TB 裸容量。这个数字定了才知道要买多大磁盘也才知道集群是不是一开始就注定存不下。版本选型上我习惯用 Hadoop 3.x 主线配 OpenJDK 8 或 11这个组合最稳生态兼容性也最好。2.x 的老项目可以继续留着跑但新项目不建议再往 2.x 上投。选型时还要注意一点不同发行版对配置项的默认值有差异下文提到的参数值都以 Hadoop 3.x 社区版常见默认值为准。场景节点数单机内存副本数试验/学习316GB2准生产小集群5-732GB3带高可用生产7-964GB3节点规划好后磁盘目录也要提前想清楚。NameNode 元数据目录和数据目录必须分盘最好用独立的固态盘因为 NameNode 的读写延迟直接决定整个 HDFS 的操作响应速度。DataNode 数据盘可以做 raid0 或直接裸盘挂载不要做 raid5浪费容量还拖慢写入。2.2 基础环境与 SSH 免密的半小时清单三台机器装好后第一步不是装 Hadoop而是把基础环境收拾干净。按下面的命令走一遍半小时内能搞定。# 1. 三台机器统一 hosts 映射避免 IP 和主机名来回切换导致的玄学问题 cat /etc/hosts EOF 192.168.10.11 node1 192.168.10.12 node2 192.168.10.13 node3 EOF # 2. 创建专用用户拒绝用 root 跑 Hadoop useradd hdp echo hdp | passwd --stdin hdp # 3. 生成 SSH 密钥并分发至少保证 node1 能免密登录到所有节点 ssh-keygen -t rsa -P -f ~/.ssh/id_rsa ssh-copy-id hdpnode1 ssh-copy-id hdpnode2 ssh-copy-id hdpnode3 # 4. 实验环境直接关闭 firewalld生产环境只放行必要端口 systemctl disable firewalldhosts 文件是集群里最容易被忽略的配置一旦某台机器的主机名解析不一致NameNode 和 DataNode 之间通信就会出现随机性的超时日志里还看不出明确报错。SSH 免密只需要单向从 node1 能免密到所有节点即可因为 start-dfs.sh 和 start-yarn.sh 是通过 SSH 去各节点拉起进程的。端口方面8020 是 NameNode 的 RPC 端口9870 是 NameNode Web UI 端口8088 是 ResourceManager Web UI 端口生产环境把这三个以及 DataNode 的数据传输端口放行就行。基础环境还有两个必须做的时间同步和文件句柄上限。时间不同步会导致 HDFS 租约异常、作业提交时间错乱用 chronyd 或 ntpd 指向同一台时间服务器即可文件句柄上限要加到至少 65535否则高并发读写时会出现 “Too many open files” 这类报错这种问题在集群刚跑起来时不明显压力一大就爆发。2.3 集群初始化与启动验证最小命令集与第一眼确认基础环境就绪后进入 Hadoop 本身的配置环节。最核心的是四个文件core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml。第一次做集群配置越少越好只把非改不可的项写进去其他保持默认。# core-site.xml默认文件系统地址必须和 hosts 里定义的主机名完全一致 cat $HADOOP_HOME/etc/hadoop/core-site.xml EOF configuration property namefs.defaultFS/name valuehdfs://node1:8020/value /property property namehadoop.tmp.dir/name value/data01/hadoop/tmp/value /property /configuration EOF # hdfs-site.xml元数据目录、数据目录和副本数 cat $HADOOP_HOME/etc/hadoop/hdfs-site.xml EOF configuration property namedfs.namenode.name.dir/name value/data01/namenode/value /property property namedfs.datanode.data.dir/name value/data01/datanode/value /property property namedfs.replication/name value3/value /property /configuration EOFhadoop.tmp.dir这个参数很关键NameNode 和 DataNode 的很多默认路径都基于它所以一定要指向一个容量足够且独立的目录不要放在/tmp下。dfs.namenode.name.dir指定元数据持久化路径dfs.datanode.data.dir指定数据块存放路径这两个目录在格式化前可以不存在Hadoop 会自动创建但父目录的属主必须是启动用户权限不对会在启动时报一堆权限异常。yarn-site.xml 里首先要配的是资源相关参数和 ResourceManager 所在主机。mapred-site.xml 里则要指定 MR 跑在 YARN 上。这两个文件配好后进入初始化步骤# 1. 首次启动前必须格式化 NameNode重复执行会清空元数据 hdfs namenode -format # 2. 启动 HDFS 与 YARN $HADOOP_HOME/sbin/start-dfs.sh $HADOOP_HOME/sbin/start-yarn.sh # 3. 用 jps 检查进程是否都起来了 jps格式化这一步新集群只做一次。格式化会写入初始的 clusterID如果后面因为操作失误重新格式化DataNode 里保存的旧 clusterID 会和 NameNode 不一致导致 DataNode 一直注册不上这个坑放到后面避坑章节详细说。jps 检查时node1 上应该看到 NameNode、DataNode、ResourceManager、NodeManager 四个进程node2 和 node3 上至少要有 DataNode 和 NodeManager。进程起来后用官方示例做一次端到端验证是最快的确认方式。# 上传测试数据并跑通 wordcount 示例 hdfs dfs -mkdir /input hdfs dfs -put /opt/words.txt /input/ hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar wordcount /input /output hdfs dfs -cat /output/*跑通这一步意味着 HDFS 的读写、YARN 的资源调度、MR 的作业提交流程全部正常集群的最小可用闭环才算真正建立。后面的个性化开发都是在这个闭环之上做文章。3. MapReduce 的关键点不背源码也能弄懂的分区、切片与 Shuffle3.1 从 WordCount 说清 Mapper 与 Reducer 的生命周期MapReduce 编程模型看似简单但很多开发写作业时并不清楚框架到底在背后做了什么。拿最经典的 WordCount 来说Mapper 的代码逻辑其实只有十几行但每一行的执行时机和约束都值得弄明白。// 一个极简 Mapper重点看生命周期方法的回调顺序 public class WordMapper extends MapperLongWritable, Text, Text, IntWritable { private final Text word new Text(); private final IntWritable one new IntWritable(1); Override protected void setup(Context context) { // 每个 Map Task 开始时回调一次适合做连接初始化、配置读取 } Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { for (String w : value.toString().split(\\s)) { word.set(w); // 每调用一次 write数据进入环形缓冲区 context.write(word, one); } } Override protected void cleanup(Context context) { // 所有记录处理完后回调一次适合做清理工作 } }生命周期很简单一个 Map Task 启动后先回调一次 setup然后对输入分片里的每条记录调用一次 map最后回调一次 cleanup。这里有个容易踩坑的细节代码里复用了同一个 Text 对象word每次只改内部值如果把这个对象直接放进集合或作为 key 缓存后面会得到一堆相同的值因为引用没变。要保存结果必须 deep copy。Reducer 的生命周期结构类似setup 在 Reduce Task 开始时回调一次然后框架把 Shuffle 过来的数据按 key 分组每组调用一次 reducecleanup 最后执行。关键在于reduce 方法收到的 key 和迭代器 values只在本组范围内有效跨组引用同样会翻车。理解这个生命周期才能明白为什么合理复用对象能大幅降低 GC 压力也才能看懂内存参数该怎么调。3.2 Split 与 Block 的关系并行度是怎么被算出来的很多新手把 HDFS 的 Block 和 MapReduce 的 Split 混为一谈其实这是两层东西。Block 是 HDFS 层面的物理存储单位默认 128MBSplit 是 MapReduce 层面的逻辑切片单位一个 Split 对应一个 Map TaskSplit 的划分逻辑由 InputFormat 决定。默认的 FileInputFormat 切分逻辑是这样的读一个文件时按 128MB 的splitSize去切每个 Split 尽量落在同一个 Block 上。如果文件的最后一块不足一个 Block 大小也会单独成一个 Split。有一点容易被忽略FileInputFormat 有个 1.1 倍的膨胀系数也就是当剩余大小大于splitSize * 1.1时才继续切这个细节决定了某些文件最后会被合并成一个大 Split而不是切出很多碎片。文件情况Split 数量实际影响1 个 256MB 文件2 个两个 Map Task 并行处理1 个 10MB 文件1 个单个 Map Task无需担心10000 个 1MB 小文件10000 个Map Task 数量爆炸调度开销巨大从这个表格能直接看出来小文件是 MapReduce 性能的头号杀手。每个小文件都至少占一个 Split每个 Split 都要启动一个 Map Task而 Task 的启动和调度成本是固定的处理 1MB 数据可能只要几百毫秒但 JVM 启动和任务上下文的开销可能是它的好几倍。所以后续个性化开发里自定义 InputFormat 合并小文件是性价比最高的优化手段之一。还有一个关键点Split 是逻辑概念跨 Block 读取是被允许的。如果一个 Split 落在两个 Block 上Map Task 运行时会从两个 DataNode 分别拉取数据这会产生额外的网络传输。所以切片和块的边界越对齐任务执行越高效。这也是为什么调整mapreduce.input.fileinputformat.split.mapsize时要谨慎改小了并行度上来了但跨机读取也变多了未必划算。3.3 Combiner 与 Partitioner两个最容易优化漏掉的环节Shuffle 是 MapReduce 的灵魂但开发者真正能干预的只有两个点Partitioner 决定数据去哪个 ReduceCombiner 决定数据在 Map 端能不能先聚合一轮。Partitioner 默认是 HashPartitioner逻辑很简单(key.hashCode() Integer.MAX_VALUE) % numReduceTasks。这个实现有两个问题一是攻击者或巧合构造的 key 可能全部落在同一个分区造成数据倾斜二是业务上希望把同一类 key 放到同一个 Reduce 时默认实现根本不懂业务。所以自定义 Partitioner 是个性化开发里的家常便饭后文专门讲。Combiner 则是一个容易被误解的优化项。它的本质是在 Map 端做一次本地 Reduce把结果合并后再写入磁盘和网络传输从而大幅减少 Shuffle 的数据量。用法很简单在作业配置里指一个 Combiner 类// Combiner 可以复用 Reducer 类但前提是计算满足交换律和结合律 job.setCombinerClass(WordReducer.class);这里有个血泪教训求和、计数、取最大值这类操作可以用 Combiner因为合并顺序不影响结果但求平均值、求中位数这类操作绝对不能直接用 Combiner否则结果会错得离谱。比如三个 Map 分别产生了 (35)/24、(79)/28、(12)/21.5Combiner 合并后算 (481.5)/34.5而真实全局均值是 (357912)/64.5这只是巧合。换成不均匀的数据错误立刻暴露。所以 Combiner 的使用边界必须想清楚它只适合可以分段合并的运算。4. 个性化开发落地的四条路线当默认机制接不住业务时4.1 自定义 InputFormat把小文件合并成一个大 Split默认的 FileInputFormat 对每个文件单独切片这在业务里几乎必然遇到问题。日志类数据通常按小时生成文件每个文件几 MB 甚至不到 1MB一天下来几千个文件直接跑 MR 就是几千个 Map Task集群资源全浪费在任务调度上。常见做法是自定义一个 InputFormat继承 CombineFileInputFormat把小文件合并到同一个 Split 里。实现起来代码量很小// 自定义 InputFormat小文件合并成大 Split public class MergeInputFormat extends CombineFileInputFormatText, Text { public MergeInputFormat() { // 一个 Split 最多容纳 128MB避免任务数爆炸 setMaxSplitSize(128 * 1024 * 1024L); // 小于 16MB 的文件不单独开 Split向已有 Split 里合并 setMinSplitSize(16 * 1024 * 1024L); } }使用方式是在 Driver 里替换默认 InputFormat// Driver 中启用自定义 InputFormat job.setInputFormatClass(MergeInputFormat.class);两个参数说明一下setMaxSplitSize控制单个 Split 的上限设置成 128MB 与 HDFS Block 对齐能减少跨机读取setMinSplitSize是合并阈值小于这个值的文件会被合并进相邻 Split而不是自己独占一个。这里有个取舍setMinSplitSize设得越大Split 数量越少但单个 Mapper 处理的数据量越大内存压力也越大。我一般从 16MB 起步根据任务的单个 Record 大小和业务容忍度调整。还要注意一个细节CombineFileInputFormat 会让 Mapper 同时处理多个文件如果你的逻辑依赖输入文件的路径比如从文件路径解析日期需要改用CombineFileSplit来获取当前记录所属的文件名。很多开发者在这里踩坑默认写死了用FileSplit强转结果运行时全是 ClassCastException。4.2 自定义 Partitioner按业务键分桶默认 HashPartitioner 对业务分组不敏感。比如按省份统计业务上希望同一个省份的数据进同一个 Reduce但省份代码的 hashCode 取模后根本做不到这一点结果就是同一个省份的数据被拆散到多个 Reduce 里还得再做一次全局合并。自定义 Partitioner 解决的就是这个问题// 自定义分区按 key 的前两位省份代码分区 public class AreaPartitioner extends PartitionerText, Text { Override public int getPartition(Text key, Text value, int numReduceTasks) { String areaCode key.toString().substring(0, 2); // 与 Integer.MAX_VALUE 做与运算保证取模前不为负数 int partition (areaCode.hashCode() Integer.MAX_VALUE) % numReduceTasks; return partition; } }在 Driver 中启用// 设置自定义分区器并显式指定 Reduce Task 数量 job.setPartitionerClass(AreaPartitioner.class); job.setNumReduceTasks(10);这里有两个关键约束。第一numReduceTasks必须大于等于分区数否则部分 key 永远没有对应的 Reduce 接收但也不能设得过大否则大量分区为空产出大量空文件。我一般先把业务键的数量统计出来再定 Reduce Task 数让每个分区尽量均匀。第二分区逻辑一旦定了Reduce 端拿到的数据就是按分区聚合的如果需要全局有序输出还得依赖框架自带的分区内排序或者再加一步全排序。自定义 Partitioner 的另一个典型场景是解决数据倾斜。如果某些 key 是热点比如某个城市的订单量占一半取模后热点 key 还是会集中在某个分区这时候可以在 key 上加随机后缀打散然后在 Reduce 端还原或者用两阶段聚合。这套打法放在后面避坑章节详细展开。4.3 自定义 Writable 与 OutputFormat传输结构由业务定MR 框架自带的 Writable 类型能覆盖大部分场景但一旦业务对象有多个字段比如一条访问日志包含 IP、时间戳、访问路径、状态码拆成多个 Text 传输既不优雅又浪费序列化开销。这时候就该自定义 Writable 类。// 自定义 Writable封装访问日志的核心字段 public class AccessLogWritable implements Writable { private Text ip new Text(); private LongWritable ts new LongWritable(); private Text path new Text(); Override public void write(DataOutput out) throws IOException { // 写出的字段顺序必须和读取的顺序完全一致 ip.write(out); ts.write(out); path.write(out); } Override public void readFields(DataInput in) throws IOException { ip.readFields(in); ts.readFields(in); path.readFields(in); } }自定义 Writable 最大的坑就藏在write和readFields的顺序上。一旦字段顺序在两个方法里不一致序列化出来的数据反序列化时直接错位报的异常还是 EOFException定位起来很费劲。我的习惯是先声明字段然后按声明顺序依次写绝不中途调整。可以的话在类里写一个toString()方法调试时能直接打印对象内容省去很多逐个字段猜的麻烦。输出端的个性化绝大多数需求用 MultipleOutputs 就能解决不用从零实现 OutputFormat。比如按省份把结果分别写到不同目录// 在 Mapper 或 Reducer 里使用 MultipleOutputs MultipleOutputsText, NullWritable mos new MultipleOutputs(context); // 按业务维度写不同子目录key 是省份码 mos.write(key, NullWritable.get(), areaCode /part); // 必须在 cleanup 里关闭否则数据丢一半 mos.close();MultipleOutputs 是“后悔药”型组件它能让你在不破坏主输出路径的情况下把数据旁路到多个目录。我一般先评估需求能不能用 MultipleOutputs 实现不能了才考虑写完整的 OutputFormat因为后者要同时实现 RecordWriter、控制输出压缩和文件命名成本和维护量都上一个台阶。4.4 MR 参数个性化内存、并行度与重试的调整口径个性化开发不只是改代码参数配置同样要跟着业务走。下面这张表按 Hadoop 3.x 主线常见默认值整理是我调参时最常动的几个。参数名默认值调整场景mapreduce.map.memory.mb1024Map 处理大对象、加载字典时调大mapreduce.reduce.memory.mb1024Reduce 端聚合多、数据量大时调大mapreduce.job.reduces1按输出文件数和数据量决定mapreduce.task.io.sort.mb100Map 输出量极大时调大mapreduce.map.output.compressfalseShuffle 传输数据量大时开启mapreduce.reduce.shuffle.parallelcopies5节点多、网络带宽充足时调高mapreduce.map.maxattempts4集群抖动导致任务频繁失败时调大其中一个组合拳经常被忽略开启 Map 输出压缩。Shuffle 传输的数据是经过 Map 端排序后溢写到磁盘的文件开启压缩能显著减少网络传输量代价是消耗一点 CPU。对 CPU 空闲、网络带宽紧张的业务这笔买卖非常划算!-- mapred-site.xml 中开启 Map 输出压缩并使用 Snappy 编解码器 -- configuration property namemapreduce.map.output.compress/name valuetrue/value /property property namemapreduce.map.output.compress.codec/name valueorg.apache.hadoop.io.compress.SnappyCodec/value /property /configuration参数生效遵循作业级覆盖集群级的原则意味着同一个参数可以在不同作业里设置不同值。在代码里设置的效果一样// 在 Job 提交前按作业覆盖默认配置 Configuration conf new Configuration(); conf.setInt(mapreduce.job.reduces, 10); conf.setInt(mapreduce.map.memory.mb, 2048);调参时有个原则要记住先调大内存参数再看 GC 和溢出日志不要一上来就堆并行度。很多时候 Map Task 数已经够多但单个 Task 内存不足导致频繁 GC整体吞吐就是上不去。改参数前先记录当前任务的运行时间和资源指标改完做对比否则就是在拿生产环境试错。5. 集群与 MR 开发避坑翻车现场排了 6 小时的 5 个真实问题5.1 NameNode 起不来日志全是空指针现象执行 start-dfs.sh 后 jps 看不到 NameNode 进程查看日志发现一堆 NullPointerException 或 FileNotFoundException指向一个不存在的路径。原因最常见的根因是格式化集群后DataNode 里残留了上一次的 clusterID和 NameNode 的新 clusterID 对不上导致注册失败。另一种情况是dfs.namenode.name.dir指向的目录属主不是启动用户NameNode 启动时没有写权限内部组件初始化到一半就抛异常。解决先看日志定位再做对应处理。# 查看 NameNode 日志找到第一个异常 tail -200 $HADOOP_HOME/logs/hadoop-hdp-namenode-node1.log # 若是 clusterID 冲突且集群是刚建的新集群清空元数据重新格式化 rm -rf /data01/namenode/* hdfs namenode -format注意重新格式化是最后的办法只适合确认没有重要数据的新集群。生产环境遇到类似问题优先把备份的元数据目录拷回来而不是直接格式化。5.2 Map 跑完 100% 卡在 ShuffleReduce 迟迟不启动现象ResourceManager 页面上 Map 进度到 100%但 Shuffle 阶段一直显示 0%Reduce Task 处于 PENDING 状态整个作业像死了一样。原因多数情况是 Map 输出数据量超过了环形缓冲区导致频繁溢写Shuffle 拉取速度极慢。另一个常见原因是mapreduce.map.memory.mb设置太小Map 容器频繁被 NodeManager 杀掉重启看起来 Map 一直在跑但真正完成的任务数没有增长。解决先到用户日志里查容器是否因为物理内存超限被杀掉# 在 YARN 的 userlogs 下搜索 physical memory 相关报错 grep -i physical memory $HADOOP_HOME/logs/userlogs/application_*/container_*/syslog | tail -20确认是内存问题后按前文参数表调大 Map 容器内存并开启 Map 输出压缩。这两个动作组合起来Shuffle 卡死的问题通常立竿见影。调完后重新跑作业再观察 Shuffle 阶段是否开始有数据流动。5.3 小文件过多导致 Map 任务数爆炸现象提交一个处理几千个小文件的作业Map Task 数量直接破万ResourceManager 调度队列被占满其他作业全部排队。原因默认 FileInputFormat 按文件切分一个小文件就对应一个 Split 和一个 Map Task。几千个文件就是几千个 Task每个 Task 的启动开销远大于数据处理本身。解决入口处做两层处理。第一层定期把 HDFS 上的小文件合并成大文件可以用一个定时 MR 或 Spark 作业第二层在作业代码里用前面讲的 CombineFileInputFormat 兜底// 作业提交前指定自定义 InputFormat job.setInputFormatClass(MergeInputFormat.class);经验值是一个 Map Task 处理的数据量建议在 64MB 到 256MB 之间小于这个区间的文件都应该被合并。要确认效果看 ResourceManager 页面上的 Map Task 总数从几千降到几十说明合并生效了。5.4 数据倾斜时个别 Reduce 跑到天荒地老现象同样一个作业大部分 Reduce 一两分钟跑完个别 Reduce 跑半小时还没结束甚至报内存溢出。原因默认 HashPartitioner 对热点 key 无感知。比如按地区分区某个地区的订单量占 60%那这个地区的 Reduce 就要处理六成数据。它不是“处理得慢”是数据量本来就偏大。解决两步走。第一步对热点 key 加随机后缀把数据打散到多个 Reduce这个阶段只做局部聚合// Mapper 端对热点 key 加随机后缀打散到不同分区 int salt new Random().nextInt(256); Text newKey new Text(key.toString() _ salt);第二步在局部聚合结果上再做一次全局聚合的作业把随机后缀去掉按真实 key 合并。这个方案对求和、计数类任务效果明显但对必须保持全局顺序的任务不适用后者只能靠改分区策略或预排序搞定。两阶段聚合会多跑一个作业换来的却是消灭长尾任务值得。5.5 改了配置重启集群效果却纹丝不动现象修改了 yarn-site.xml 里的内存参数也重启了集群跑作业时发现资源总量还是老样子。原因三个可能。配置文件改到了错误的路径比如改了 mapred-site.xml 里实际属于 yarn 的参数修改只同步到了一台机器其他节点还是旧配置参数名写错Hadoop 解析时会忽略不确定的配置项不报错但也不生效。解决改完配置先确认配置同步再确认参数名最后看 UI 验证。# 1. 确认参数在活着的配置里 grep -n yarn.nodemanager.resource.memory-mb $HADOOP_HOME/etc/hadoop/yarn-site.xml # 2. 同步到所有节点 for host in node1 node2 node3; do scp $HADOOP_HOME/etc/hadoop/yarn-site.xml $host:$HADOOP_HOME/etc/hadoop/yarn-site.xml done # 3. 重启后再到 UI 上看 Cluster Metrics 的 Memory TotalResourceManager 页面上有个 Cluster Metrics 栏能看到集群总内存和活跃节点数。如果总数没变说明参数没生效变了才是真的改好了。这套验证逻辑能省下大量“改了没效果”的排查时间。6. 最后一步用三个验证手段确认集群和 MR 程序真的“稳”6.1 用 ResourceManager 页面反向验证配置配置改完有没有生效与其猜不如看页面。ResourceManager 的 Web UI 里Cluster Metrics 会显示集群总内存、总核数、活跃节点数和 Container 运行情况。如果同步了 yarn-site.xml 里的内存参数Memory Total 的数字会立刻变化。另一个值得盯的是应用的 Container 失败次数失败数持续增长说明资源不足或程序有 Bug这时候再去翻日志方向就准了。6.2 给 MR 程序加自定义计数器作业里最怕的是黑匣子式运行跑完了只知道成功失败不知道处理了多少数据、丢弃了多少脏数据。MR 框架自带计数器机制可以在代码里自定义统计项把业务指标暴露到作业页面// 在 Mapper 或 Reducer 里统计热点 key 出现次数 context.getCounter(UserStats, huge_key_count).increment(1L);作业跑完后在 ResourceManager 页面的 Job Counter 区域就能看到这个统计值。我习惯在代码里埋这几个计数器输入记录数、过滤掉的脏数据数、每个 Reduce 处理的 key 数。尤其最后一个如果某个 Reduce 的计数明显高于其他数据倾斜一眼就能看出来。6.3 用日志时间线确认 Shuffle 瓶颈作业运行完去 userlogs 目录看 Task 日志的时间戳。Map 阶段里 setup 到 map 的时间差是配置和初始化耗时map 到 cleanup 是数据处理耗时cleanup 到任务结束是溢写和分区耗时。Reduce 的日志里从 start 到第一次 shuffle 完成的时间能直接反映 Map 输出传输效率。这一套时间线看下来瓶颈在计算还是在 Shuffle 就清清楚楚了。# 查看指定 Task 的运行日志关注各阶段时间戳 tail -200 $HADOOP_HOME/logs/userlogs/application_*/container_*/syslog我自己做集群和 MR 作业习惯是每改一个参数就记下改前和改后的任务耗时、资源指标积上几次就能看出规律而不是凭感觉调参。集群和程序真正的稳定性来自可观测、可对比、可重复验证希望这套验证思路也能帮到你。本文还有配套的精品资源点击获取 Hadoop集群搭建与MapReduce个性化开发：关键机制与避坑指南
简介面向Hadoop初学者与大数据入门开发者这份操作手册完整记录了基于VM虚拟机中Ubuntu Kylin系统从零搭建Hadoop集群、并在Eclipse中完成MapReduce程序开发的全过程。内容按“集群部署、MapReduce开发、开发总结”三大任务组织前两部分逐步讲解SSH无密码登录、Java环境安装、Hadoop部署、集群网络与分布式配置、Eclipse插件配置、HDFS文件操作以及MapReduce项目创建与运行等关键环节每一步骤均配有完整命令、代码与解释并给出预期验证效果方便读者边做边核对。第三部分集中整理了No route to host、Too many fetch-failures、内存溢出、DataNode未启动等高频异常给出定位思路与排除方法能有效避免新手反复试错。资源包共1个doc文件大小约12.37MB文档目录清晰关键节点单独成节并融入了作者在实践中的个性化总结阅读与检索都很方便。目前已有1047人学习下载适合希望快速搭建可复现的Hadoop实验环境、并掌握MapReduce开发验证流程的读者作为实操参考。1. 集群还没搭好就聊个性化等于在沙滩上盖楼这份标题文档到底在解决什么“Hadoop集群搭建部署与MapReduce程序关键点个性化开发”这串词几乎每个做离线计算的团队都绕不过去。多数人把“搭建”理解成跑通一个 WordCount把“个性化开发”理解成改改输出路径真到了生产环境才发现集群网络、内存、文件分片这些基础环节处处卡脖子MR 作业一接真实数据就暴露原形。这篇标题背后真正要解决的事情有两件一是把集群从零拉到能稳定承载业务作业的状态二是把 MR 程序从“能跑”推向“按业务逻辑可定制”从输入读取、分区逻辑到输出格式都握在自己手里。我见过太多团队卡在同一个地方示例跑通了代码一换真实业务就翻车而且翻得莫名其妙日志看起来全正常就是任务卡在 Shuffle 不动。这篇文档对应的落地路径就是把“能跑 HelloWorld”推进到“能承载真实任务”适合刚接手集群但只见过安装文档的运维、写过几个 MR 作业但没深究机制的后端开发以及准备把试验代码改成生产作业的小团队。这篇不聊高可用架构先把最小可用闭环和关键机制拆透。2. 先把地基砸实Hadoop 集群从规划到跑通的最小闭环2.1 硬件与版本选型先定三个数字再动手动手装集群之前先定三个数字节点数、单机内存、副本数。这三个数字直接决定后续所有配置参数怎么填也是集群后期好不好用的分水岭。节点数上我一般建议 3 台起步一台跑 NameNode 和 ResourceManager两台跑 DataNode 和 NodeManager。学习或验证用 3 台足够如果要做 NameNode 高可用至少 4 到 5 台因为需要独立的 JournalNode 节点。单机内存方面实验环境 16GB 可以跑准生产小集群建议 32GB 起步NameNode 所在节点内存可以给到 64GB因为元数据全在内存里。副本数默认 3数据量不大时可以设 2但这个参数要结合存储成本一起算。存储容量的估算公式很简单日新增数据量 × 保留天数 × 副本数 / 压缩比。举个例子每天新增 200GB 日志保留 30 天副本 3压缩比算 0.5那就是200 × 30 × 3 / 0.5 36000GB约 36TB 裸容量。这个数字定了才知道要买多大磁盘也才知道集群是不是一开始就注定存不下。版本选型上我习惯用 Hadoop 3.x 主线配 OpenJDK 8 或 11这个组合最稳生态兼容性也最好。2.x 的老项目可以继续留着跑但新项目不建议再往 2.x 上投。选型时还要注意一点不同发行版对配置项的默认值有差异下文提到的参数值都以 Hadoop 3.x 社区版常见默认值为准。场景节点数单机内存副本数试验/学习316GB2准生产小集群5-732GB3带高可用生产7-964GB3节点规划好后磁盘目录也要提前想清楚。NameNode 元数据目录和数据目录必须分盘最好用独立的固态盘因为 NameNode 的读写延迟直接决定整个 HDFS 的操作响应速度。DataNode 数据盘可以做 raid0 或直接裸盘挂载不要做 raid5浪费容量还拖慢写入。2.2 基础环境与 SSH 免密的半小时清单三台机器装好后第一步不是装 Hadoop而是把基础环境收拾干净。按下面的命令走一遍半小时内能搞定。# 1. 三台机器统一 hosts 映射避免 IP 和主机名来回切换导致的玄学问题 cat /etc/hosts EOF 192.168.10.11 node1 192.168.10.12 node2 192.168.10.13 node3 EOF # 2. 创建专用用户拒绝用 root 跑 Hadoop useradd hdp echo hdp | passwd --stdin hdp # 3. 生成 SSH 密钥并分发至少保证 node1 能免密登录到所有节点 ssh-keygen -t rsa -P -f ~/.ssh/id_rsa ssh-copy-id hdpnode1 ssh-copy-id hdpnode2 ssh-copy-id hdpnode3 # 4. 实验环境直接关闭 firewalld生产环境只放行必要端口 systemctl disable firewalldhosts 文件是集群里最容易被忽略的配置一旦某台机器的主机名解析不一致NameNode 和 DataNode 之间通信就会出现随机性的超时日志里还看不出明确报错。SSH 免密只需要单向从 node1 能免密到所有节点即可因为 start-dfs.sh 和 start-yarn.sh 是通过 SSH 去各节点拉起进程的。端口方面8020 是 NameNode 的 RPC 端口9870 是 NameNode Web UI 端口8088 是 ResourceManager Web UI 端口生产环境把这三个以及 DataNode 的数据传输端口放行就行。基础环境还有两个必须做的时间同步和文件句柄上限。时间不同步会导致 HDFS 租约异常、作业提交时间错乱用 chronyd 或 ntpd 指向同一台时间服务器即可文件句柄上限要加到至少 65535否则高并发读写时会出现 “Too many open files” 这类报错这种问题在集群刚跑起来时不明显压力一大就爆发。2.3 集群初始化与启动验证最小命令集与第一眼确认基础环境就绪后进入 Hadoop 本身的配置环节。最核心的是四个文件core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml。第一次做集群配置越少越好只把非改不可的项写进去其他保持默认。# core-site.xml默认文件系统地址必须和 hosts 里定义的主机名完全一致 cat $HADOOP_HOME/etc/hadoop/core-site.xml EOF configuration property namefs.defaultFS/name valuehdfs://node1:8020/value /property property namehadoop.tmp.dir/name value/data01/hadoop/tmp/value /property /configuration EOF # hdfs-site.xml元数据目录、数据目录和副本数 cat $HADOOP_HOME/etc/hadoop/hdfs-site.xml EOF configuration property namedfs.namenode.name.dir/name value/data01/namenode/value /property property namedfs.datanode.data.dir/name value/data01/datanode/value /property property namedfs.replication/name value3/value /property /configuration EOFhadoop.tmp.dir这个参数很关键NameNode 和 DataNode 的很多默认路径都基于它所以一定要指向一个容量足够且独立的目录不要放在/tmp下。dfs.namenode.name.dir指定元数据持久化路径dfs.datanode.data.dir指定数据块存放路径这两个目录在格式化前可以不存在Hadoop 会自动创建但父目录的属主必须是启动用户权限不对会在启动时报一堆权限异常。yarn-site.xml 里首先要配的是资源相关参数和 ResourceManager 所在主机。mapred-site.xml 里则要指定 MR 跑在 YARN 上。这两个文件配好后进入初始化步骤# 1. 首次启动前必须格式化 NameNode重复执行会清空元数据 hdfs namenode -format # 2. 启动 HDFS 与 YARN $HADOOP_HOME/sbin/start-dfs.sh $HADOOP_HOME/sbin/start-yarn.sh # 3. 用 jps 检查进程是否都起来了 jps格式化这一步新集群只做一次。格式化会写入初始的 clusterID如果后面因为操作失误重新格式化DataNode 里保存的旧 clusterID 会和 NameNode 不一致导致 DataNode 一直注册不上这个坑放到后面避坑章节详细说。jps 检查时node1 上应该看到 NameNode、DataNode、ResourceManager、NodeManager 四个进程node2 和 node3 上至少要有 DataNode 和 NodeManager。进程起来后用官方示例做一次端到端验证是最快的确认方式。# 上传测试数据并跑通 wordcount 示例 hdfs dfs -mkdir /input hdfs dfs -put /opt/words.txt /input/ hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar wordcount /input /output hdfs dfs -cat /output/*跑通这一步意味着 HDFS 的读写、YARN 的资源调度、MR 的作业提交流程全部正常集群的最小可用闭环才算真正建立。后面的个性化开发都是在这个闭环之上做文章。3. MapReduce 的关键点不背源码也能弄懂的分区、切片与 Shuffle3.1 从 WordCount 说清 Mapper 与 Reducer 的生命周期MapReduce 编程模型看似简单但很多开发写作业时并不清楚框架到底在背后做了什么。拿最经典的 WordCount 来说Mapper 的代码逻辑其实只有十几行但每一行的执行时机和约束都值得弄明白。// 一个极简 Mapper重点看生命周期方法的回调顺序 public class WordMapper extends MapperLongWritable, Text, Text, IntWritable { private final Text word new Text(); private final IntWritable one new IntWritable(1); Override protected void setup(Context context) { // 每个 Map Task 开始时回调一次适合做连接初始化、配置读取 } Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { for (String w : value.toString().split(\\s)) { word.set(w); // 每调用一次 write数据进入环形缓冲区 context.write(word, one); } } Override protected void cleanup(Context context) { // 所有记录处理完后回调一次适合做清理工作 } }生命周期很简单一个 Map Task 启动后先回调一次 setup然后对输入分片里的每条记录调用一次 map最后回调一次 cleanup。这里有个容易踩坑的细节代码里复用了同一个 Text 对象word每次只改内部值如果把这个对象直接放进集合或作为 key 缓存后面会得到一堆相同的值因为引用没变。要保存结果必须 deep copy。Reducer 的生命周期结构类似setup 在 Reduce Task 开始时回调一次然后框架把 Shuffle 过来的数据按 key 分组每组调用一次 reducecleanup 最后执行。关键在于reduce 方法收到的 key 和迭代器 values只在本组范围内有效跨组引用同样会翻车。理解这个生命周期才能明白为什么合理复用对象能大幅降低 GC 压力也才能看懂内存参数该怎么调。3.2 Split 与 Block 的关系并行度是怎么被算出来的很多新手把 HDFS 的 Block 和 MapReduce 的 Split 混为一谈其实这是两层东西。Block 是 HDFS 层面的物理存储单位默认 128MBSplit 是 MapReduce 层面的逻辑切片单位一个 Split 对应一个 Map TaskSplit 的划分逻辑由 InputFormat 决定。默认的 FileInputFormat 切分逻辑是这样的读一个文件时按 128MB 的splitSize去切每个 Split 尽量落在同一个 Block 上。如果文件的最后一块不足一个 Block 大小也会单独成一个 Split。有一点容易被忽略FileInputFormat 有个 1.1 倍的膨胀系数也就是当剩余大小大于splitSize * 1.1时才继续切这个细节决定了某些文件最后会被合并成一个大 Split而不是切出很多碎片。文件情况Split 数量实际影响1 个 256MB 文件2 个两个 Map Task 并行处理1 个 10MB 文件1 个单个 Map Task无需担心10000 个 1MB 小文件10000 个Map Task 数量爆炸调度开销巨大从这个表格能直接看出来小文件是 MapReduce 性能的头号杀手。每个小文件都至少占一个 Split每个 Split 都要启动一个 Map Task而 Task 的启动和调度成本是固定的处理 1MB 数据可能只要几百毫秒但 JVM 启动和任务上下文的开销可能是它的好几倍。所以后续个性化开发里自定义 InputFormat 合并小文件是性价比最高的优化手段之一。还有一个关键点Split 是逻辑概念跨 Block 读取是被允许的。如果一个 Split 落在两个 Block 上Map Task 运行时会从两个 DataNode 分别拉取数据这会产生额外的网络传输。所以切片和块的边界越对齐任务执行越高效。这也是为什么调整mapreduce.input.fileinputformat.split.mapsize时要谨慎改小了并行度上来了但跨机读取也变多了未必划算。3.3 Combiner 与 Partitioner两个最容易优化漏掉的环节Shuffle 是 MapReduce 的灵魂但开发者真正能干预的只有两个点Partitioner 决定数据去哪个 ReduceCombiner 决定数据在 Map 端能不能先聚合一轮。Partitioner 默认是 HashPartitioner逻辑很简单(key.hashCode() Integer.MAX_VALUE) % numReduceTasks。这个实现有两个问题一是攻击者或巧合构造的 key 可能全部落在同一个分区造成数据倾斜二是业务上希望把同一类 key 放到同一个 Reduce 时默认实现根本不懂业务。所以自定义 Partitioner 是个性化开发里的家常便饭后文专门讲。Combiner 则是一个容易被误解的优化项。它的本质是在 Map 端做一次本地 Reduce把结果合并后再写入磁盘和网络传输从而大幅减少 Shuffle 的数据量。用法很简单在作业配置里指一个 Combiner 类// Combiner 可以复用 Reducer 类但前提是计算满足交换律和结合律 job.setCombinerClass(WordReducer.class);这里有个血泪教训求和、计数、取最大值这类操作可以用 Combiner因为合并顺序不影响结果但求平均值、求中位数这类操作绝对不能直接用 Combiner否则结果会错得离谱。比如三个 Map 分别产生了 (35)/24、(79)/28、(12)/21.5Combiner 合并后算 (481.5)/34.5而真实全局均值是 (357912)/64.5这只是巧合。换成不均匀的数据错误立刻暴露。所以 Combiner 的使用边界必须想清楚它只适合可以分段合并的运算。4. 个性化开发落地的四条路线当默认机制接不住业务时4.1 自定义 InputFormat把小文件合并成一个大 Split默认的 FileInputFormat 对每个文件单独切片这在业务里几乎必然遇到问题。日志类数据通常按小时生成文件每个文件几 MB 甚至不到 1MB一天下来几千个文件直接跑 MR 就是几千个 Map Task集群资源全浪费在任务调度上。常见做法是自定义一个 InputFormat继承 CombineFileInputFormat把小文件合并到同一个 Split 里。实现起来代码量很小// 自定义 InputFormat小文件合并成大 Split public class MergeInputFormat extends CombineFileInputFormatText, Text { public MergeInputFormat() { // 一个 Split 最多容纳 128MB避免任务数爆炸 setMaxSplitSize(128 * 1024 * 1024L); // 小于 16MB 的文件不单独开 Split向已有 Split 里合并 setMinSplitSize(16 * 1024 * 1024L); } }使用方式是在 Driver 里替换默认 InputFormat// Driver 中启用自定义 InputFormat job.setInputFormatClass(MergeInputFormat.class);两个参数说明一下setMaxSplitSize控制单个 Split 的上限设置成 128MB 与 HDFS Block 对齐能减少跨机读取setMinSplitSize是合并阈值小于这个值的文件会被合并进相邻 Split而不是自己独占一个。这里有个取舍setMinSplitSize设得越大Split 数量越少但单个 Mapper 处理的数据量越大内存压力也越大。我一般从 16MB 起步根据任务的单个 Record 大小和业务容忍度调整。还要注意一个细节CombineFileInputFormat 会让 Mapper 同时处理多个文件如果你的逻辑依赖输入文件的路径比如从文件路径解析日期需要改用CombineFileSplit来获取当前记录所属的文件名。很多开发者在这里踩坑默认写死了用FileSplit强转结果运行时全是 ClassCastException。4.2 自定义 Partitioner按业务键分桶默认 HashPartitioner 对业务分组不敏感。比如按省份统计业务上希望同一个省份的数据进同一个 Reduce但省份代码的 hashCode 取模后根本做不到这一点结果就是同一个省份的数据被拆散到多个 Reduce 里还得再做一次全局合并。自定义 Partitioner 解决的就是这个问题// 自定义分区按 key 的前两位省份代码分区 public class AreaPartitioner extends PartitionerText, Text { Override public int getPartition(Text key, Text value, int numReduceTasks) { String areaCode key.toString().substring(0, 2); // 与 Integer.MAX_VALUE 做与运算保证取模前不为负数 int partition (areaCode.hashCode() Integer.MAX_VALUE) % numReduceTasks; return partition; } }在 Driver 中启用// 设置自定义分区器并显式指定 Reduce Task 数量 job.setPartitionerClass(AreaPartitioner.class); job.setNumReduceTasks(10);这里有两个关键约束。第一numReduceTasks必须大于等于分区数否则部分 key 永远没有对应的 Reduce 接收但也不能设得过大否则大量分区为空产出大量空文件。我一般先把业务键的数量统计出来再定 Reduce Task 数让每个分区尽量均匀。第二分区逻辑一旦定了Reduce 端拿到的数据就是按分区聚合的如果需要全局有序输出还得依赖框架自带的分区内排序或者再加一步全排序。自定义 Partitioner 的另一个典型场景是解决数据倾斜。如果某些 key 是热点比如某个城市的订单量占一半取模后热点 key 还是会集中在某个分区这时候可以在 key 上加随机后缀打散然后在 Reduce 端还原或者用两阶段聚合。这套打法放在后面避坑章节详细展开。4.3 自定义 Writable 与 OutputFormat传输结构由业务定MR 框架自带的 Writable 类型能覆盖大部分场景但一旦业务对象有多个字段比如一条访问日志包含 IP、时间戳、访问路径、状态码拆成多个 Text 传输既不优雅又浪费序列化开销。这时候就该自定义 Writable 类。// 自定义 Writable封装访问日志的核心字段 public class AccessLogWritable implements Writable { private Text ip new Text(); private LongWritable ts new LongWritable(); private Text path new Text(); Override public void write(DataOutput out) throws IOException { // 写出的字段顺序必须和读取的顺序完全一致 ip.write(out); ts.write(out); path.write(out); } Override public void readFields(DataInput in) throws IOException { ip.readFields(in); ts.readFields(in); path.readFields(in); } }自定义 Writable 最大的坑就藏在write和readFields的顺序上。一旦字段顺序在两个方法里不一致序列化出来的数据反序列化时直接错位报的异常还是 EOFException定位起来很费劲。我的习惯是先声明字段然后按声明顺序依次写绝不中途调整。可以的话在类里写一个toString()方法调试时能直接打印对象内容省去很多逐个字段猜的麻烦。输出端的个性化绝大多数需求用 MultipleOutputs 就能解决不用从零实现 OutputFormat。比如按省份把结果分别写到不同目录// 在 Mapper 或 Reducer 里使用 MultipleOutputs MultipleOutputsText, NullWritable mos new MultipleOutputs(context); // 按业务维度写不同子目录key 是省份码 mos.write(key, NullWritable.get(), areaCode /part); // 必须在 cleanup 里关闭否则数据丢一半 mos.close();MultipleOutputs 是“后悔药”型组件它能让你在不破坏主输出路径的情况下把数据旁路到多个目录。我一般先评估需求能不能用 MultipleOutputs 实现不能了才考虑写完整的 OutputFormat因为后者要同时实现 RecordWriter、控制输出压缩和文件命名成本和维护量都上一个台阶。4.4 MR 参数个性化内存、并行度与重试的调整口径个性化开发不只是改代码参数配置同样要跟着业务走。下面这张表按 Hadoop 3.x 主线常见默认值整理是我调参时最常动的几个。参数名默认值调整场景mapreduce.map.memory.mb1024Map 处理大对象、加载字典时调大mapreduce.reduce.memory.mb1024Reduce 端聚合多、数据量大时调大mapreduce.job.reduces1按输出文件数和数据量决定mapreduce.task.io.sort.mb100Map 输出量极大时调大mapreduce.map.output.compressfalseShuffle 传输数据量大时开启mapreduce.reduce.shuffle.parallelcopies5节点多、网络带宽充足时调高mapreduce.map.maxattempts4集群抖动导致任务频繁失败时调大其中一个组合拳经常被忽略开启 Map 输出压缩。Shuffle 传输的数据是经过 Map 端排序后溢写到磁盘的文件开启压缩能显著减少网络传输量代价是消耗一点 CPU。对 CPU 空闲、网络带宽紧张的业务这笔买卖非常划算!-- mapred-site.xml 中开启 Map 输出压缩并使用 Snappy 编解码器 -- configuration property namemapreduce.map.output.compress/name valuetrue/value /property property namemapreduce.map.output.compress.codec/name valueorg.apache.hadoop.io.compress.SnappyCodec/value /property /configuration参数生效遵循作业级覆盖集群级的原则意味着同一个参数可以在不同作业里设置不同值。在代码里设置的效果一样// 在 Job 提交前按作业覆盖默认配置 Configuration conf new Configuration(); conf.setInt(mapreduce.job.reduces, 10); conf.setInt(mapreduce.map.memory.mb, 2048);调参时有个原则要记住先调大内存参数再看 GC 和溢出日志不要一上来就堆并行度。很多时候 Map Task 数已经够多但单个 Task 内存不足导致频繁 GC整体吞吐就是上不去。改参数前先记录当前任务的运行时间和资源指标改完做对比否则就是在拿生产环境试错。5. 集群与 MR 开发避坑翻车现场排了 6 小时的 5 个真实问题5.1 NameNode 起不来日志全是空指针现象执行 start-dfs.sh 后 jps 看不到 NameNode 进程查看日志发现一堆 NullPointerException 或 FileNotFoundException指向一个不存在的路径。原因最常见的根因是格式化集群后DataNode 里残留了上一次的 clusterID和 NameNode 的新 clusterID 对不上导致注册失败。另一种情况是dfs.namenode.name.dir指向的目录属主不是启动用户NameNode 启动时没有写权限内部组件初始化到一半就抛异常。解决先看日志定位再做对应处理。# 查看 NameNode 日志找到第一个异常 tail -200 $HADOOP_HOME/logs/hadoop-hdp-namenode-node1.log # 若是 clusterID 冲突且集群是刚建的新集群清空元数据重新格式化 rm -rf /data01/namenode/* hdfs namenode -format注意重新格式化是最后的办法只适合确认没有重要数据的新集群。生产环境遇到类似问题优先把备份的元数据目录拷回来而不是直接格式化。5.2 Map 跑完 100% 卡在 ShuffleReduce 迟迟不启动现象ResourceManager 页面上 Map 进度到 100%但 Shuffle 阶段一直显示 0%Reduce Task 处于 PENDING 状态整个作业像死了一样。原因多数情况是 Map 输出数据量超过了环形缓冲区导致频繁溢写Shuffle 拉取速度极慢。另一个常见原因是mapreduce.map.memory.mb设置太小Map 容器频繁被 NodeManager 杀掉重启看起来 Map 一直在跑但真正完成的任务数没有增长。解决先到用户日志里查容器是否因为物理内存超限被杀掉# 在 YARN 的 userlogs 下搜索 physical memory 相关报错 grep -i physical memory $HADOOP_HOME/logs/userlogs/application_*/container_*/syslog | tail -20确认是内存问题后按前文参数表调大 Map 容器内存并开启 Map 输出压缩。这两个动作组合起来Shuffle 卡死的问题通常立竿见影。调完后重新跑作业再观察 Shuffle 阶段是否开始有数据流动。5.3 小文件过多导致 Map 任务数爆炸现象提交一个处理几千个小文件的作业Map Task 数量直接破万ResourceManager 调度队列被占满其他作业全部排队。原因默认 FileInputFormat 按文件切分一个小文件就对应一个 Split 和一个 Map Task。几千个文件就是几千个 Task每个 Task 的启动开销远大于数据处理本身。解决入口处做两层处理。第一层定期把 HDFS 上的小文件合并成大文件可以用一个定时 MR 或 Spark 作业第二层在作业代码里用前面讲的 CombineFileInputFormat 兜底// 作业提交前指定自定义 InputFormat job.setInputFormatClass(MergeInputFormat.class);经验值是一个 Map Task 处理的数据量建议在 64MB 到 256MB 之间小于这个区间的文件都应该被合并。要确认效果看 ResourceManager 页面上的 Map Task 总数从几千降到几十说明合并生效了。5.4 数据倾斜时个别 Reduce 跑到天荒地老现象同样一个作业大部分 Reduce 一两分钟跑完个别 Reduce 跑半小时还没结束甚至报内存溢出。原因默认 HashPartitioner 对热点 key 无感知。比如按地区分区某个地区的订单量占 60%那这个地区的 Reduce 就要处理六成数据。它不是“处理得慢”是数据量本来就偏大。解决两步走。第一步对热点 key 加随机后缀把数据打散到多个 Reduce这个阶段只做局部聚合// Mapper 端对热点 key 加随机后缀打散到不同分区 int salt new Random().nextInt(256); Text newKey new Text(key.toString() _ salt);第二步在局部聚合结果上再做一次全局聚合的作业把随机后缀去掉按真实 key 合并。这个方案对求和、计数类任务效果明显但对必须保持全局顺序的任务不适用后者只能靠改分区策略或预排序搞定。两阶段聚合会多跑一个作业换来的却是消灭长尾任务值得。5.5 改了配置重启集群效果却纹丝不动现象修改了 yarn-site.xml 里的内存参数也重启了集群跑作业时发现资源总量还是老样子。原因三个可能。配置文件改到了错误的路径比如改了 mapred-site.xml 里实际属于 yarn 的参数修改只同步到了一台机器其他节点还是旧配置参数名写错Hadoop 解析时会忽略不确定的配置项不报错但也不生效。解决改完配置先确认配置同步再确认参数名最后看 UI 验证。# 1. 确认参数在活着的配置里 grep -n yarn.nodemanager.resource.memory-mb $HADOOP_HOME/etc/hadoop/yarn-site.xml # 2. 同步到所有节点 for host in node1 node2 node3; do scp $HADOOP_HOME/etc/hadoop/yarn-site.xml $host:$HADOOP_HOME/etc/hadoop/yarn-site.xml done # 3. 重启后再到 UI 上看 Cluster Metrics 的 Memory TotalResourceManager 页面上有个 Cluster Metrics 栏能看到集群总内存和活跃节点数。如果总数没变说明参数没生效变了才是真的改好了。这套验证逻辑能省下大量“改了没效果”的排查时间。6. 最后一步用三个验证手段确认集群和 MR 程序真的“稳”6.1 用 ResourceManager 页面反向验证配置配置改完有没有生效与其猜不如看页面。ResourceManager 的 Web UI 里Cluster Metrics 会显示集群总内存、总核数、活跃节点数和 Container 运行情况。如果同步了 yarn-site.xml 里的内存参数Memory Total 的数字会立刻变化。另一个值得盯的是应用的 Container 失败次数失败数持续增长说明资源不足或程序有 Bug这时候再去翻日志方向就准了。6.2 给 MR 程序加自定义计数器作业里最怕的是黑匣子式运行跑完了只知道成功失败不知道处理了多少数据、丢弃了多少脏数据。MR 框架自带计数器机制可以在代码里自定义统计项把业务指标暴露到作业页面// 在 Mapper 或 Reducer 里统计热点 key 出现次数 context.getCounter(UserStats, huge_key_count).increment(1L);作业跑完后在 ResourceManager 页面的 Job Counter 区域就能看到这个统计值。我习惯在代码里埋这几个计数器输入记录数、过滤掉的脏数据数、每个 Reduce 处理的 key 数。尤其最后一个如果某个 Reduce 的计数明显高于其他数据倾斜一眼就能看出来。6.3 用日志时间线确认 Shuffle 瓶颈作业运行完去 userlogs 目录看 Task 日志的时间戳。Map 阶段里 setup 到 map 的时间差是配置和初始化耗时map 到 cleanup 是数据处理耗时cleanup 到任务结束是溢写和分区耗时。Reduce 的日志里从 start 到第一次 shuffle 完成的时间能直接反映 Map 输出传输效率。这一套时间线看下来瓶颈在计算还是在 Shuffle 就清清楚楚了。# 查看指定 Task 的运行日志关注各阶段时间戳 tail -200 $HADOOP_HOME/logs/userlogs/application_*/container_*/syslog我自己做集群和 MR 作业习惯是每改一个参数就记下改前和改后的任务耗时、资源指标积上几次就能看出规律而不是凭感觉调参。集群和程序真正的稳定性来自可观测、可对比、可重复验证希望这套验证思路也能帮到你。本文还有配套的精品资源点击获取