企业官网建设流程全解析

简介：hadoop-3.2.4 安装包是面向大数据工程师与集群运维人员的完整发行版，适用于搭建Hadoop分布式环境、学习YARN/HDFS核心机制及排查部署问题。压缩包共2000个文件，涵盖1829个html帮助文档、82个css样式文件、60个sh运维脚本、10个sql初始化脚本及9个xml配置文件等，整体约505.9MB，结构近似官方二进制发行包，便于离线部署与对照学习。目前已有220人学习/下载，对于希望避开网络不稳定的手动下载、快速获得原生环境并研究其目录组织方式的开发者，这份内容可直接用于本地集群搭建、脚本化启停服务，并借助附带文档理解配置项含义与常见调优参数。受益于完整的sh脚本与xml样例，还能辅助验证NameNode、DataNode、ResourceManager等组件协同流程，是学习或生产预研的可靠基础包。

1. Hadoop 3.2.4 安装包：解压不等于装完，先想清楚三件事

Hadoop 3.2.4 安装包我见过太多人下完就解压、敲一句 start-all.sh，然后卡在三种状态之一：NameNode 起不来、DataNode 连不上、YARN 页面打不开。这个安装包资源解决的不是“下载”这一步，而是把从解压到跑通原生 WordCount 的完整链路一次性理顺：里面除了 hadoop-3.2.4 二进制发行版，一般还会带上 JDK 8 安装说明、五份核心 XML 配置模板和 SSH 免密脚本。拆包之前先想清楚三件事——装给谁用、目录放哪里、启动用什么用户，这三件事想明白了，后面所有坑至少能避开一半。适合谁？就是要在一台笔记本或云主机上搭单机伪分布式做学习、功能验证的从业者，也包括正在准备大数据开发环境、不想在装环境这件事上反复折腾的人。你拿到的不是一个压缩包，是一条能复现的部署路径。

2. 装前准备：JDK 版本、目录规划与安装包校验

2.1 为什么选 3.2.4：稳定性和 JDK 兼容性

Hadoop 3.2.4 是 3.2.x 分支的一个维护版本，它卡在一个比较微妙的平衡点上：往上 3.3/3.4 对内存和 CPU 的要求更高，往下 2.7/2.8 又太老，很多新接口和默认端口都对不上。对学习机和测试环境来说，3.2.4 是官方对 Java 8 支持最扎实的一代，你不需要为了跑通它去装一个更高版本的 JDK，也更不容易遇到“编译时好好的，运行时 Class 版本冲突”的玄学问题。

选型理由一句话总结：如果你只是要验证 MapReduce 逻辑、练习 HDFS 命令、跑通 YARN 调度，3.2.4 比 3.3+ 更容易一次成功。它默认的端口是 9870（NameNode Web UI）和 8088（YARN ResourceManager），这和 2.x 时代的 50070/8088 是两套体系，查教程的时候一定要分清版本，不然照着 2.x 的文章填配置，最后 Web UI 永远打不开。

这个安装包资源里给的是二进制发行版，不是源码包，所以解压即用，不需要自己编译。省掉编译这一步，是它和从 GitHub 拉源码自己 build 的最大区别。

2.2 目录规划：把“临时数据”和“安装目录”分开

我拆过太多 Hadoop 环境，见过最典型的翻车就是：hadoop.tmp.dir 用默认值，格式化 NameNode 的时候元数据写到了系统 /tmp 下，某天系统一清理，NameNode 直接起不来，报 “Failed to load FSImage”。所以拿到安装包之后，第一件事不是解压，而是先把目录规划好。

常见做法是把安装文件放 /opt/hadoop，把运行数据放 /data/hadoop 下，两者分开。数据目录再拆成三块：tmp 放 mapreduce 中间结果和临时文件，name 放 NameNode 元数据，data 放 DataNode 数据块。这样后面万一要重装，只需要清空 /data/hadoop，安装目录还能留着。

sudo useradd -m -s /bin/bash hadoop sudo mkdir -p /opt/hadoop sudo mkdir -p /data/hadoop/tmp /data/hadoop/name /data/hadoop/data sudo chown -R hadoop:hadoop /opt/hadoop /data/hadoop

逻辑说明：创建独立的 hadoop 用户，是为了避免直接用 root 启动 Hadoop 时踩到 3.x 的 root 限制；chown 把安装目录和数据目录的属主都交给 hadoop 用户，后面所有命令都用这个用户执行。参数说明：/opt/hadoop 是后面 $HADOOP_HOME 的指向位置；/data/hadoop/tmp、name、data 三个子目录分别对应该安装包里 core-site.xml 和 hdfs-site.xml 里要填的路径。

2.3 安装包校验和解压

很多人忽略这一步。Hadoop 安装包从镜像站下载，有极小概率碰到包损坏，最常见的现象是解压时报 “gzip: invalid compressed data” 或者解压后 bin/hdfs 文件执行就报错。先做一次 MD5 校验，比解压到一半才发现问题再回头重新下载要省时间得多。

# 校验安装包完整性 md5sum hadoop-3.2.4.tar.gz # 解压到 /opt 目录，并改名为 /opt/hadoop tar -zxvf hadoop-3.2.4.tar.gz -C /opt/ mv /opt/hadoop-3.2.4 /opt/hadoop

逻辑说明：md5sum 会输出一段 32 位十六进制串，去 Apache 官方发布页对应版本号下核对这个值，不一致就重新下载，别硬着头皮解压。tar 的 -C 参数指定解压目标目录，先解压到 /opt，再把目录名统一成 hadoop。参数说明：-zxvf 里 z 表示 gzip 压缩、x 表示解压、v 表示显示解压过程、f 表示指定文件名；mv 改名这一步是为了让环境变量路径更短，也避免版本号改动后脚本里路径要跟着改。

解压完成后，花十几秒看一眼目录结构：bin 下是客户端命令，sbin 下是启动脚本，etc/hadoop 下是所有配置文件，share/hadoop/mapreduce 下是自带示例 jar 包。后面几步全部围绕 etc/hadoop 展开，这个目录就是整个 Hadoop 的黑匣子入口。

3. 五份 XML 配置：伪分布式最该改的参数就这几个

3.1 环境变量：让 hadoop 脚本找到 JDK

Hadoop 的启动脚本本质是一个个 shell 脚本，它们靠 JAVA_HOME 找到 java 命令，再靠 HADOOP_HOME 定位自己的 bin、sbin、etc 目录。很多人只配了 PATH 没配 JAVA_HOME，表面上 hadoop 命令能敲出来，但一执行 start-dfs.sh 就报 “JAVA_HOME is not set”。这一步直接写在用户环境变量里，比改 /etc/profile 更稳妥。

export JAVA_HOME=/opt/jdk1.8.0_202 export HADOOP_HOME=/opt/hadoop export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin

逻辑说明：这三行加到 hadoop 用户的 ~/.bashrc 末尾，source 一次即可。HADOOP_HOME 指向上一节解压出来的目录，PATH 里加上 bin 和 sbin，是为了让 hdfs、yarn、start-dfs.sh 这些命令不用写全路径。参数说明：JAVA_HOME 必须写成你实际 JDK 安装路径，不要写相对路径；如果你用的版本不是 jdk1.8.0_202，这里要改成自己机器上 java -version 对应的路径，一个字符都不能差。

还有一个更容易漏的地方：etc/hadoop/hadoop-env.sh 里有一行 export JAVA_HOME 经常被注释着，hadoop 脚本加载完用户环境变量后还会读这个文件，如果这里没配，部分脚本照样找不到 JDK。我一般会在 hadoop-env.sh 里再显式写一遍export JAVA_HOME=/opt/jdk1.8.0_202，双保险。

3.2 core-site.xml：默认文件系统与临时目录

core-site.xml 是 Hadoop 全局配置里最先生效的一份。伪分布式只跑一个节点，最需要改的就是 fs.defaultFS 和 hadoop.tmp.dir。前者决定客户端执行 hdfs dfs 命令时默认连到哪个 NameNode，后者决定 NameNode 和 DataNode 的默认数据落盘位置。

<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/data/hadoop/tmp</value> </property> </configuration>

逻辑说明：fs.defaultFS 写成 hdfs://localhost:9000，表示所有 HDFS 操作默认连接本机 9000 端口的 NameNode RPC 服务。hadoop.tmp.dir 覆盖了默认的 /tmp/hadoop-${user}，指向我们在 2.2 节建好的目录，这样系统清理 /tmp 不影响元数据。参数说明：9000 端口要和 hdfs-site.xml 里的 NameNode RPC 端口保持一致，通常不用改；hadoop.tmp.dir 一旦配好，后面格式化 NameNode 时数据会写进这个名字目录下的 dfs 子目录里。

3.3 hdfs-site.xml：副本数、元数据目录与数据目录

伪分布式只有一台机器、一个 DataNode，所以 dfs.replication 必须设成 1。如果保持默认的 3，所有数据块都会因为副本不足停在 “Under replicated” 状态，虽然任务能跑，但 HDFS 会一直报健康告警。这里也把 name.dir 和 data.dir 显式指向 /data/hadoop 下的独立子目录。

<configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>file:///data/hadoop/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:///data/hadoop/data</value> </property> <property> <name>dfs.permissions.enabled</name> <value>false</value> </property> </configuration>

逻辑说明：dfs.replication 设为 1，避免复制因子高于节点数导致的副本告警。name.dir 是 NameNode 存 FSImage 和 EditLog 的路径，data.dir 是 DataNode 存数据块的路径，符号是 file:// 开头的本地路径。dfs.permissions.enabled 在单机学习时设 false，可以避免文件属主和权限问题干扰测试，生产环境千万别照抄这一项。参数说明：file:///data/hadoop/name 是三个斜杠，第一个是协议分隔符，后两个是绝对路径起始，漏一个斜杠会直接报路径解析错误。

3.4 yarn-site.xml 与 mapred-site.xml：内存配额与框架选择

YARN 是资源调度层，它负责告诉 NodeManager“你这台机器最多能跑多少内存、多少 vCPU”。mapred-site.xml 则决定 MapReduce 任务提交到哪个框架。伪分布式最容易出的问题就是 YARN 默认内存参数和本机实际内存不匹配——机器只有 4G 内存，NodeManager 默认却认为自己有 8G 可用，最后 Container 频繁被杀。

<configuration> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>4096</value> </property> <property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>4096</value> </property> <property> <name>yarn.nodemanager.resource.cpu-vcores</name> <value>2</value> </property> </configuration>

逻辑说明：nodemanager.resource.memory-mb 是这台机器能分给 YARN 的总内存，我这里按 4G 机器配置，如果你的机器是 8G 或 16G，可以相应调大。scheduler.maximum-allocation-mb 是单个 Container 能申请的上限，必须大于等于 map/reduce 各自的内存需求，否则任务会一直卡在调度阶段。cpu-vcores 按物理核数填，2 是虚拟机环境比较容易一次通过的值。参数说明：YARN 总内存不要超过机器物理内存减掉系统占用后的值，否则操作系统会因为你同时跑了 NameNode、DataNode 再加 YARN 而开始换页，整个集群响应变慢。

mapred-site.xml 里最关键的是 mapreduce.framework.name，必须设成 yarn，否则任务不会提交到 YARN 上。然后是 map 和 reduce 的单个任务内存，这里设 1024MB，配合前面的 4096MB 上限，同一时间最多能并行 4 个 map。

<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> <property> <name>mapreduce.map.memory.mb</name> <value>1024</value> </property> <property> <name>mapreduce.reduce.memory.mb</name> <value>1024</value> </property> </configuration>

逻辑说明：framework.name 写 yarn，提交 job 时客户端会把任务交给 ResourceManager 去调度，而不是走本地 jobrunner。map.memory.mb 和 reduce.memory.mb 是每个 map/reduce Container 的内存大小，单位是 MB。参数说明：这两个值乘上并发度要小于 yarn.scheduler.maximum-allocation-mb，如果以后跑大任务，优先调大 maximum-allocation-mb，而不是把单个 Container 撑得太大。

3.5 workers 文件与 SSH 免密：DataNode 从哪台机器启动

3.2.4 里，决定 DataNode 和 NodeManager 跑在哪台机器上的文件叫 workers，位置在 etc/hadoop/workers。2.x 时代它叫 slaves，很多人沿用旧文件名，结果 start-dfs.sh 读不到任何节点信息，一个 DataNode 都起不来。

# 写入本机节点名 cat > $HADOOP_HOME/etc/hadoop/workers << EOF localhost EOF

逻辑说明：workers 文件里每行一个节点名。伪分布式只有一台机器，写 localhost 即可。如果你后面想扩展成两台或三台，在这个文件里追加 IP 或主机名，再配好免密就能直接拉起。参数说明：这里不要写空格以外的多余符号，空行不影响；文件里第一行数据会被用来启动 DataNode，写错主机名或 IP 就会看到 NameNode 起来了、DataNode 死活不见。

SSH 免密是另一个前置条件。start-dfs.sh 会通过 ssh 到 workers 上每个节点启动 DataNode，如果不配免密，脚本会停在密码提示上，而且每个节点问一遍，非常折磨。

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys ssh localhost

逻辑说明：生成一对无密码的 RSA 密钥，把公钥追加到本机授权列表里，sshd 就会免密放行。最后 ssh localhost 如果直接进 shell 不再问密码，就说明配好了。注意要在你启动 Hadoop 的那个用户下执行，不是 root 下执行完切回 hadoop 用户就失效。参数说明：-P '' 表示空口令，-f 指定密钥存放位置，chmod 600 是很多免密失败的根源——authorized_keys 权限如果太宽松，sshd 会直接忽略它。

4. 格式化与启动：NameNode 初始化时机和三层验证

4.1 格式化 NameNode：只做一次，做对一次

格式化 NameNode 是伪分布式搭建里最容易被误操作的一步。格式化会清空 hdfs-site.xml 中 dfs.namenode.name.dir 指向的目录，并生成 FSImage、clusterID 等元数据。它只在第一次部署时执行一次，后续重启集群绝对不要重复格式化。很多教程没说清楚这句话，导致新手每次启动失败就改配置、重新格式化，最后 DataNode 的 clusterID 和 NameNode 不一致，数据节点永远连不上。

$HADOOP_HOME/bin/hdfs namenode -format

逻辑说明：这条命令会读取 core-site.xml 里的 hadoop.tmp.dir 和 hdfs-site.xml 里的 name.dir，在对应目录下创建 current 子目录，写入 fsimage_0000000000000000000 文件和一个 VERSION 文件，VERSION 里就是 clusterID。格式化成功时日志里会明确打印 “successfully formatted”。参数说明：执行这一段之前，必须确认第 3 章的配置全部写完，尤其是 hadoop.tmp.dir 不再指向 /tmp；如果之前已经格式化过、后面改过配置，最稳妥的做法是手动清空 /data/hadoop/name、/data/hadoop/data、/data/hadoop/tmp 三个目录后重新格式化，而不是在旧数据上反复覆盖。

4.2 启动顺序：先 HDFS 再 YARN

启动顺序有讲究，先 HDFS 后 YARN。HDFS 起来了，NameNode 和 DataNode 才能提供服务，YARN 的 NodeManager 在启动时也会尝试去联络 HDFS，顺序反了容易出现日志里一大片连接拒绝的报错。大部分环境用普通用户启动是正常路径，但如果你和我一样图省事用 root 跑的云主机，Hadoop 3.x 会直接拒绝：脚本里会对 HDFS 和 YARN 的每个角色做用户名校验，root 用户需要先在 hadoop-env.sh 里显式声明允许。

# 常见部署方式（普通用户，已配好免密） $HADOOP_HOME/sbin/start-dfs.sh $HADOOP_HOME/sbin/start-yarn.sh

逻辑说明：start-dfs.sh 会读取 workers 文件，通过 ssh 到 localhost 启动 DataNode；start-yarn.sh 同理启动 NodeManager。两条命令分别执行，比用 start-all.sh 更利于定位是 HDFS 还是 YARN 出了问题。参数说明：如果你是 root 跑的，先在 hadoop-env.sh 里加这几行再执行启动：HDFS_NAMENODE_USER=root、HDFS_DATANODE_USER=root、HDFS_SECONDARYNAMENODE_USER=root、YARN_RESOURCEMANAGER_USER=root、YARN_NODEMANAGER_USER=root，否则脚本会在连 ssh 之前就报 “Attempting to operate on hdfs namenode as root”。

4.3 三层验证：进程、日志、Web UI

启动完成后，第一件事不是跑任务，而是确认进程全不全。jps 是 JDK 自带工具，能列出所有由 JVM 启动的 Hadoop 进程。对照以下表格，五个进程缺一个都算没起来：

jps

逻辑说明：看到上面五个进程名，说明进程层面没问题。如果一个都没有，先看 JDK 是否安装；如果进程启动后马上消失，去 $HADOOP_HOME/logs 下找 hadoop-hadoop-namenode-localhost.log，最后几十行就是原因。参数说明：jps 默认只显示简短进程名，想看到完整启动命令行可以用 jps -l；如果 NameNode 的进程名出现但端口没监听，多半是端口被其他服务占用，用 lsof -i:9870 查一下。

端口和存储层面的验证，用 hdfs dfsadmin -report 和 yarn node -list 两条命令更直接。

hdfs dfsadmin -report yarn node -list

逻辑说明：dfsadmin -report 会输出每个 DataNode 的存储容量、已使用空间、状态，以及整个集群的块健康情况。yarn node -list 显示 ResourceManager 视角里活跃的 NodeManager 节点，能看到节点的内存和 vCPU 总量。参数说明：dfsadmin -report 输出里如果 Live datanodes 数量是 0，说明 DataNode 和 NameNode 之间的 clusterID 没对上，这就是第 5 章要展开讲的第一个高频坑；yarn node -list 里如果 Rack 显示为 default-rack，说明节点没配置机架拓扑，伪分布式不用管，多机集群后面需要单独配。

三层验证的顺序是：先看进程，再看日志，最后看 Web UI。浏览器打开 http://localhost:9870 确认 NameNode 状态，打开 http://localhost:8088 确认 YARN 集群状态。这一步过了，环境才算立住了。

5. 避坑：五个高频翻车点和对应处理

5.1 进程起不来：三个启动阶段的坑

现象一：NameNode 进程启动后秒退，日志里报 “Failed to load FSImage file ... No such file or directory”。

原因：格式化时 hadoop.tmp.dir 还是默认的 /tmp/hadoop-${user}，系统重启或定时清理后，NameNode 的 current 目录被清掉，元数据文件不存在。解决：先修改 core-site.xml 固定 hadoop.tmp.dir 为 /data/hadoop/tmp，然后执行rm -rf /data/hadoop/tmp /data/hadoop/name /data/hadoop/data，再做一次hdfs namenode -format，最后重新 start-dfs.sh。从那以后我再也没有把元数据放在系统临时目录里。

现象二：jps 里 DataNode 进程在，但 dfsadmin -report 显示 Live datanodes 是 0。

原因：格式化 NameNode 执行了多次，每次都会生成新的 clusterID，而 DataNode 的 current/VERSION 里还是旧 clusterID，NameNode 校验不一致拒绝注册。解决：用cat /data/hadoop/name/current/VERSION看 NameNode 的 clusterID，再用cat /data/hadoop/data/current/VERSION看 DataNode 的 clusterID，把 DataNode 里那个值改成和 NameNode 一致，重启 DataNode。这是伪分布式搭建里最常见的“启动成功但连不上”原因。

现象三：start-dfs.sh 执行后一直要求输入 SSH 密码，每个节点问一遍。

原因：SSH 免密没配好，或者是在 root 用户下生成的密钥，切换到 hadoop 用户后配置全部失效。解决：确认当前启动用户，执行whoami核对，然后在该用户下重新走一遍ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa、cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys、chmod 600 ~/.ssh/authorized_keys三步，最后ssh localhost验证不再问密码再执行启动命令。

5.2 能启动但任务失败：两个运行阶段的坑

现象四：hadoop 或者 hdfs 命令报 “JAVA_HOME is not set”，或者提示 java: command not found。

原因：只配置了 PATH 指向 $HADOOP_HOME/bin，没设置 JAVA_HOME，hadoop 脚本里所有调用 java 的地方都失效了；或者 hadoop-env.sh 里 export JAVA_HOME 那一行还注释着。解决：在 hadoop-env.sh 里显式加export JAVA_HOME=/opt/jdk1.8.0_202，并用$JAVA_HOME/bin/java -version验证这个路径能直接执行。很多脚本绕过了用户环境变量，只读 hadoop-env.sh，所以这份文件里的 JAVA_HOME 比 ~/.bashrc 里的更关键。

现象五：WordCount 任务跑到一半失败，日志里出现 “Container is running beyond virtual memory limits” 或者 “No space left on device”。

原因：虚拟内存超限是 YARN 默认开启 vmem 检查，单个 Container 申请 1G 物理内存，但 JVM 实际分配和系统统计的虚拟内存加起来远超限制，NodeManager 直接把 Container 杀了。磁盘不足则是 hadoop.tmp.dir 还在系统盘，中间结果把 / 分区写满。解决：虚拟内存可以在 yarn-site.xml 里把yarn.nodemanager.vmem-pmem-ratio调大到 4~6，或者学习环境直接设yarn.nodemanager.vmem-check-enabled为 false；磁盘不足就把 hadoop.tmp.dir 和 name.dir 全部迁移到大分区后重启。这两个坑都是参数和机器资源不匹配导致的，不是代码问题。

6. 用自带 WordCount 跑通全链路：一个验证技巧和三组参数检查

6.1 一条命令链：WordCount 冒烟测试

环境立住之后，最后一步是跑一个最简 MapReduce 任务。Hadoop 安装包自带 examples jar 包，位置在 share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.4.jar，里面就有 wordcount。这一步跑通了，说明 HDFS 读写、YARN 调度、Container 启动全链路都没问题。

hdfs dfs -mkdir -p /input hdfs dfs -put $HADOOP_HOME/etc/hadoop/*.xml /input/ hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.4.jar wordcount /input /output hdfs dfs -cat /output/part-r-00000 | head -20

逻辑说明：前三行分别完成建输入目录、上传配置目录下的 XML 文件作为输入数据、提交 wordcount 任务。第四行读取 reduce 输出文件。任务跑起来后，看到输出里每个单词和计数的键值对，整个伪分布式环境就算真正可用了。参数说明：/output 目录在任务启动前不能存在，MapReduce 不会自动覆盖同名输出目录，重复执行前要hdfs dfs -rm -r /output；如果想让任务只执行一轮，第一行用 /input 目录最后不要加斜杠，客户端解析路径时行为更稳定。

跑 WordCount 时我一般会多等一分钟再去浏览器看结果。MapReduce 任务从提交到输出，中间有 ApplicationMaster 申请、Container 分配、map 阶段 shuffle、reduce 阶段合并，第一次跑会慢是正常的，不要看到几分钟没动静就手动 kill。

6.2 三个验证技巧与参数检查

第一个技巧：看日志而不是猜原因。任务失败后不要马上改配置重试，先去 $HADOOP_HOME/logs/userlogs 目录下找当前任务的 container 日志。这里记录了 stdout、stderr 和 syslog，绝大多数失败原因都在 syslog 里。想更详细，可以在启动时加上环境变量HADOOP_ROOT_LOGGER=DEBUG,console，这样 hadoop 命令会直接输出调试日志，能看到每个 RPC 调用和调度决策，适合排查“任务卡住不动”的问题。

第二个技巧：用 fsck 检查 HDFS 健康度。hdfs fsck / -files -blocks会输出每个文件的块分布和副本状态。伪分布式环境里，看到 REPORT 行写着 HEALTHY 就是正常的；如果出现 MISSING 块，说明之前可能清理不彻底，需要检查 data.dir 下是否有多个残留 current 目录。

第三个技巧：核对 YARN 页面的资源数字。打开 8088 页面，看 Active Nodes 下节点的 Used Memory、Total Memory 是不是和你配置的 yarn.nodemanager.resource.memory-mb 一致。不一致说明节点没重启或者 YARN 还缓存着旧配置，这时去 NodeManager 日志里确认重启时间，而不是盲目调大任务内存。

收尾前，把最常见的几个参数做成一张自查表，每次部署完对着它过一遍：

从那以后我每次搭 Hadoop 环境，都强制走一遍“格式化前删旧目录、jps 对照五个进程、跑一次 WordCount 冒烟”这三件事，尤其是第二件事，五进程齐不齐直接决定了前面一小时的配置有没有落对。顺序一旦乱了，排查时间往往比第一次配置还长。希望这次拆包笔记帮你在 hadoop-3.2.4 安装包这条路上少绕几个弯。

本文还有配套的精品资源，点击获取