企业官网建设流程全解析

简介：hadoop-2.6.5.tar.gz 是 Apache Hadoop 2.6.5 的 Linux 发行压缩包，属于大数据基础架构中的经典版本，面向需要搭建分布式存储与计算环境的大数据开发、运维人员及实验学习者，可解决海量数据的可靠存储、高效分析与集群资源调度问题。压缩包共 900 个文件，总大小约 175.09MB，其中 477 个 jar 依赖库支撑核心运行组件，129 个 class 类文件构成可执行逻辑，51 个 xml 文件提供 core-site、hdfs-site、mapred-site 等配置模板，50 个 sh 脚本负责集群启停与守护进程管理，另外还包含 18 个 html 监控页面、16 个 bat 辅助脚本及 properties、cmd、txt 等资源，目录涵盖 bin、sbin、etc、lib、share 等标准模块，解压后即可按官方结构快速定位配置项。已有 1268 人学习下载，适合从零开始理解 HDFS、MapReduce 与 YARN 的协作机制，并通过修改关键配置、启动服务与运行示例来验证安装。借助这套发行版，可进一步衔接 Hive、Spark、HBase 等生态组件，是课程实验、入门研究与生产部署前演练的可靠素材。

1. 一份能直接落地的 hadoop-2.6.5.tar.gz：别急着解压，先看清楚它在你的部署里充当什么角色

很多刚接触大数据的朋友，拿到 hadoop-2.6.5.tar.gz 的第一反应是解压、配环境变量、启动，结果卡在各种玄学报错里。我拆过不少离线部署环境，这份资源的核心价值在于它是一份未经二次修改的原版 Hadoop 2.6.5 二进制发行包，解压即用，省去了从源码编译的漫长等待。它解决的是「版本选型」和「环境一致性」两个问题：你不需要再纠结到底该下 CDH 还是 HDP，不需要担心网上散落的安装包被人动过手脚，一个官方的 tar.gz 就能撑起伪分布式学习、课程设计、甚至小规模集群的底座。适合谁？打算系统学习 HDFS 和 MapReduce 的初学者、要做 Hadoop 课程设计的在校生、以及需要在离线内网环境快速搭一套 Hadoop 的运维新人。但使用它之前，有几件事必须想清楚。

2. 为什么还在用 hadoop-2.6.5：部署前必须知道的版本定位与三个边界

2.1 从 JDK 兼容性看版本选择的底层逻辑

hadoop-2.6.5 是 2.x 系列里的一个稳定补丁版本，发布于 2016 年附近。它对应的是 JDK 1.7 和 JDK 1.8 都能跑的时代，这一点在部署时非常重要。很多人拿到 tar.gz 直接配 JDK 11 甚至 JDK 17，结果启动 NameNode 的时候直接报UnsupportedClassVersionError，这就是没搞明白版本边界导致的翻车现场。

我的经验是：如果只是跑课程设计、伪分布式练习，JDK 1.8 是最省事的选择。2.6.5 的编译目标字节码是 JDK 1.7 级别，JDK 1.8 向下兼容，不会出问题。但换成 JDK 11 之后，javax 包结构变化、JAXB 模块被移除，Hadoop 2.6.5 里的很多脚本和依赖会找不到类。这不是 Hadoop 的问题，是时代的问题，2.6.5 生来就不是给新 JDK 准备的。

2.2 伪分布式、完全分布式与 HA 的边界判定

hadoop-2.6.5.tar.gz 解压出来后，你能用它搭建三种不同形态的环境。很多新手分不清这三者的区别，导致配置文件改得乱七八糟。

第一种是伪分布式，所有进程（NameNode、DataNode、ResourceManager、NodeManager）都跑在同一台机器上。适合学习 HDFS 读写流程、跑通第一个 MapReduce 作业。你只需要一个 core-site.xml 一个 hdfs-site.xml 就能跑起来。

第二种是完全分布式，至少三台机器，分别承担不同角色。这里要改的文件一下子变成五个，还要处理 SSH 免密登录、IP 和 hostname 映射。2.6.5 在这方面的配置逻辑和 3.x 差别不大，但 YARN 的资源配置参数名称有细微差异，比如yarn.nodemanager.resource.memory-mb，在 3.x 里已经改成了yarn.nodemanager.resource.memory-mb对应的新命名空间，但 2.6.5 用的还是老一套，照着新教程抄容易踩坑。

第三种是HA 高可用，需要额外引入 Zookeeper 集群来协调 NameNode 的主备切换。2.6.5 是支持 HA 的，但它的 HA 配置比 3.x 繁琐得多，尤其是手动故障切换和自动故障切换的配置项容易混淆。我后面专门有一章讲这个。

2.3 文件系统与网络端口的隐含约定

hadoop-2.6.5.tar.gz 解压后的目录结构里，etc/hadoop是配置重地，sbin目录存放启停脚本，bin目录存放命令行工具。这套结构是 Hadoop 的经典布局，但从 2.6.5 到 3.x 没有大变化，所以你对这份资源的目录记忆，未来迁移到新版本时依旧适用。注意，2.6.5 默认使用HADOOP_PREFIX或HADOOP_HOME来定位安装目录，环境变量配错会导致脚本找不到配置文件，表现为Cannot find configuration directory这类报错。

另外一个隐含约定是端口。2.6.5 的 NameNode Web UI 默认端口是 50070，YARN 的 ResourceManager Web UI 是 8088，SecondaryNameNode 是 50090。这些端口和 3.x 不一样，3.x 把 NameNode Web UI 改成了 9870。如果你照着新文章排查 50070 端口打不开的问题，本身就是个伪问题。

3. 伪分布式搭建实战：从 tar.gz 到跑通第一个 MapReduce 作业

3.1 环境准备与解压安装

先把 JDK 1.8 装好并确认java -version能正常输出，然后创建专门的数据目录和安装目录。我一般习惯把大数据组件统一放在/opt下面，日志和元数据放在/data下面，这样出问题的时候好排查，日志也不会把系统盘撑爆。

mkdir -p /opt/hadoop mkdir -p /data/hadoop/tmp mkdir -p /data/hadoop/name mkdir -p /data/hadoop/data tar -zxvf hadoop-2.6.5.tar.gz -C /opt/hadoop mv /opt/hadoop/hadoop-2.6.5 /opt/hadoop/hadoop ls -l /opt/hadoop/hadoop/etc/hadoop/

这里把解压后的目录改名成了 hadoop，纯属个人习惯，方便以后升级版本的时候做软链接替换。etc/hadoop目录下你会看到core-site.xml、hdfs-site.xml、mapred-site.xml.template等文件，其中mapred-site.xml需要你手动从模板复制出来，这个细节很多教程都会忽略。

3.2 五个关键配置文件的参数拆解

伪分布式的配置核心在于五个文件，但实际要动的只有三四个。先说etc/hadoop/hadoop-env.sh，这个文件负责定义 Java 环境变量，需要把JAVA_HOME改成你的实际路径，不要用export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:bin/java::")这种取巧办法，直接写死路径最稳妥。

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_HOME=/opt/hadoop/hadoop export HADOOP_CONF_DIR=/opt/hadoop/hadoop/etc/hadoop export HADOOP_LOG_DIR=/data/hadoop/logs

接着是core-site.xml，这里最关键的两个参数是fs.defaultFS和hadoop.tmp.dir。前者决定了 HDFS 的访问入口，后者决定了元数据和数据块的根目录。很多新手不配hadoop.tmp.dir，默认存在/tmp下面，系统一重启数据就没了，属于血泪教训。

<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表示 NameNode 的 RPC 通信端口是 9000，后续所有客户端和 DataNode 都通过这个地址连接 NameNode。hadoop.tmp.dir是 HDFS 元数据和数据块的根目录，/data/hadoop/tmp需要预先创建并保证写权限，否则格式化时直接报错。

然后是hdfs-site.xml。伪分布式模式下，需要把副本数从默认的 3 改成 1，同时显式指定 NameNode 和 DataNode 的数据存储路径，不要依赖默认值。

<configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/data/hadoop/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/data/hadoop/data</value> </property> </configuration>

这段配置的逻辑很直接：单机环境副本数写 1，否则每个数据块会尝试写三份，直接磁盘溢出或报资源不足。NameNode 的 name.dir 存的是 fsimage 和 edits 日志，DataNode 的 data.dir 存的是实际数据块，两个目录分开有利于后续做磁盘故障隔离。实际部署时，name.dir 可以配多个路径用逗号分隔，实现元数据冗余，这也是 2.x 常见的生产配置手段。

接着处理mapred-site.xml，这个文件默认不存在，需要从模板复制。

cp /opt/hadoop/hadoop/etc/hadoop/mapred-site.xml.template /opt/hadoop/hadoop/etc/hadoop/mapred-site.xml

内容只有一项核心配置：指定 MapReduce 运行在 YARN 之上。

<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> </configuration>

如果这个参数不写，MapReduce 作业会跑在 local 模式下，作业提交到本地 JVM，数据不会走 HDFS，虽然也能出结果，但完全体验不到 YARN 的资源调度过程。课程设计里如果只要求跑通 WordCount，local 模式能跑出结果就算过关，但面试时如果被问起作业提交流程，就会露馅。

最后是yarn-site.xml，伪分布式至少要配置 ResourceManager 的地址和 NodeManager 的辅助服务。

<configuration> <property> <name>yarn.resourcemanager.hostname</name> <value>localhost</value> </property> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> <property> <name>yarn.nodemanager.aux-services.mapreduce_shuffle.class</name> <value>org.apache.hadoop.mapred.ShuffleHandler</value> </property> </configuration>

这里的yarn.nodemanager.aux-services必须配成mapreduce_shuffle，这是 MapReduce 作业在 YARN 上运行时，NodeManager 为 Shuffle 过程提供的辅助服务。如果漏配，作业提交后 Container 启动失败，日志里会报ShuffleHandler找不到相关的类错误。2.6.5 版本里这个参数名是固定的，和 3.x 一致，这部分倒是没有版本差异。

3.3 初始化与启动流程

配置文件都改完之后，下一步是格式化 HDFS。很多人直接在这一步翻车，原因是多次格式化导致clusterID不一致，或者格式化时 NameNode 已经启动导致端口占用。

hdfs namenode -format

格式化过程的输出里，最关键的看两处信息：一是clusterID是否生成，二是Storage directory /data/hadoop/name has been successfully formatted这句确认信息。如果看到java.io.IOException: Cannot create directory /data/hadoop/name，说明目录权限不对，检查属主和写权限即可。

格式化完成后，启动 HDFS 和 YARN。

/opt/hadoop/hadoop/sbin/start-dfs.sh /opt/hadoop/hadoop/sbin/start-yarn.sh

启动完执行jps命令验证进程，正常应该看到NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager五个进程。少任何一个都别急着跑作业，先看对应日志。

跑第一个 MapReduce 作业，我用的是 Hadoop 自带的 WordCount 示例，不需要自己写代码，这是最快验证环境是否可用的方式。

hdfs dfs -mkdir -p /input hdfs dfs -put /etc/hadoop/core-site.xml /input/ hadoop jar /opt/hadoop/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.6.5.jar wordcount /input /output hdfs dfs -cat /output/part-r-00000

命令逻辑：先把本地的 core-site.xml 上传到 HDFS 的 /input 目录，然后用官方示例包跑 wordcount，输出到 /output。跑完从 part-r-00000 文件里读结果。如果作业卡在map 100% reduce 0%超过几分钟，通常是内存不足或者 Shuffle 配置有问题，看下文排查章节。

4. 伪分布式踩坑实录：五个高发问题与排查路径

4.1 DataNode 进程启动后立刻消失

现象：start-dfs.sh执行后，NameNode 在 jps 里能看到，但 DataNode 进程死活起不来，或者起来几秒就自动退出。查看/data/hadoop/logs目录下的hadoop-hadoop-datanode-*.log文件，能看到java.io.IOException: Inconsistent clusterIDs相关报错。

原因：这是 2.x 系列最经典的翻车点。你第一次hdfs namenode -format之后跑了一段时间，后来觉得配置改得不对，又执行了一次格式化，新的 clusterID 写入 NameNode 的元数据，但 DataNode 的数据目录里还是旧的 clusterID，两边对不上，DataNode 拒绝启动。

解决：停掉所有进程，把 NameNode 和 DataNode 的存储目录全部清空重建，然后重新格式化。注意，/data/hadoop/name和/data/hadoop/data都删掉，不能只删一个。命令如下：

/opt/hadoop/hadoop/sbin/stop-all.sh rm -rf /data/hadoop/name/* /data/hadoop/data/* hdfs namenode -format -force /opt/hadoop/hadoop/sbin/start-all.sh

从那以后我每次重新格式化之前，都强制走一遍「先停进程再清目录」的流程，从源头避开这个坑。

4.2 JAVA_HOME 配置不生效

现象：执行start-dfs.sh时，脚本报Error: JAVA_HOME is not set and could not be found，但你在/etc/profile里明明已经 export 了JAVA_HOME。

原因：start-dfs.sh脚本在执行时，是通过hadoop-env.sh里的JAVA_HOME变量来定位 Java 环境的，而不是直接读系统环境变量。如果你只改了/etc/profile，没改hadoop-env.sh，脚本里找不到 Java 就会直接退出。这个设计很坑，但一旦知道就再也不会犯。

解决：在/opt/hadoop/hadoop/etc/hadoop/hadoop-env.sh文件顶部显式加上export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk，不要用$(command -v java)之类的动态解析，直接写死最靠谱。

4.3 ResourceManager 启动后无法访问 8088 端口

现象：start-yarn.sh执行成功，jps 能看到ResourceManager进程，但浏览器访问http://localhost:8088一直转圈或拒绝连接。

原因：可能是防火墙没放行 8088 端口，也可能是yarn-site.xml里 ResourceManager 绑定的 hostname 写成了实际机器名，但客户端访问走 localhost，两者不一致导致页面地址跳转异常。2.6.5 的 YARN Web UI 对 hostname 解析非常敏感，绑定的是myhost却用localhost访问，页面会跳到myhost:8088然后超时。

解决：检查防火墙状态，同时把yarn-site.xml里的yarn.resourcemanager.hostname改成0.0.0.0或localhost，具体看你的部署形态。单机伪分布式直接写 localhost，集群环境写域名。改完重启 YARN 即可。

4.4 MapReduce 作业提交后 Container 反复失败

现象：作业能提交上去，但 Console 里频繁出现Container is running beyond virtual memory limits的报错，作业最终失败。

原因：伪分布式机器的物理内存往往只有 4G 或 8G，但yarn-site.xml默认的虚拟内存放大比例和物理内存限制都偏高，NodeManager 在计算容器内存时把虚拟内存也算进去了，单个 Container 申请的内存超过系统可用值，直接被判定为超限杀掉。这在低配电脑上极其常见，属于资源配置与实际硬件不符造成的经典问题。

解决：在yarn-site.xml里显式调小资源上限，并关闭虚拟内存检查。

<property> <name>yarn.nodemanager.resource.memory-mb</name> <value>2048</value> </property> <property> <name>yarn.nodemanager.vmem-pmem-ratio</name> <value>2.1</value> </property> <property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property>

这里yarn.nodemanager.resource.memory-mb设为 2048 表示 NodeManager 可分配给容器的物理内存上限是 2G，vmem-pmem-ratio是虚拟内存与物理内存的比例上限，vmem-check-enabled直接关闭虚拟内存超限检查。这三项配合，在 4G 内存的虚拟机上跑 WordCount 就稳了。注意不要只调小物理内存而不动虚拟内存比例，否则还是会报超限。

4.5 SSH 免密登录配置了但仍然提示输入密码

现象：配好 ssh-keygen 并把公钥追加到authorized_keys之后，执行start-dfs.sh脚本还是要求输入目标机器的密码，导致启动失败。

原因：脚本通过 SSH 到各角色节点执行远程命令，如果你修改了/etc/hosts映射但公钥是给 IP 或旧 hostname 生成的，或者authorized_keys文件的权限不是 600，SSH 会选择忽略这个认证文件。此外.ssh目录权限必须是 700，否则免密直接失效，这是 Linux SSH 安全策略强制规定的。

解决：重建免密，并修改目录权限后才能生效。

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

执行ssh localhost如果不要求密码，说明免密配置成功。多节点场景需要对每个目标主机做同样的操作，换成目标机器的主机名做验证。

5. Hadoop 2.6.5 与 Zookeeper 整合实战：从 NameNode 单点到 HA 高可用

5.1 为什么要引入 Zookeeper，以及 2.6.5 的 HA 架构边界

Hadoop 2.6.5 虽然支持 HA，但它的自动故障转移能力必须依赖外部协调组件，默认的dfs.ha.automatic-failover.enabled是 false，单纯配两个 NameNode 并不会自动切换。Zookeeper 在这里的角色是「选举协调者」：Active NameNode 和 Standby NameNode 同时向 Zookeeper 注册，Zookeeper 通过临时节点和会话超时机制判断 Active 是否存活，一旦失联，Standby 接管并切换为 Active，整个过程由 ZKFailoverController（ZKFC）进程驱动。

这个机制解决了两个问题：一是 NameNode 单点故障导致整个 HDFS 不可写的风险；二是结合 JournalNode 共享存储，让 Active 和 Standby 之间的元数据保持一致。2.6.5 的 HA 有两种形态，手动切换和自动切换，前者不依赖 Zookeeper，但需要运维人工介入；后者依赖 Zookeeper，配置项多了一些。

5.2 模拟项目X的 HA 集群规划与 Zookeeper 安装

我拆过一个典型的模拟项目X，三台虚拟机，角色分配如下：node1 运行 Active NameNode、ZKFC、JournalNode、Zookeeper；node2 运行 Standby NameNode、ZKFC、JournalNode、Zookeeper；node3 运行 DataNode、JournalNode、Zookeeper。ResourceManager 单独跑在 node1 和 node2 上做 YARN 的 HA。注意，2.6.5 的 Zookeeper 需要 3.4.5 以上版本，3.5.x 或 3.6.x 都能兼容，但 3.5 以后会有独立的 admin 端口，防火墙放行的时候别漏了。

先安装 Zookeeper，需要的配置文件是zoo.cfg，核心是 dataDir 和 server 列表，token 分隔，每个节点用 myid 文件区分身份。

mkdir -p /data/zookeeper echo "1" > /data/zookeeper/myid

myid文件的内容必须和zoo.cfg里的 server 序号一一对应，node1 写 1，node2 写 2，node3 写 3。zoo.cfg内容如下：

tickTime=2000 initLimit=10 syncLimit=5 dataDir=/data/zookeeper clientPort=2181 server.1=node1:2888:3888 server.2=node2:2888:3888 server.3=node3:2888:3888

参数说明：tickTime是 Zookeeper 使用的基本时间单元，单位毫秒；initLimit是 Follower 与 Leader 之间最长心跳次数，超过这个次数没收到响应就判定 Leader 失效；syncLimit是 Follower 与 Leader 之间请求和确认的最长心跳次数。2888 端口用于 Follower 连接 Leader，3888 用于 Leader 选举，这两个端口需要防火墙放行。

启动 Zookeeper 集群，并验证状态。

/opt/zookeeper/bin/zkServer.sh start /opt/zookeeper/bin/zkServer.sh status

status命令输出Mode: leader或Mode: follower表示集群正常，如果输出Mode: standalone说明另外两台没连上，先检查防火墙和 myid。

5.3 HDFS HA 核心配置与 ZKFC 初始化流程

回到 Hadoop 的hdfs-site.xml，HA 配置比伪分布式复杂得多，关键是nameservices和dfs.ha.namenodes。

<configuration> <property> <name>dfs.nameservices</name> <value>mycluster</value> </property> <property> <name>dfs.ha.namenodes.mycluster</name> <value>nn1,nn2</value> </property> <property> <name>dfs.namenode.rpc-address.mycluster.nn1</name> <value>node1:9000</value> </property> <property> <name>dfs.namenode.rpc-address.mycluster.nn2</name> <value>node2:9000</value> </property> <property> <name>dfs.namenode.http-address.mycluster.nn1</name> <value>node1:50070</value> </property> <property> <name>dfs.namenode.http-address.mycluster.nn2</name> <value>node2:50070</value> </property> <property> <name>dfs.namenode.shared.edits.dir</name> <value>qjournal://node1:8485;node2:8485;node3:8485/mycluster</value> </property> <property> <name>dfs.journalnode.edits.dir</name> <value>/data/hadoop/journal</value> </property> <property> <name>dfs.client.failover.proxy.provider.mycluster</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property> <property> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value> </property> <property> <name>ha.zookeeper.quorum</name> <value>node1:2181,node2:2181,node3:2181</value> </property> </configuration>

这段配置里最容易出错的是dfs.namenode.shared.edits.dir，格式必须是qjournal://host1:8485;host2:8485;host3:8485/nameservice。它是 JournalNode 的 RPC 地址，Active NameNode 把 edits 日志实时写到这个目录，Standby NameNode 从这里读取并同步到自己的内存镜像。dfs.journalnode.edits.dir是 JournalNode 本地落盘路径，三台机器上都要创建并保证可写。

初始化流程和伪分布式完全不同。先启动三台机器的 JournalNode，然后只在 node1 上执行格式化，再把格式化后的元数据同步到 node2，最后初始化 ZKFC。

hadoop-daemon.sh start journalnode hdfs namenode -format hdfs zkfc -formatZK

hdfs zkfc -formatZK会在 Zookeeper 中创建 HA 相关的持久节点，后续 NameNode 的自动故障转移都基于这些节点。注意：这一步只需要在一台机器上执行，如果多台都执行，Zookeeper 里会残留旧节点导致切换异常。

接着同步元数据到 node2。在 node2 上执行：

hdfs namenode -bootstrapStandby

bootstrapStandby会从 node1 的 NameNode 拉取最新的 fsimage 和 edits log，构建出 Standby 的初始状态。执行完成后，在两台机器上分别启动 NameNode：

hadoop-daemon.sh start namenode

然后用hdfs haadmin -getAllServiceState查看主备状态，正常应有一台输出active。手动触发一次故障转移验证整体流程：

hdfs haadmin -failover nn1 nn2

执行后再次查看状态，如果 nn2 变 active，说明整个 HA 链路打通了。从实际经验来看，第一次做 HA 大概率卡在 JournalNode 没启动就格式化 NameNode，或者 ZKFC 没 format 导致自动切换不生效，这两点务必按顺序执行。

6. 集群健康体检：三分钟验证你的 Hadoop 环境是否真的可用

环境搭好之后，很多同学跑通了一个 WordCount 就认为万事大吉，结果过了两天再打开，发现进程在但作业提交就报错。我自己的习惯是，每次启动完集群，强制自己走一遍五步体检法，全部通过才算环境真正就绪。

第一步，看进程完整性。执行jps，对比你当前部署形态对应的进程清单。伪分布式是 NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager 五个进程缺一不可；HA 模式要额外看到 ZKFC 进程，并且两台 NameNode 主备必须一 active 一 standby。少一个进程，直接去/data/hadoop/logs目录查对应的hadoop-hadoop-*.log文件，别只盯着终端输出。

第二步，查 HDFS 状态。执行hdfs dfsadmin -report，关键看两个数据：Configured Capacity和Datanodes available。后者必须等于你部署的节点数，如果少了一个，说明那个节点的 DataNode 进程起过但退出了，优先检查 clusterID 和磁盘空间。

第三步，验证文件读写。新建一个测试目录，写一个文件进去，再读出来，最后删掉。

hdfs dfs -mkdir -p /healthcheck echo "ping" | hdfs dfs -put - /healthcheck/test.txt hdfs dfs -cat /healthcheck/test.txt hdfs dfs -rm -r /healthcheck

这一步能快速暴露 HDFS 的写入和读取链路异常，比如 DataNode 线程池占满、磁盘只读、raft 日志目录损坏等问题。如果put卡住，大概率是副本数配置大于可用 DataNode 数，排查dfs.replication的配置。

第四步，查 YARN 状态。执行yarn node -list，输出里应该看到 NodeManager 的地址和状态为 RUNNING。如果显示 unhealthy，去 NodeManager 日志里查磁盘健康检查相关的警告，通常是因为本地磁盘可用空间低于阈值，YARN 会主动标记节点不健康，相关日志在yarn-hadoop-nodemanager-*.log里。

第五步，用官方示例包跑一个最小作业，但不要再用 wordcount，换成计算圆周率的pi作业，它能更灵敏地暴露 shuffle 阶段的性能问题。

hadoop jar /opt/hadoop/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.6.5.jar pi 4 1000

参数含义是启动 4 个 map 任务，每个任务计算 1000 次采样，输出一个接近 3.14 的结果说明 YARN 和 MapReduce 框架整体正常。如果这个作业在map 0% reduce 0%卡了超过两分钟，检查/data/hadoop/logs里 user 目录下是否有容器溢出日志，常见原因是上一节提到的虚拟内存限制问题。这套体检流程看着简单，却能挡住 90% 的日常故障。从那以后，我每次拿到任何一份 Hadoop 发行包，都会强制走一遍这套命令再放行，省下的排障时间足以值回票价。希望帮到你。

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