简介：面向Hadoop运维初学者及1+X大数据平台运维考证人群，这份PDF实验指导系统梳理了Hadoop集群运行阶段必须掌握的核心操作。文档共1个PDF文件，大小仅1.33MB，内容涵盖从集群格式化配置、运行状态查看、HDFS报告与节点监控，到安全停止集群的完整流程。已有204人学习浏览，适合在CentOS 7.4、三节点以上互通的实验环境中边看边练。文档以实验任务一“hadoop集群运行”为主线，先介绍实验目的与环境要求（双核CPU、8GB内存、100G硬盘），再分步演示NameNode/DataNode格式化命令（bin/hdfs namenode -format）、启动与查看Java进程（hadoop-daemon.sh start namenode、jps）、查看HDFS报告与节点状态（hdfs dfsadmin -report）、浏览器访问查看节点状态以及执行stop-all.sh停止集群。特别强调了首次启动HDFS才需格式化、重复格式化前必须删除/usr/local/src/hadoop/tmp工作目录数据等易错细节，能帮助读者快速上手Hadoop集群日常运维与故障排查，具有很高的实践参考价值。
1. Hadoop集群运行：这份资料解决的实际问题
Hadoop 集群运行，是整个学习路线里第一道需要实打实动手的关卡。前几章你可能已经能对着单机环境把 HDFS 读写流程、MapReduce 执行机制说得头头是道，但真正把几台机器组在一起，让数据分散存储、作业分布计算，配置文件里每一个参数、进程日志里每一条报错，都会变成拦路石。这份以《第5章 Hadoop集群运行》为核心主题的学习资料，覆盖的正是从「单机改配置」到「多机跑通」之间最难熬的衔接段：集群组建前要准备什么、配置文件怎么改、启动命令按什么顺序执行、跑挂了怎么判断是哪一环出了问题。内容适合正在搭实验集群的入门者，也适合准备生产部署前先把运行机制理顺的开发与运维人员，我按实际动手的经验把这一章拆成可直接照做的操作链。
2. 先认清角色再动手：集群运行的架构前提与选型
2.1 主从架构里的六个关键进程
Hadoop 集群运行的底层逻辑是主从架构，HDFS 和 YARN 各有一主一从，再加上辅助角色，一共六个核心进程需要你全部认识。
NameNode 是 HDFS 的主节点，负责维护文件系统的命名空间和文件到数据块的映射关系，所有文件的元数据都在它内存里，它挂了整个文件系统就进入只读或不可用状态。DataNode 是 HDFS 的从节点，真正把数据块落盘，每个 DataNode 会周期性向 NameNode 发送块报告，说自己手里有哪些块的副本。SecondaryNameNode 是很多初学者的认知盲区，它不接收客户端请求，也不是备机，它的职责是定期拉取 NameNode 的 fsimage 和 edits 日志，合并成新的 fsimage 再传回去，作用是缩短 NameNode 重启时回放日志的时间。可以理解为给 NameNode 做定期「记忆整理」的辅助角色。
YARN 这边，ResourceManager 负责全局资源管理与作业调度，是所有作业申请资源的唯一入口。NodeManager 是每台机器上的资源管家，管理本机容器和内存CPU，定时向 ResourceManager 心跳汇报。ApplicationMaster 是作业级别的调度员，每个 MapReduce 作业提交后都会先拉起一个 AM，由它向 ResourceManager 申请执行 Map 和 Reduce 的容器，并协调整个作业的生命周期。
很多教程把这六个进程列出来就结束了，但实际排错时你要清楚它们之间的通信关系：DataNode 启动时根据 core-site.xml 里的 fs.defaultFS 找到 NameNode 的地址去注册；NodeManager 根据 yarn-site.xml 里的 yarn.resourcemanager.hostname 找到 ResourceManager 去注册。如果把配置文件理解成「进程之间互相找到对方的通讯录」，再去看启动顺序和日志报错，思路会清晰很多。
2.2 部署模式选择：伪分布式、多节点集群怎么取舍
常见做法是把 Hadoop 部署分成三种模式，很多教材把它们叫本地模式、伪分布式和完全分布式。本地模式下不需要额外进程，MapReduce 作业直接在同一个 JVM 里跑，适合纯调试代码逻辑；伪分布式在一台机器上同时启动六个进程，能完整体验 HDFS 写入和 YARN 调度流程；完全分布式才是「集群运行」这个词的真正指向，多个节点协同工作。
我当初跳过了伪分布式直接搭多节点，结果踩了一串坑，后来回头把伪分布式跑通，才发现它能在半小时内提前暴露掉一半的问题。原因是伪分布式和完全分布式读同一套配置文件，参数含义完全一致，但前者只需要排查一台机器，日志集中，出问题的定位成本低得多。这里给一个明确的选择建议：如果只是学 MapReduce 编程，本地模式足够；如果目标是熟悉 HDFS 写流程和 YARN 调度行为，伪分布式性价比最高；如果模拟真实部署、要观察数据块在机器间的分布，至少准备三台机器，一台做主节点跑 NameNode 和 ResourceManager，两台做从节点跑 DataNode 和 NodeManager。
多节点集群里角色是否混布也是一个常见疑问。实验环境为了省资源，主节点上同时跑 DataNode 完全可行；但生产环境的规范做法是主节点只跑管理角色，不存数据块，道理很简单：主节点内存和磁盘压力本来就大，再参与数据存储会让故障时恢复成本更高。实验阶段不用纠结，按资源情况来就行。
2.3 集群运行前的系统准备：内存、磁盘与用户
集群组建前最容易被忽视的是系统级准备，这一步没做好，后面配置再正确也会在各种诡异的地方翻车。
内存方面，每个 Java 进程都会占用一定堆内存，实验环境下六到八个进程挤在一台 2G 内存的机器上，启动到一半就能看到进程被系统杀掉，日志里没有明显报错，只留下一条 OOM 记录。我一般建议主节点至少 4G 内存，从节点至少 2G，如果受限于机器条件，就把 yarn.nodemanager.resource.memory-mb 调小，同时用 HADOOP_HEAPSIZE 这类环境变量控制各进程的堆大小。
磁盘方面，NameNode 和 DataNode 的数据目录不要放在系统根分区，因为集群跑起来之后块数据和日志增长很快，把系统盘写满会导致整个操作系统异常。推荐把数据目录指到独立的数据盘或者空间充足的分区，这个决策要在第一次格式化之前就做掉，因为格式化后数据目录位置如果变了，迁移成本很高。
用户方面，不要用 root 直接跑集群。实验环境里很多人图省事用 root，但一旦形成习惯，后续磁盘权限、文件属主这类问题会被 root 权限直接掩盖，生产环境会付出代价。创建专用用户，比如 hdfs 或者 hadoop 用户，所有进程都用这个用户启动，日志和数据文件的属主才能保持统一。另外，集群内所有节点的主机名解析必须在启动前搞定，/etc/hosts 里要把每台机器的 IP 和主机名对应写清楚，SSH 免密通信也要配置到位，否则 start-dfs.sh 远程拉起从节点进程时会直接失败，而且报错信息很容易误导人。
3. 配置文件逐项落地：core-site、hdfs-site、yarn-site 的关键参数
3.1 core-site.xml：先定文件系统入口
core-site.xml 是每个进程都会读取的全局配置，最核心的两个参数是 fs.defaultFS 和 hadoop.tmp.dir。
<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://hadoop-master:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/data/hadoop/tmp</value> </property> </configuration>fs.defaultFS 定义整个集群的默认文件系统地址，客户端的 hdfs dfs 命令和 MapReduce 作业读写 HDFS 时，默认连的就是这个地址。hadoop-master 是主节点的主机名，9000 是 NameNode 默认的 RPC 通信端口，这个端口要保证集群内所有节点都能访问。hadoop.tmp.dir 是运行时临时文件根目录，如果不在 hdfs-site.xml 里显式指定 NameNode 和 DataNode 的数据目录，元数据和数据块就会默认落在这个临时目录下面。
这里值得反复提醒的是：hadoop.tmp.dir 的默认值指向 /tmp/hadoop-${user.name}，而很多 Linux 发行版会定期清理 /tmp 目录，或者系统重启后清空，一旦元数据被清掉，整个 HDFS 相当于被推倒重来。我习惯的做法是无论实验还是生产，都在 hdfs-site.xml 里显式配置数据目录，绝不依赖默认临时路径，这一点几乎没有例外。
3.2 hdfs-site.xml：副本数、数据目录与块大小
hdfs-site.xml 控制 HDFS 自身的存储行为，以下四个参数是集群运行前必须想清楚的。
<configuration> <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>file:///data/hadoop/hdfs/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:///data/hadoop/hdfs/datanode</value> </property> <property> <name>dfs.blocksize</name> <value>134217728</value> </property> </configuration>dfs.replication 决定每个数据块保存几个副本，默认是 3，但实验环境三节点集群如果副本数设 3，任何一台节点宕机集群就写不进新数据，磁盘占用也高。我一般建议三节点实验集群设置为 2，既保留容错能力，又给磁盘留出余量。这个参数修改后只对后续写入的文件生效，已经写入的数据块副本数不会自动增减，需要手动触发调整。
dfs.namenode.name.dir 和 dfs.datanode.data.dir 分别指向元数据目录和数据块目录，注意两个细节：一是路径前的 file:// 前缀表示这是本地文件系统路径，不要漏掉；二是这两级目录在格式化前必须手动创建，格式化命令不会帮你建目录，目录不存在会直接报错退出。dfs.blocksize 默认 134217728 字节即 128MB，这是生产环境的标准块大小。实验环境如果想更快观察多节点数据分布，可以临时调小到 64MB，但要意识到这个参数一旦文件写入后就不会再变，运行中修改只影响新文件。
还有一个容易被忽略的参数是 dfs.namenode.handler.count，它控制 NameNode 处理 RPC 请求的线程数。节点数量超过 30 时，默认值 10 会成为瓶颈，需要按节点规模调大，实验环境不用动它。这个参数属于「平时没感觉，节点多起来就卡」的类型。
3.3 yarn-site.xml：资源调度与容器上限
YARN 是真正执行作业的调度平台，yarn-site.xml 里最容易出问题的就是资源相关参数，配置不当会直接导致作业提交后一直排队。
<configuration> <property> <name>yarn.resourcemanager.hostname</name> <value>hadoop-master</value> </property> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>8192</value> </property> <property> <name>yarn.nodemanager.resource.cpu-vcores</name> <value>4</value> </property> <property> <name>yarn.scheduler.minimum-allocation-mb</name> <value>512</value> </property> <property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>4096</value> </property> </configuration>yarn.resourcemanager.hostname 告诉所有 NodeManager 向哪台机器的 ResourceManager 注册，这个参数配错的话，从节点会一直在日志里反复打印连接失败的记录，而你在主节点上看到 ResourceManager 正常启动，很容易被误导成集群没问题。
yarn.nodemanager.resource.memory-mb 是单台 NodeManager 能提供给 YARN 的总内存，这个值必须小于节点的物理内存，要预留出操作系统、DataNode 进程、NodeManager 自身进程的空间。一台 8G 内存的机器配 6G 是合理的，配 8G 反而会因为系统内存不足触发内核把 NodeManager 进程杀死，表现为节点状态在 RUNNING 和 LOST 之间反复横跳。cpu-vcores 同理，不要超过逻辑核数。
yarn.scheduler.minimum-allocation-mb 和 maximum-allocation-mb 定义了单个容器的申请范围。最小申请值设得越小，资源切分越细，调度越灵活但开销越大；最大值太大，单个容器可能占满整台节点。实际运行时，MapReduce 作业的 mapreduce.map.memory.mb 配置如果超过 maximum-allocation-mb，作业会在申请阶段直接报错，提示容器内存超限，这个错误信息指向明确，优先检查两端参数的匹配关系即可。
3.4 配置同步与进程环境：别忘 hadoop-env.sh
配置文件在主机上改好后，必须同步到集群里每一台机器。常见做法是用 scp 分发配置文件目录：
scp -r /opt/hadoop/etc/hadoop/ hadoop-node1:/opt/hadoop/etc/hadoop/ scp -r /opt/hadoop/etc/hadoop/ hadoop-node2:/opt/hadoop/etc/hadoop/这里需要注意，分发时只覆盖配置目录，不要整个 Hadoop 安装目录一起拷贝，因为各节点机器的本地路径可能不同，比如数据盘挂载点不一样，目录结构有差异，整目录覆盖会把差分化配置一起抹掉。
还有一个不起眼但很关键的文件是 hadoop-env.sh，里面需要显式设置 JAVA_HOME。虽然安装程序可能已经写入了默认值，但多节点场景下，SSH 远程拉起进程时的用户环境变量和你在终端里手工执行的并不一致，JAVA_HOME 拿不到或者拿错，进程启动就会失败，日志里只留一句找不到 Java 环境的提示。我一般会在 hadoop-env.sh 里写死 Java 安装路径的绝对路径，这在多节点环境里能减少大量因为环境差异导致的玄学问题。配置同步完成后，随手在每台从节点上 grep 检查一遍关键参数是否和主节点一致，这个动作能省下后面排错的无数时间，因为我就遇到过从节点上的配置文件是旧版本，DataNode 注册到了错误地址，客户端读写超时问题排查了一整天才定位到。
4. 从格式化到跑通作业：集群启动的完整命令链
4.1 首次启动前的格式化操作
集群第一次运行时，NameNode 的元数据目录是空的，必须执行格式化才能生成初始的元数据镜像，这一步是整个集群运行里最需要谨慎对待的操作。
# 确认数据目录存在且属主正确 mkdir -p /data/hadoop/hdfs/namenode mkdir -p /data/hadoop/hdfs/datanode chown -R hadoop:hadoop /data/hadoop # 格式化 NameNode hdfs namenode -format格式化前要确认三件事：第一，dfs.namenode.name.dir 指向的目录已经创建，并且当前用户有写权限；第二，这台机器不是一台已经运行过集群的机器，如果目录下已经有 current 目录，数据是真实的用户数据，不能直接格式化；第三，确认所有节点的数据目录路径一致，避免格式化后部分节点找不到目录。
格式化成功的标志是日志末尾出现 successfully formatted 的字样。这里有一条血泪教训：格式化不是后悔药，执行之后元数据目录被重置，之前 HDFS 里的所有文件索引全部丢失。如果配置改了需要重新格式化，必须先把主节点和所有从节点上的 name.dir 与 data.dir 内容全部清空再执行，否则数据目录里残留的 clusterID 和新的不一致，DataNode 会被判定属于不同的集群实例而拒绝注册。Hadoop 3 版本里这种情况的报错通常指向 clusterID 不匹配，解决方法是使用 hdfs namenode -format -clusterID 手动指定统一标识，或者干脆清空原数据目录重新来过。
4.2 启动 HDFS 与 YARN 的正确顺序
集群启动的顺序是有讲究的：先启动 HDFS，再启动 YARN。原因是 YARN 上的作业要依赖 HDFS 作为底层存储，文件系统就绪之前启动资源调度没有意义，还会在日志里刷一堆连接错误。
# 在主节点执行 start-dfs.sh start-yarn.shstart-dfs.sh 会读取 workers 文件（旧版本叫 slaves 文件）里的从节点主机名列表，逐个通过 SSH 远程拉起 DataNode，并在主节点本地启动 NameNode 和 SecondaryNameNode。start-yarn.sh 启动主节点的 ResourceManager 和各从节点的 NodeManager。这两个脚本是批量操作，如果只想单独控制某个进程，用 hdfs --daemon start namenode 或者 yarn --daemon start resourcemanager 这类单进程命令，排错时比全量脚本好用得多。
启动后别急着提交作业，先确认进程是否全部在位。最直接的工具是 jps，只列出当前用户的 Java 进程。主节点上应该能看到 NameNode、SecondaryNameNode、ResourceManager 三个进程，从节点上应该能看到 DataNode 和 NodeManager。这里有个常见误判：用 root 启动了集群，然后切到普通用户执行 jps，什么进程都看不到，以为启动失败，其实是用户视角不同。用同一个用户执行启动和检查，能避免这种假故障。
4.3 验证集群健康状态
进程都在不代表集群是健康的，数据块分布和节点资源注册情况要单独验证。我习惯用三条命令做启动后的例行体检。
# 查看 HDFS 节点状态与块健康 hdfs dfsadmin -report # 查看 YARN 节点的资源注册 yarn node -list # 检查指定路径的数据块与副本分布 hdfs fsck / -files -blocksdfsadmin -report 输出每个 DataNode 的容量、剩余空间、状态，以及整个文件系统的块副本健康汇总，包括 Under replicated blocks 的数量。yarn node -list 列出所有注册的 NodeManager，以及每台的内存、核数、运行状态。fsck 是检查具体数据块分布的利器，能看到每个文件占用了哪些块、每个块有几个副本、副本是否分布在可用的 DataNode 上。
网页监控同样重要。NameNode 的 Web UI 默认端口在 Hadoop 3 版本是 9870，ResourceManager 的 Web UI 默认是 8088。前者展示 HDFS 容量、存活 DataNode 列表和浏览文件目录；后者展示作业列表、资源使用和日志入口。端口访问不通时，优先检查防火墙和主机名解析，这两个环节是拦截最多的原因。Hadoop 集群内部大量使用主机名进行通信，/etc/hosts 配置不全或者配错，日志里只会留下大段超时和连接失败，这是典型的黑匣子式问题。
4.4 提交一个测试作业验证全链路
进程健康检查通过后，用真实的 MapReduce 作业跑一遍全链路是最可靠的收尾。常见做法是先造一个测试文件写入 HDFS，再提交 WordCount 示例作业。
# 准备测试数据 echo "hello hadoop cluster run test" > /tmp/test.txt hdfs dfs -mkdir -p /test/input hdfs dfs -put /tmp/test.txt /test/input/ # 提交 WordCount 作业（示例 JAR 在安装目录 share/hadoop/mapreduce 下） hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \ wordcount /test/input /test/output # 查看结果 hdfs dfs -cat /test/output/part-r-00000提交后去 8088 页面观察作业状态流转，正常路径是 ACCEPTED 到 RUNNING 再到 FINISHED。如果一直卡在 ACCEPTED，说明资源没有分配，回到第 3 章的资源参数去排查。如果作业跑完但报错说输出目录已存在，这是因为 MapReduce 不允许覆盖已有输出，用 hdfs dfs -rm -r /test/output 删除后换个目录名重新提交。
这条验证链路覆盖了 HDFS 写入、YARN 调度、容器启动、MapReduce 执行、结果回读全部环节，任何一环有问题都会暴露出来。我建议把这组命令保存成一个脚本，作为每次集群启动后的例行检查，比单纯看进程列表可靠得多，也比盯着日志文件高效。
5. 集群运行避坑指南：格式化、磁盘、掉线的 5 个典型问题
5.1 重复格式化导致 NameNode 无法启动
现象：集群运行一段时间后，因为配置调整重新执行了 hdfs namenode -format，之后 start-dfs.sh 启动失败，NameNode 日志出现 clusterID 不匹配的报错，所有 DataNode 无法完成注册，集群处于文件系统不可用状态。
原因：格式化会生成新的 clusterID，同时重置元数据目录，而各 DataNode 的数据目录里保留着首次注册时的 clusterID。新的 NameNode 发现自己管理的是旧身份的数据节点，把它们判定为不属于当前文件系统实例，全部拒绝注册，表面上看起来是 DataNode 掉线，实际根因在 NameNode 侧的标识不一致。
解决：如果确认是要重置整个集群，把主节点和所有从节点上 dfs.namenode.name.dir 和 dfs.datanode.data.dir 目录内容全部删除，然后重新格式化再启动。如果想保留原数据，就不要随意格式化，需要先备份元数据目录里的 fsimage。这里的关键动作是格式化前检查 NameNode 数据目录下是否有 current 目录，有就说明文件系统已经初始化过，非重置场景不碰格式化命令。
5.2 HDFS 有剩余空间，作业却写不进去
现象：终端里执行 df -h 显示数据盘还有大量剩余空间，但向 HDFS 写入文件时报磁盘空间不足，或者 DataNode 日志里出现 Disk out of space 的写失败记录。
原因：DataNode 会为系统预留一部分磁盘空间，由 dfs.datanode.du.reserved 控制，默认值是 0，但部分发行版会默认预留 10% 左右。这个预留值在空间计算时被排除在可用容量之外，所以 HDFS 看到的可用空间比系统实际剩余更少。另外，NameNode 是根据各 DataNode 周期汇报的容量来决定写入位置的，如果某个节点汇报延迟或者掉线，客户端写入时可能只看到部分节点的空间，从而提前判定空间不足。
解决：先用 hdfs dfsadmin -report 确认所有 DataNode 的剩余空间和在线状态，排除节点掉线因素。再检查 dfs.datanode.du.reserved 的值，如果设置得过高，调低它可以看到可用空间立刻恢复。但注意不要把这个预留值设成 0，操作系统和日志文件需要空间，否则数据盘写满后系统服务会连环崩，清一次盘的成本远高于预留空间浪费的成本。
5.3 DataNode 掉线后副本数长期不恢复
现象：从节点宕机或磁盘故障后，dfsadmin -report 显示 Under replicated blocks 数量明显增多，节点恢复上线后，副本数长时间保持在不健康状态，迟迟不自动补齐。
原因：HDFS 的副本复制是后台异步进行的，NameNode 要等 DataNode 上报块报告之后，才会把缺失副本的块放入复制队列。如果块报告周期设置过长，或者网络带宽资源受限，复制过程会非常缓慢。另一个隐蔽原因是集群运行后修改过 dfs.replication，NameNode 不会主动删除多余的副本，也不会对低于新配置值的块立即触发补充，界面上的副本数量长期处于异常状态。
解决：先用 hdfs fsck / -files -blocks 定位具体哪些块副本不足。确认掉线节点已恢复且块报告已上报后，耐心等待是常态，正常情况下副本会自动补齐。如果等很久没有动静，可以调整 dfs.namenode.replication.max-streams 和 dfs.namenode.replication.work.multiplier.per.iteration 提高复制并发度。最后的手段是重启 NameNode，重启会强制重新遍历块信息并重建复制队列，对卡住的复制任务有奇效。
5.4 作业提交后一直 ACCEPTED 不进入 RUNNING
现象：MapReduce 作业提交后状态长时间停在 ACCEPTED，8088 页面里看不到容器分配记录，提交命令行也没有明显报错输出。
原因：绝大多数情况是资源匹配失败。要么是 NodeManager 注册的内存总容量小于作业申请的最小容器内存，调度器永远凑不出一个满足条件的容器；要么是 yarn.scheduler.maximum-allocation-mb 设置过小，作业里配置的 mapreduce.map.memory.mb 超过上限，申请被直接拒绝。
解决：去 ResourceManager 的 8088 页面看每个 NodeManager 上报的资源总量和可用量，再对比作业申请值和调度器上下限。常见做法是把 maximum-allocation-mb 调大，或者把作业的 mapreduce.map.memory.mb 调小，使二者匹配。如果有多个作业同时排队，还要检查调度器队列容量，Capacity Scheduler 的默认队列可能被先提交的作业占满，后面的作业只能排队。用 yarn application -list 查看排队情况，用 yarn application -kill 清理掉卡死不释放资源的异常任务，这类问题定位顺序是先看资源总量，再看作业申请值，最后看队列容量。
5.5 节点间时钟不同步引发各种异常
现象：集群运行中偶尔出现安全相关异常、作业随机失败、节点被判定失联，重启相关服务后短暂恢复，过一段时间又复发，排查代码和配置都没有明显问题。
原因：Hadoop 内部大量通信协议依赖时间戳和超时机制，节点间时钟偏差超过一定阈值，心跳判断和租约机制会出现误判。尤其是 HDFS 的租约机制，客户端写文件时靠租约锁定，时钟不同步会导致租约提前过期或延迟释放，写入操作会被其他客户端抢占，或者文件始终处于写入打开状态。
解决：在集群所有节点上统一配置时间同步，常见做法是部署 chrony 或系统自带的时间同步服务，让所有机器指向同一个时间源。这个配置要在集群搭建时就完成，不要等异常出现再补，因为部分环境的防火墙策略不允许临时变更。时间同步完成后重启 HDFS 服务，租约机制重新初始化，异常即可消除。这类问题属于典型的「配置没毛病、代码没毛病、但就是无缘无故翻车」的场景，排查思路应该先看系统层时间，而不是一上来怀疑应用代码。我自己的经验是集群超过三台机器时，第一件事就是统一时钟源，没有例外。
6. 把集群跑得更稳：资源限额、日志定位与调整顺序
集群能跑通只是起点，持续稳定运行靠的是三件事：资源限额、日志习惯、参数调整纪律。
第一件事是给不同业务划分配额。如果多个人同时用集群，一个占资源的作业会把整个集群的资源全部占掉，其他人提交的任务无限排队。在 capacity-scheduler.xml 里配置多个队列，分别限制资源上限，再结合提交作业时通过参数指定队列，能让资源分配更可控。实验环境里这一步可能看不出差别，放多团队共用集群时是真正保命的设计，改完队列配置要让 ResourceManager 重新加载，一般通过 Web UI 的刷新队列操作或者对应命令生效。
第二件事是熟悉日志的存放位置和排查顺序。NameNode、DataNode、ResourceManager、NodeManager 的日志都集中在安装目录的 logs 目录下，文件名带角色前缀，排错时先看对应角色的日志，不要从第一台机器开始盲 grep。作业本身的日志通过 YARN 的日志聚合功能收集，8088 页面每个作业都能跳到对应容器的标准输出和错误输出，这比一台台登录节点去翻日志高效得多。如果还没有开启日志聚合，建议尽早确认相关参数处于开启状态，否则作业跑完再找日志就只能靠清理策略碰运气。
第三件事是参数调整的顺序。不要一次改多个参数然后重启服务，出了问题你根本不知道是哪一项的锅。我的习惯是单次只调整一个参数，记下修改时间、修改前后的值，改完立刻跑一遍测试作业验证，确认无误再动下一个参数。这个习惯帮我避开了很多次「同时改了三个参数，集群反而更慢，又改不回去」的尴尬局面。资源类参数按内存、核数、并发数的顺序依次调，每次只动一个维度，因果链条才能观察清楚。回看这些年跑 Hadoop 集群的教训，最深刻的体会不是某个参数配错了，而是不要等问题出现才开始学运行维护。把格式化、启动顺序、健康检查、日志定位这些动作在实验环境里反复练成肌肉记忆，真正面对突发故障时心里才有底，命令才不会乱。希望这篇关于 Hadoop 集群运行的梳理能帮到你。
本文还有配套的精品资源，点击获取
