企业官网建设流程全解析

1. 项目概述与选型剖析

Hadoop 2.7.3 是我在生产环境里真正用起来的一个版本，也是让我把分布式存储和计算调度这件事彻底想明白的关键一版。它不算新，稳定性和生态兼容性却非常能打，很多公司的离线数仓、课程设计、面试场景都还在拿它做基准。这篇文章把我从零部署一套三节点全分布式集群的全过程、踩过的坑，以及环境变量和 JVM 堆参数到底怎么调才不会翻车，一次性整理成一份可以直接照着做的清单。

很多人一上来就照着官网文档复制粘贴，结果不是 DataNode 起不来，就是 YARN 调度器卡在等待 container。根本原因不是命令敲错，而是对配置文件之间的耦合关系没理解。部署 Hadoop 集群其实只有三件事：把机器之间的信任关系弄好、把 XML 配置文件里的角色和通信地址写对、把启动过程产生的隐患提前排除。我下面按这个顺序来拆，每步都会解释参数背后的逻辑，不是让你“照抄”，而是让你知道为什么这么写。

1.1 为什么选 2.7.3：版本选择的底层逻辑

先说说版本选型。Hadoop 2.7.3 属于 Apache Hadoop 2.x 系列中非常成熟的发行版，发布于 2016 年，但生命力远超很多人预期。2.x 最大的标志是把 YARN 作为统一资源调度层独立出来，MapReduce 变成跑在 YARN 上的一个计算框架，这让多框架共存成为可能。2.7.3 在这条演进线上处于“该有的都有、多余的坑不多”的位置：HDFS HA 支持、YARN 联邦调度、NameNode 可扩展接口都已经具备，但又没有 3.x 那种把 NameNode 默认端口从 50070 改成 9870、引入纠删码和基于 Router 的联邦这样的激进变化。

为什么不是 3.x？如果你跑的是 Hive 2.x 或者 Spark 1.6/2.2 这类配套生态，2.7.3 的兼容性最稳。很多教材和培训机构至今用 2.7.x 做标准教学环境，网上问题答案也多，遇到报错基本能搜到前辈的解决方案。生产环境选型讲究“稳”字当头，2.7.3 的 CHD 发行版（比如 CDH 5.x 内部就是基于 2.6/2.7 的）被大量企业用了很多年，踩坑成本已经摊得很薄。如果你是想学技术原理、课设演示，或者接手一套老离线数仓，这个版本是最不容易出幺蛾子的。

1.2 集群角色分配与硬件规划

我这次用的是三台物理虚拟机，部署规划见下表，这个规模也适合大多数课程设计和中等测试环境。

有人习惯把 SecondaryNameNode 单独放到第三台机器，只留一台 DataNode，但那样既不经济，也没必要。SecondaryNameNode 并不是 NameNode 的热备，它的职责是定期合并 EditLog 和 FsImage 到检查点，本身内存压力不大，放在 master 上完全没问题。真正要重视的是 NameNode 和 ResourceManager 这两个“大脑”不能和 DataNode 挤在一起，否则 JVM 堆内存互相争抢，调度一高就出现 full GC。数据盘千万别放在根分区，NameNode 的元数据目录和 DataNode 的块存储目录一定要用独立挂载点，这是我在排障时经常看到同事踩翻车的地方。

2. 部署前的系统准备与基础环境

很多新手以为 Hadoop 部署的难点在 XML 配置，我的经验恰恰相反，最耗时间的往往是系统层的准备工作。JDK 环境变量的坑、SSH 免密登录的权限坑、防火墙没关导致的端口不通坑，这三个坑不排掉，后面启动集群时你会看到一堆莫名其妙而且互相矛盾的错误。

2.1 JDK 与 JAVA_HOME：部署前最容易被忽略的一关

Hadoop 2.7.3 官方要求 JDK 7 或 JDK 8，实操中我建议直接上 JDK 8，因为 Hive、Spark、HBase 这些下游组件对 JDK 8 的兼容性更好。安装方式很简单，CentOS 7 环境下用 OpenJDK 就能跑，或者你也可以手动解压 Oracle JDK 到/usr/local/jdk1.8.0_211这样的目录。装完不要急着关终端，先把环境变量写对。

# 编辑 /etc/profile，在文件末尾追加 export JAVA_HOME=/usr/local/jdk1.8.0_211 export PATH=$PATH:$JAVA_HOME/bin export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar # 生效并验证 source /etc/profile java -version

这里有个经常误导新人的地方：你可能会在~/.bashrc和/etc/profile各写一遍，当某个脚本用非交互式 shell 执行时，~/.bashrc里的变量可能根本没加载，于是 Hadoop 启动脚本报“JAVA_HOME is not set”。最稳妥的做法是把 JAVA_HOME 统一写在/etc/profile里，同时把hadoop-env.sh中的 JAVA_HOME 改成硬编码路径，两处一致，任何启动方式都不会翻车。还有个细节：如果你用的是某些精简版 Linux，系统可能自带了jre但没有javac，java -version能通过，但后续编译类工具或扩展源码时会突然失败，所以装完之后顺手跑一下javac -version，确认完整 JDK 而不是只有 JRE。

2.2 SSH 免密登录配置与权限坑

Hadoop 的启动脚本是通过 SSH 远程到各个节点启动守护进程的，这一步不做免密，后面 start-dfs.sh 会逐台弹密码，相当痛苦。配置流程不复杂，但权限非常讲究，我见过无数人卡在这里。下面这套命令以 hadoop 用户执行：

# 在所有节点生成密钥对，一路回车即可 ssh-keygen -t rsa -b 4096 # 在 master 上把公钥分发到各节点 ssh-copy-id hadoop@hadoop-master ssh-copy-id hadoop@hadoop-node1 ssh-copy-id hadoop@hadoop-node2 # 测试免密登录，如果能直接进 shell 就说明成功 ssh hadoop-node1 hostname

如果你发现明明执行了 ssh-copy-id，但还是弹密码，先检查三处权限：~/.ssh目录必须是 700，~/.ssh/authorized_keys文件必须是 600，~/.ssh目录的所有者必须是你当前登录用户，不能是 root。Linux 对 SSH 密钥权限非常敏感，权限过宽时服务端会直接拒绝使用这个文件，而且日志里不一定给出明显提示。另外注意 host key 冲突：如果之前重装过系统，或者主机名对应的 IP 变更过，SSH 会提示 REMOTE HOST IDENTIFICATION HAS CHANGED，这种时候别傻乎乎反复尝试，直接编辑~/.ssh/known_hosts删掉对应 IP 那行，再重新连接就行。

2.3 hosts 映射与防火墙处理

Hadoop 节点之间通过主机名互相通信，所以每台机器的/etc/hosts都必须包含全部节点的映射，这个文件错一处，节点之间就找不到对方。我在每台机器上统一写入以下内容：

192.168.56.101 hadoop-master 192.168.56.102 hadoop-node1 192.168.56.103 hadoop-node2

然后使用ping hadoop-node1这类命令逐一验证。这里要特别注意：主机名千万不要带下划线，Hadoop 内部有些组件解析主机名时对特殊字符处理不友好，我就见过主机名带_导致 NameNode 间 RPC 通信失败的案例，老老实实用短横线或纯字母最安全。防火墙方面，学习环境图省事可以直接关闭 firewalld 和 SELinux，命令是systemctl stop firewalld && systemctl setenforce 0。但如果是公司环境，不建议全局关闭，而是放行以下端口：8020（HDFS RPC）、50070（NameNode Web UI）、8088（ResourceManager Web UI）、19888（JobHistory Web UI）、50090（SecondaryNameNode Web UI）。只对这些服务端口做白名单，既不影响功能，又守住安全底线。

3. Hadoop 2.7.3 核心配置逐项细讲

接下来就是重头戏，$HADOOP_HOME/etc/hadoop目录下的几个 XML 文件。很多教程喜欢把每个文件完整贴一遍，但我更想解释每个属性为什么存在、不设置会怎样、改了之后影响范围是什么。把这些逻辑搞通，你就是换一台机器换个版本也知道怎么下手。

3.1 core-site.xml：文件系统入口与临时目录

core-site.xml 是 Hadoop 全局配置，最重要的两个属性是fs.defaultFS和hadoop.tmp.dir。fs.defaultFS决定了客户端访问 HDFS 时的默认地址，也就是 NameNode 的 RPC 通信地址；hadoop.tmp.dir则是 HDFS 元数据、NameNode 和 DataNode 的工作目录的默认父目录，这个值如果不动，默认落在系统/tmp下，而/tmp经常被系统清理，机器一重启你的集群元数据就全没了。

<property> <name>fs.defaultFS</name> <value>hdfs://hadoop-master:8020</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/data/hadoop/tmp</value> </property> <property> <name>io.file.buffer.size</name> <value>131072</value> </property>

这里端口我写的是 8020，也有人写 9000，两者都常见，关键是一致。fs.defaultFS写 9000 的话，后面 hdfs-site.xml 里的 NameNode RPC 地址相关配置也要配套。hadoop.tmp.dir配好后，NameNode 名字目录默认会成为/data/hadoop/tmp/dfs/name，DataNode 数据目录默认成为/data/hadoop/tmp/dfs/data。我建议在创建目录时就用mkdir -p /data/hadoop/tmp && chown -R hadoop:hadoop /data/hadoop，让 Hadoop 用户对这个路径有完整控制权，避免启动时因权限不足目录创建失败。io.file.buffer.size是读写文件的缓冲区大小，默认 4096 太小，128KB 比较均衡，对大文件读写性能和 HDFS 的吞吐量都有直接改善。

3.2 hdfs-site.xml：副本数、NameNode 与 DataNode 目录

hdfs-site.xml 管理 HDFS 的核心行为。这里最需要认真对待的是三个目录配置和副本数。dfs.namenode.name.dir是 NameNode 存放元数据（EditLog 和 FsImage）的路径，dfs.datanode.data.dir是 DataNode 存放数据块的实际路径。这两条路径在生产环境里千万不能混用，元数据盘坏了影响的是整个集群的文件索引，数据盘坏了影响的只是部分块，两者的灾备级别完全不同。

<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> <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.namenode.secondary.http-address</name> <value>hadoop-master:50090</value> </property> <property> <name>dfs.permissions.enabled</name> <value>false</value> </property>

关于dfs.replication：三节点环境我建议设成 2，既保证数据有一定冗余，又能让写入速度不受太大影响。设成 3 在三节点上确实每个块都能写满三副本，但写数据时需要一个接一个地确认副本落盘，写入延迟会变大，对小集群得不偿失。这里有个常见的报错“There are X datanode(s) running and none are excluded in this operation”，原因是你的副本数大于实际活动的 DataNode 数，所以副本数量一定要小于等于 DataNode 总数。另外，dfs.permissions.enabled在测试环境设成 false 可以省掉一堆文件权限上的麻烦，但生产环境不能省，否则等于把 HDFS 的安全门完全敞开。

3.3 yarn-site.xml：资源调度与容器内存

YARN 是资源调度层，yarn-site.xml 里配置的是 ResourceManager 怎么管理整个集群的资源、NodeManager 能为容器提供多少内存和 CPU。我第一次部署时就在这栽了跟头：总以为 ResourceManager 的地址会自动识别，结果 job 提交后一直卡在 ACCEPTED 状态，日志里没有任何报错，纯粹是 ResourceManager 联系不上 NodeManager。

<property> <name>yarn.resourcemanager.hostname</name> <value>hadoop-master</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> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>4096</value> </property> <property> <name>yarn.nodemanager.resource.cpu-vcores</name> <value>2</value> </property>

yarn.nodemanager.resource.memory-mb和cpu-vcores这两个参数决定每台 NodeManager 能分配出去的资源总量，并不是说你机器内存多大就写多大，一定要给操作系统预留 20%~30% 的内存。比如机器 8G 内存，你设 8192，容器在内存高水位时会把进程直接挤到 swap，性能骤降甚至 OOM。这里的关键原则是：NodeManager 声明资源的总额必须小于物理机可用的真实内存，我一般按物理内存减 2G 来设。内存单位是 MB，CPU 是虚拟核数，比如机器 4 核 8G，写 6144 和 3 是安全的。如果你配置完成之后 task 反复失败，可以在这里调整，但不要想着一口气把单个 container 内存调得特别大，YARN 的 container 调度是整块分配的，块太大反而浪费。

3.4 mapred-site.xml 与 slaves 文件

mapred-site.xml 在 Hadoop 2.7.3 里默认是不存在的，只有一个模板文件mapred-site.xml.template，你需要先复制一份再编辑，这步漏掉的话后面提交 MapReduce job 时它会报找不到框架。核心配置如下：

cp $HADOOP_HOME/etc/hadoop/mapred-site.xml.template $HADOOP_HOME/etc/hadoop/mapred-site.xml

<property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> <property> <name>mapreduce.jobhistory.address</name> <value>hadoop-master:10020</value> </property> <property> <name>mapreduce.jobhistory.webapp.address</name> <value>hadoop-master:19888</value> </property>

mapreduce.framework.name必须写 yarn，这样 MapReduce 任务才会提交到 YARN 上调度，而不是以本地模式运行。如果你发现明明部署了集群，跑 job 时日志却显示“Running job in local mode”，十有八九是这个配置没设置。slaves 文件也很容易出错：这个文件名在 2.7.3 里就叫slaves，不是 3.x 的workers，里面每行写一个 DataNode 主机名。

hadoop-node1 hadoop-node2

注意文件末尾不要有多余的空行、空格，Windows 下编辑过的文件可能出现 CRLF 换行符，可能导致脚本解析主机名时带上\r导致连不上，最好用 Linux 的dos2unix转一下格式，或者直接在 Linux 上用 vim 重新录入一遍，这个坑虽然低概率，但踩到一次就够你排查一晚上。

4. 启动集群与验证部署

配置写完不等于集群能跑，启动顺序和验证方法很有讲究。我见过太多人一启动就到处报错，然后不知所措地删数据目录重新格式化，最后把集群搞得更乱。这一节我把正确流程和背后的原理讲清楚。

4.1 格式化 NameNode 的正确姿势与误操作提醒

格式化 NameNode 是把 NameNode 的元数据初始化出来的关键动作，但这个动作有严格的次数限制。正确命令是在 master 上执行：

hdfs namenode -format

执行成功后你会看到Storage directory /data/hadoop/name has been successfully formatted。这时 NameNode 相关的目录里会生成current/VERSION文件，里面记录了clusterID。重要提醒：格式化只应该在首次部署或者你明确要重置整个集群时执行一次，之后日常运维不要重复执行。因为格式化只会清空并重建 NameNode 的元数据，但 DataNode 已经用旧的clusterID完成了注册；当 NameNode 和 DataNode 的clusterID不一致时，DataNode 启动后会自动退出，并在日志里输出类似的报错：

Incompatible clusterIDs in /data/hadoop/data: namenode clusterID = CID-xxx; datanode clusterID = CID-yyy

网上很多教程遇到这种问题就让你把 DataNode 数据目录删掉再重启，这是可行的，但一定要先想清楚：删除 DataNode 目录等于放弃该节点上所有数据块，在测试环境无所谓，生产环境绝对不能这么干。正确的修复思路是看 VERSION 文件里的 clusterID 是否两边一致，有差异再考虑处理。格式化前还要确认/data/hadoop/name目录本身不存在历史残留，否则可能报目录已存在，手动清空时可以这样：

rm -rf /data/hadoop/name/*

但千万别手贱删掉/data/hadoop/data/*，除非你确认这个节点就是初始化状态。

4.2 启动顺序与 jps 检查

格式化完成后，按顺序启动各组件脚本：

start-dfs.sh start-yarn.sh

通常 master 上会先起 NameNode 和 SecondaryNameNode，然后脚本 SSH 到 slaves 列出的节点启动 DataNode；start-yarn.sh 则会启动 ResourceManager 和各节点的 NodeManager。启动后第一步用jps检查各节点的 Java 进程，这是最直观的故障定位手段。正常状态应该是：

如果发现某个节点缺了 DataNode，不要一上来就想重启集群，先执行tail -100 $HADOOP_HOME/logs/hadoop-hadoop-datanode-*.log看日志。如果 master 上jps直接没有 Java 进程，大概率是JAVA_HOME没配好，或者是脚本执行时走的用户不对，可以用which java和echo $JAVA_HOME先自检。这里的坑在于：很多人在 hadoop 用户下配好了环境变量，但用 root 执行 start-dfs.sh，脚本里如果通过 su 切换或 SSH 到别的节点，环境变量未必能带过去，所以整套集群的所有操作最好固定统一用户。

4.3 Web UI 与 HDFS 基础操作验证

进程都在了，不代表集群真的健康，还要通过 Web UI 和实际文件操作做双重验证。Hadoop 2.7.3 的 NameNode Web UI 默认地址是http://hadoop-master:50070/dfshealth.html#tab-overview，打开后能看到集群的资源概况和 DataNode 列表。ResourceManager 的 UI 在http://hadoop-master:8088/cluster/nodes，这里能看到每个 NodeManager 报告的资源总量，如果 Nodes 页面的资源数值和你/etc/hosts里规划的机器配置对不上，说明 yarn-site.xml 里的内存参数没生效。再用命令行验证 HDFS 是否真的可用：

hdfs dfs -mkdir -p /test/input hdfs dfs -put /etc/hosts /test/input/ hdfs dfs -ls /test/input hdfs dfsadmin -report

dfsadmin -report会列出每个 DataNode 的容量、剩余空间和块数量，如果这里显示 Datanodes available 只有 1 或者 0，说明有的节点没真正注册成功，赶紧回 4.2 去查日志。顺便提一句，50070 这个端口在 Hadoop 3.x 里已经改成 9870，所以网上搜到的新版本文章里端口对不上时，别慌，先确认版本再调整访问地址。

5. 环境变量与性能调优实战

很多部署教程在“能启动”之后就戛然而止，但实际生产环境里，从“能跑”到“跑得稳、跑得快”之间还有一段调优的路。Hadoop 调优可以从三层来理解：JVM 堆参数调优、操作系统层参数调优、HDFS/YARN 业务参数调优。三层都处理好，集群才算真正可用。

5.1 hadoop-env.sh 的 JAVA_HOME 与 JVM 堆参数

$HADOOP_HOME/etc/hadoop/hadoop-env.sh是 Hadoop 启动脚本统一读取的环境文件，也是调优的第一站。先说 JAVA_HOME，我强烈建议在这里直接写死绝对路径，不要留${JAVA_HOME}。因为 start-dfs.sh 在执行时涉及 SSH 到远程节点，远程节点的非交互 shell 里不一定能加载你 /etc/profile 里的变量，写死是最稳的：

export JAVA_HOME=/usr/local/jdk1.8.0_211

接下来是 JVM 堆内存。Hadoop 2.7.3 默认堆内存上限是 1000MB，对 NameNode 这种角色来说太抠了。NameNode 的元数据都在内存里，文件数量一多，1000MB 很快告急。调优时不要改全局的 HADOOP_HEAPSIZE，而是针对守护进程分别设置，这样才能按角色分配资源：

export HADOOP_HEAPSIZE=4096 export HADOOP_NAMENODE_OPTS="-Xmx4096m -Xms4096m -Djava.net.preferIPv4Stack=true" export HADOOP_DATANODE_OPTS="-Xmx2048m -Djava.net.preferIPv4Stack=true" export YARN_RESOURCEMANAGER_OPTS="-Xmx4096m" export YARN_NODEMANAGER_OPTS="-Xmx2048m"

堆内存设置的逻辑是：NameNode 给 4G，DataNode 给 2G，节点内存 8G 左右比较合适。注意-Xms和-Xmx设成相同值，避免 JVM 在运行过程中发生堆扩容，堆扩容时会触发 stop-the-world 停顿，在高并发场景下影响非常明显。还有个小坑：这里设置 JVM 参数时，如果你重复设置了HADOOP_NAMENODE_OPTS字段，脚本里可能会把默认参数和自定义参数拼接在一起，导致参数冲突，最好先注释掉原文件里的这部分，再统一追加。

5.2 系统级参数：文件描述符、交换分区与网络

Hadoop 集群的每个 DataNode 要同时管理大量 HDFS 数据块连接和 MapReduce task 的 socket 连接，文件描述符很容易耗尽。默认系统限制 1024，对这个场景完全不够用。修改/etc/security/limits.conf：

hadoop soft nofile 65535 hadoop hard nofile 65535 hadoop soft nproc 65535 hadoop hard nproc 65535

修改后重新登录，用ulimit -n验证。文件描述符不足时，你会发现进程明明存在，但日志里疯狂报Too many open files，而且在 HDFS 客户端写入大文件时也会突然中断，这属于典型的隐藏雷，不提前排掉后面很难定位。还有一个系统参数是vm.swappiness，Linux 默认 30 表示内存使用到 70% 左右就可能开始换页，Hadoop 这种内存型任务集群会把内存用到很满，在这个机制下很容易把进程的关键内存页换到 swap 上，导致任务突然变慢。建议调低：

sysctl vm.swappiness=10 echo "vm.swappiness=10" >> /etc/sysctl.conf

10 表示系统只有在内存相当紧张时才适量换页，对守护进程长期运行的稳定性非常有帮助。网络层面不要随意调 TCP 缓冲区，默认值在千兆网卡下够用，真正该做的是确保集群内部是千兆以上内网，跨公网部署会非常痛苦。

5.3 HDFS 与 MapReduce 侧调优经验

业务层的调优不追求一次到位，但要理解参数之间会联动。比如 HDFS 默认 block 大小是 128MB，如果你的文件普遍是几百 MB 到 GB 级，保持默认就挺好；但如果大量小文件，block 调大反而浪费。可以在 hdfs-site.xml 里显式声明：

<property> <name>dfs.blocksize</name> <value>134217728</value> </property>

134217728就是 128MB 的字节数，如果你后续要跑 Spark 读取 HDFS，block 大小也直接影响分区数量，所以这个值要配套你上层的计算框架来设计。MapReduce 侧一个非常关键的参数组合是mapreduce.map.memory.mb、mapreduce.reduce.memory.mb与yarn.nodemanager.resource.memory-mb的配套关系。比如你给 NodeManager 声明 4096MB，那单个 map 容器最多也就几百 MB 到 1G，因为 NodeManager 要给多个容器同时分配。如果 map 内存配置大于 NodeManager 可用总量，任务会在提交阶段直接失败，日志提示“Resource is not enough”。我常用的配置经验是单台 8G 内存的节点，给每个 map 容器 1024MB，reduce 容器 1536MB，这样最多同时跑三四个任务，不容易把节点打满。

<property> <name>mapreduce.map.memory.mb</name> <value>1024</value> </property> <property> <name>mapreduce.reduce.memory.mb</name> <value>1536</value> </property> <property> <name>mapreduce.map.java.opts</name> <value>-Xmx819m</value> </property> <property> <name>mapreduce.reduce.java.opts</name> <value>-Xmx1228m</value> </property>

这里有个很多人不知道的细节：mapreduce.map.memory.mb是容器总内存，而mapreduce.map.java.opts是 JVM 堆内存，JVM 堆必须比容器总内存小一截，因为堆外还有 metaspace、线程栈和系统内存开销，一般按 80% 比例来写，比如上面 1024MB 对应 819MB，留出约 20% 冗余给堆外。只调前者不调后者，任务还是会在堆外内存耗尽时被 YARN kill 掉。

6. 踩坑实录与排查技巧

最后这部分是我最想分享的，可以说都是真金白银换来的经验。我不会把所有错误都列一遍，只挑高频且最坑人的几种，外加我自己的一套排错思路，你遇到问题时按照这个思路一步步来，会比漫无目的地翻日志高效得多。

6.1 典型错误速查表

每个错误的修复操作我都标出了场景限制，尤其是“清空 DataNode 数据目录”这种操作，在测试环境可以大胆做，生产环境务必先确认当前节点的角色和数据价值，最好在维护窗口内操作。

6.2 我的惯用排查命令与思路

排错最关键的是建立稳定的排查路径。我的顺序基本是：先确认进程在不在，再看日志有没有明显异常，最后用状态命令确认资源视图。jps前面说过，是第一步；hdfs dfsadmin -report是第二步，专门看集群整体视图；yarn node -list -all是第三步，看调度资源状态。日志文件的落点要先找准：在 2.7.3 里，如果没有单独配置HADOOP_LOG_DIR，日志默认输出到$HADOOP_HOME/logs/，目录下会按角色命名，比如hadoop-hadoop-datanode-hadoop-node1.log，启动报错的现场就在这个文件的末尾。我强烈建议你把下面这个命令刻进记忆里：

tail -100 $HADOOP_HOME/logs/hadoop-hadoop-datanode-*.log

实际排查时，日志末尾的关键词最管用，比如Exception、FATAL、ERROR，不要从头到尾读，直接grep -E "ERROR|FATAL|Exception" -A 20，上下文连同异常栈一起看。很多时候光看错误信息不够，比如出现java.net.ConnectException: Connection refused，这是最典型的“目标服务没监听”，原因可能在防火墙、进程没起、端口写错、或者访问的是内网 IP 但服务只绑定了 127.0.0.1 这四个方向，逐一确认就好。如果改了配置但看不出效果，要记住 Hadoop 2.7.3 的配置修改后大部分需要重启对应角色才能生效，不是像某些应用一样热加载。

说到最后，我给你留一个个人觉得最有用的经验：第一次部署千万别一上来就追求“一次成功”。我做了这么多项目，真正高效的路径是先在一台机器上把伪分布式模式跑通，理解了每个 XML 对应什么角色、每个端口对应什么服务，再扩展到三节点。伪分布式能帮你把 HDFS 和 YARN 的关系、启动日志的阅读方式、基础命令的用法全部跑熟，这些基本功没打牢，直接上全分布式，任何一个小问题都会放大成集群级事故。先把环境变量、目录路径、日志位置这三样刻进脑子里，再谈调优。这套 2.7.3 集群我后来跑了两年多没出过大毛病，希望你按这套流程部署完，也能一次到位、长期稳定。