简介《第5章 Hadoop集群运行.pdf》是一份面向Hadoop运维初学者的实验指导文档贴合1X职业技能等级证书备考场景。内容围绕集群运行的完整生命周期展开从NameNode和DataNode格式化、启动HDFS到使用jps查看Java进程、通过hdfs dfsadmin -report检查HDFS报告与节点状态再到浏览器监控与stop-all.sh停止集群每一步均配有清晰命令和输出示例。文档还给出了服务器集群、CentOS 7.4等实验环境的准备说明以及格式化前清理工作目录的注意事项。资源包共1个文件类型为单个PDF大小1.33MB方便离线查看。已有204人学习过适合作为课内实验指导或课后自学材料。重点呈现集群运行中的常见操作与排错思路帮助读者避开DataNode进程缺失等典型坑位快速掌握集群状态确认与故障排查的基础技能。1. Hadoop集群运行PDF一份能照着搭集群的纸面导航做大数据开发绕不开 Hadoop而 Hadoop 最劝退的不是 MapReduce 编程是集群起不来。这份《第5章 Hadoop集群运行.pdf》是某高校大数据课程配套教材里的一章内容围绕集群运行全流程展开从环境校验、角色分配、核心配置到格式化、启停、任务提交正好对应 1x 大数据平台运维证书的实操考点。它不空讲原理每个环节都有可执行命令和参数说明适合两类人一类是刚接触集群、想在一套机器上把 Hadoop 跑起来的初学者另一类是备考 1x 证书、需要把集群运维流程走通的学生。照着这份章节操作能绕开不少玄学故障省下大量排查时间。2. 集群前置JDK 与 SSH 免密是起不来的两道坎2.1 为什么先查 JDKHadoop 对 Java 版本很敏感Hadoop 是跑在 JVM 上的分布式框架JDK 版本不对启动脚本执行到一半就报UnsupportedClassVersionError或JAVA_HOME is not set。这份 PDF 的第 5 章开篇就把 JDK 检查放在第一步不是没道理。Hadoop 3.x 需要 JDK 8 或 11很多教材环境用 JDK 1.8因为它兼容性最稳和后续 Hive、Spark 的衔接也顺。先确认三台机器如果有三台的 java 版本一致避免后面节点间行为不一致。# 分别在每台机器上执行 java -version # 查看 JAVA_HOME 是否已写入环境变量 echo $JAVA_HOMEjava -version的输出会显示当前 JDK 版本如果显示的是 1.8.x那基本没问题。echo $JAVA_HOME这一句很多人会忽略Hadoop 启动脚本会直接读取这个环境变量如果它是空的后边start-dfs.sh就会报 “JAVA_HOME is not set”。这时候要去/etc/profile或~/.bashrc里补上export JAVA_HOME/usr/local/jdk1.8 export PATH$PATH:$JAVA_HOME/bin改完执行source /etc/profile让它生效。注意JAVA_HOME的路径以你实际解压目录为准别照抄。集群里每台机器都要配漏一台那一台上的 DataNode 或 NodeManager 进程就起不来。我一般会在三台机器都执行一遍java -version echo $JAVA_HOME看到输出一致才继续。这一步的价值在于把“玄学报错”提前变成“环境问题”排查成本最低。2.2 SSH 免密配置生成密钥与分发公钥Hadoop 的启动脚本依赖 SSH 在节点间免密登录不然你执行start-dfs.sh后它会卡在密码输入上甚至直接失败。原理不复杂主节点生成一对密钥把公钥追加到目标机器的authorized_keys文件里之后 SSH 连接时服务器校验通过就不再要密码。实际操作里常见问题是只配了ssh localhost忘了节点之间的互通。# 在主节点上生成 RSA 密钥对一路回车即可 ssh-keygen -t rsa -P -f ~/.ssh/id_rsa # 将公钥分发到各个节点包括本机 ssh-copy-id -i ~/.ssh/id_rsa.pub hdusernode1 ssh-copy-id -i ~/.ssh/id_rsa.pub hdusernode2 ssh-copy-id -i ~/.ssh/id_rsa.pub hdusernode3-P 表示密钥口令为空这样脚本执行时不需手动输入 passphrase。-f ~/.ssh/id_rsa指定生成路径不写也行默认就是这个位置。分发公钥用的是ssh-copy-id它会自动把公钥追加到远端用户的authorized_keys比手动cat 更省事还会自动创建目录和设置权限。这里有个细节每台机器的用户必须一致比如都用hduser不然目录权限和所有者对上不后边还是会要密码。如果你没有三台机器只在单机做伪分布式「公钥分发」这一步只需要执行本机ssh-copy-id -i ~/.ssh/id_rsa.pub hduserlocalhost这是最多人踩的坑以为集群才有免密伪分布式也需要。PDF 里把这一步放在集群规划之前顺序是对的因为后面所有启动脚本都依赖它。我用一个「从主节点 ssh 到各节点不输密码」作为检查标准通了才算过。2.3 免密自检卡在这步后面全白搭配置完免密不要急着启动集群先做一轮自检。命令很简单但能把问题暴露在早期依次从主节点 SSH 到每一台机器看是否还要密码。ssh node1 ssh node2 ssh node3如果某台机器依然提示输入密码大概率是公钥没追加成功或者~/.ssh目录权限不对。Hadoop 对authorized_keys的权限要求很严格.ssh目录要 700authorized_keys文件要 600权限过宽会被 SSH 直接拒绝。用chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys修正。另外检查一下每台机器的/etc/hosts确保主机名能解析到正确的 IP。主机名解析错误会引发一个隐蔽问题SSH 连上了但 Hadoop 脚本解析节点时找不到对应主机。这一步做完集群的“地基”才算是打牢了。3. 角色规划与配置文件三台机器怎么分工3.1 伪分布式与完全分布式的选择Hadoop 的运行模式有三种本地模式、伪分布式、完全分布式。本地模式不需要启动任何守护进程跑 MapReduce 任务时直接在当前 JVM 里执行适合调试代码逻辑。伪分布式是在一台机器上模拟集群NameNode、DataNode、ResourceManager、NodeManager 都作为独立进程跑。完全分布式则是至少三台机器各角色分配到不同节点。PDF 这一章的定位是集群运行所以它默认你至少是伪分布式起步。如果你只有一台机器就用伪分布式拿整个流程练手如果你有 2 台或者 3 台按完全分布式来搭一步到位。选择上我的建议是能上多台就别用单机因为集群的很多故障只有多节点时才暴露——比如 DataNode 和 NameNode 的通信问题、节点间免密遗漏。单机伪分布式把所有角色塞进一个进程组反而掩盖了网络层面的问题。3.2 从 PDF 中提炼的角色分配表角色分配是集群运行的第一步设计PDF 给出一张示例表类似下面这样节点NameNodeDataNodeResourceManagerNodeManagernode1是是是是node2否是否是node3否是否是这张表在完全分布式里很典型主节点同时承担 NameNode 和 ResourceManager两个角色一个管存储、一个管计算调度放在同一台机器上在入门规模里可以接受。生产环境一般会拆分但学习阶段没必要。两个从节点作为 DataNode 和 NodeManager 提供存储与计算资源。如果只有一台机器做伪分布式所有角色都落在同一台角色分配表这一节可以直接跳过但配置文件里该写的参数一个都不能少。需要注意的是从节点不用配置dfs.namenode.name.dir因为它不跑 NameNode 进程。3.3 四个核心配置文件与参数说明Hadoop 的配置集中在etc/hadoop目录下最常见的四个文件是core-site.xml、hdfs-site.xml、yarn-site.xml和mapred-site.xml。很多人上来就改改完就报错原因是不知道每个参数控制什么。PDF 第 5 章在角色分配后紧接着给出配置模板这正是实操的正确顺序先确定角色再写配置。!-- core-site.xml集群入口与临时目录 -- configuration property namefs.defaultFS/name valuehdfs://node1:9000/value /property property namehadoop.tmp.dir/name value/home/hduser/hadoop_tmp/value /property /configurationfs.defaultFS是集群的统一入口地址所有客户端和节点都通过这个地址访问 HDFS主节点主机名写错后边所有任务提交都会报UnknownHostException。hadoop.tmp.dir是临时目录的根路径NameNode 的数据目录和 DataNode 的数据目录默认都会放在这个路径下所以一定要把它的父目录手动创建好mkdir -p /home/hduser/hadoop_tmp权限也要注意如果当前用户对这个目录没有写权限格式化阶段就会报错。下面是hdfs-site.xml的核心参数它与角色分配直接对应!-- hdfs-site.xmlNameNode 与 DataNode 的数据目录 -- configuration property namedfs.namenode.name.dir/name value/home/hduser/hadoop_tmp/dfs/name/value /property property namedfs.datanode.data.dir/name value/home/hduser/hadoop_tmp/dfs/data/value /property property namedfs.replication/name value2/value /property /configurationdfs.replication是副本数完全分布式默认 3但你只有两个 DataNode副本数设 3 的话第三个副本会一直处于等待状态集群显示不健康。学习环境设成 2 就够了。dfs.namenode.name.dir只在主节点配dfs.datanode.data.dir在每个 DataNode 节点配。如果你在从节点上也写了 name.dir它不会有影响但会造成困惑没必要。然后是 YARN 的配置这一块控制的是计算资源。ResourceManager 跑在主节点NodeManager 跑在从节点!-- yarn-site.xml调度与资源管理 -- configuration property nameyarn.resourcemanager.hostname/name valuenode1/value /property property nameyarn.nodemanager.resource.memory-mb/name value8192/value /property /configurationyarn.resourcemanager.hostname指定 ResourceManager 所在主机从节点不需要改。yarn.nodemanager.resource.memory-mb是每个 NodeManager 可用的最大内存我习惯设置成物理内存的 75% 左右比如 8G 内存的机器设 8192。设得过高会导致容器分配失败任务提交后一直在等待。还有一个参数容易被遗漏yarn.nodemanager.vmem-check-enabled虚拟内存超限检查实测里很多任务因为虚拟内存超限被杀掉把它设为false能减少这类误杀property nameyarn.nodemanager.vmem-check-enabled/name valuefalse/value /property最后是mapred-site.xml在 Hadoop 3.x 里MapReduce 运行框架默认就是 YARN这个文件可以不用额外配置。但很多教材还保留它原因是旧版本需要显式指定。如果你用的是 Hadoop 3.x不配这个文件完全没影响。搞清楚这一点能少改一个文件也少一次出错机会。4. 格式化与启停别让 NameNode 二次格式化坑了你4.1 首次格式化确认目录再下手配置全部写完第一次启动 HDFS 之前必须格式化 NameNode。格式化的作用是初始化文件系统的元数据目录生成一个空的 FsImage相当于给系统做一次“出厂设置”。命令是hdfs namenode -format执行后终端会打印一堆日志最后出现successfully formatted才说明成功。这里有三个容易踩的坑我一个个讲。第一个坑是格式化时机的选择。很多初学者启动失败后不做排查就直接重新格式化这是灾难性的操作。格式化会清空 NameNode 的元数据如果数据已经写入 HDFS重新格式化后 DataNode 的集群 ID 和 NameNode 不一致DataNode 就会拒绝连接表现为datanode进程活着但 Web UI 里看不到活跃节点。第二个坑是格式化目录本身。假如之前格式化过但失败了或者你改了dfs.namenode.name.dir的路径残留目录会让第二次格式化报错。解决方法是先手动清掉旧的元数据目录rm -rf /home/hduser/hadoop_tmp/dfs/name mkdir -p /home/hduser/hadoop_tmp/dfs/name只清理主节点还不够DataNode 的 data 目录也最好一并清掉保持集群元数据一致。第三个坑是格式化时如果dfs.namenode.name.dir指向的目录权限不够格式化直接抛 IOException提前用chown -R hduser:hduser /home/hduser/hadoop_tmp把归属理顺。4.2 分步启动还是脚本一键启各有各的适用场景格式化完成可以启动集群了。Hadoop 提供了start-dfs.sh和start-yarn.sh以及合并的start-all.sh。我建议在入门阶段分步执行而不是一键全启原因很简单分步启动可以清晰看到每类守护进程的启动日志出了问题知道是哪一段挂的。# 第一步启动 HDFS 集群 start-dfs.sh # 第二步启动 YARN 集群 start-yarn.shstart-dfs.sh会读取etc/hadoop/workers文件里的主机列表逐台 SSH 上去启动 DataNode。所以这个 workers 文件里的主机名必须和角色分配表一致漏写一个主机就少一个 DataNode。如果启动过程卡在 “node2: starting datanode” 之后不动多半是 SSH 免密没配置到位回到第 2 章去查。启动完成后再执行start-yarn.sh它负责拉起 ResourceManager 和 NodeManager同样是从主节点 SSH 到各工作节点。如果你确实想一键启可以用start-all.sh但这属于后边熟悉流程后再用的方式。要停集群对应的是stop-dfs.sh stop-yarn.sh停的顺序和启正好相反先停 YARN 再停 HDFS。实际运维里如果你直接 kill 所有 Java 进程会导致 HDFS 心跳超时客户端写入会报异常。按脚本停止能让节点优雅退出数据更安全。4.3 用 jps 验活进程数量对不对一眼看出集群启动完毕后别急着跑任务先在每台机器上执行jps检查守护进程。jps是 JDK 自带的小工具专门查看 Java 进程Hadoop 的所有守护进程都是 Java 进程所以用它能一眼看出谁活着谁挂了。# 在主节点 node1 上执行 jps正常情况下node1 应该出现以下进程NameNode ResourceManager SecondaryNameNode NodeManager DataNode如果你配置了 SecondaryNameNode它也会列出来。有人看到jps输出里有多个 Java 进程名会误以为集群异常其实那是正常情况。伪分布式模式下所有进程都在一台机器上看起来有 5 个 Java 进程完全正确。完全分布式下node2 和 node3 上应该只有DataNode和NodeManager如果出现了NameNode说明你角色分配没写对去检查hdfs-site.xml里的dfs.namenode.name.dir是否被错误地同步到了从节点。如果jps里某个进程缺失优先看对应日志而不是重启进程。日志位置默认在$HADOOP_HOME/logs目录比如 NameNode 日志是hadoop-hduser-namenode-node1.logDataNode 日志是hadoop-hduser-datanode-node2.log。日志尾部通常已经说明了失败原因比如端口被占用、目录不存在、权限不足。养成“先看日志再决定重启”的习惯能省下大量试错时间。5. 常见问题排查三组高频故障与修复记录5.1 免密配置完还要输密码现象start-dfs.sh启动过程中执行到某台从节点时卡住提示输入密码或者直接报Permission denied (publickey,gssapi-keyexch,password)。原因这台机器的authorized_keys文件里没有主节点的公钥或者公钥文件的权限不对。还有一种情况是.ssh目录的属主不是当前用户导致 SSH 拒绝读取公钥文件。解决重新手动把主节点的公钥追加到目标机器并设置好权限。# 在主节点执行把公钥内容复制到远端 cat ~/.ssh/id_rsa.pub | ssh hdusernode2 mkdir -p ~/.ssh cat ~/.ssh/authorized_keys # 在 node2 上执行修正目录与文件权限 chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys我遇到过一种隐蔽情况三台机器都配了免密但hosts表里 node2 配了内网 IP而 SSH 连接时解析到的是这个内网 IP从主节点连过去没问题但start-dfs.sh里用的主机名和hosts不一致导致它 SSH 到另一个地址走了密码登录。所以在hosts里主机名对应关系一定要和配置文件保持一致别图省事只用 IP。5.2 重复格式化后 DataNode 连不上 NameNode现象集群启动后jps显示 DataNode 进程存在但 HDFS Web UI 上看不到活跃的 DataNode命令行执行hdfs dfsadmin -report显示DataNode denied communication with NameNode日志里有Incompatible clusterIDs。原因这是典型的二次格式化导致的集群 ID 不一致。格式化的本质是给 NameNode 生成一个唯一的集群 IDDataNode 在首次连接时会把这个 ID 记录在本地。NameNode 被二次格式化后生成新 IDDataNode 手里的旧 ID 与之对不上就被拒绝。解决把每台 DataNode 上的dfs.datanode.data.dir对应目录清空让 DataNode 下一次启动时重新注册。# 在 node2 和 node3 上分别执行 rm -rf /home/hduser/hadoop_tmp/dfs/data清完重启 DataNode 进程它会重新从 NameNode 获取集群 ID。这个操作会丢失已存储的数据如果集群里还有数据先备份。学习环境一般没有重要数据可以直接清。从那以后我每次格式化前都强制确认一次“这台集群还有没有需要保留的 HDFS 数据”确认没有才动手。5.3 集群起来就卡死内存参数没设现象集群所有进程都起来了jps也正常但提交一个简单的 MapReduce 任务任务一直卡在ACCEPTED状态或者运行到一半Container被NodeManager杀掉日志显示物理内存超限。原因NodeManager 默认内存限制与实际配置不匹配。我遇到过一台 4G 内存的机器yarn.nodemanager.resource.memory-mb设置了 8G结果容器一分配就失败集群看起来活着实际什么事都干不了。解决根据机器物理内存调整参数并关闭虚拟内存检查。property nameyarn.nodemanager.resource.memory-mb/name value3072/value /property property nameyarn.nodemanager.vmem-check-enabled/name valuefalse/value /property这里 3072 是 4G 物理机上相对稳妥的取值给系统本身和其他进程留出余量。改完配置后要重启 YARN 相关进程stop-yarn.sh再start-yarn.sh。内存参数属于“配置时觉得差不多就行跑任务时才知道差很多”的那类问题建议一开始就把数据写准别靠运气。6. 用 WordCount 做冒烟测试验证集群的完整路径6.1 测试任务的准备与提交集群启动完成配置也调好接下来要做一次端到端的验证确认整条链路能通。最稳妥的冒烟测试是 Hadoop 自带的 WordCount 示例。运行时需要先往 HDFS 放一份输入数据再提交作业最后查看输出结果。# 在 HDFS 上创建测试目录 hdfs dfs -mkdir -p /test/input # 创建一个本地文本文件并上传 echo hello hadoop hello hdfs /tmp/test.txt hdfs dfs -put /tmp/test.txt /test/input/ # 提交 WordCount 作业 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /test/input /test/outputhdfs dfs -mkdir -p用于在 HDFS 上递归创建目录-put把本地文件上传到 HDFS。最后一条命令里的 jar 包路径会根据你使用的 Hadoop 版本变化如果目录下没有这个 jar用ls看一下实际文件名。作业提交后终端会输出作业进度包括map和reduce的百分比看到两项都到 100% 才算跑通。作业完成后输入目录里会有_SUCCESS文件作为完成标记。6.2 结果确认与日志查看作业跑完第一件事是确认输出内容是否正确这一步能验证 HDFS 读写和 MapReduce 计算全链路。# 查看输出目录内容 hdfs dfs -ls /test/output # 查看结果文件内容 hdfs dfs -cat /test/output/part-r-00000如果一切正常part-r-00000里会显示每个单词出现的次数比如hadoop 2、hello 2、hdfs 1。这里有一个判断经验如果输出目录已存在作业会直接报错因为 HDFS 不允许作业输出目录存在所以在重复运行时先删掉输出目录hdfs dfs -rm -r /test/output另外一个容易忽略的细节是Web UI 的 YARN 页面会显示历史作业列表里面可以看到每个作业的日志、启动时间、资源消耗。遇到怀疑作业有问题时把页面上拿到的 Application ID 拿到命令行去查yarn logs -applicationId application_1710000000000_0001yarn logs能打印出完整的日志包含 Map 阶段和 Reduce 阶段的输出比看 Web UI 更直观定位报错位置。在作业失败时我基本都是先看这里的日志再看对应的 container 日志。6.3 一轮跑通后的收尾习惯WordCount 跑通说明集群从配置到运行再到任务提交的整条链路已经能闭环。这时候我习惯做一遍收尾检查把这个流程固定成习惯先看jps确认所有进程还在然后去 HDFS Web UI 确认活跃 DataNode 数量与角色分配表一致最后看一眼 YARN 页面里的节点资源总量。这三个检查做完集群运行环境才算是真正稳定。整套操作走完以后建议把这份 PDF 的第 5 章下载下来对照着过一遍命令和配置文件重点确认有没有遗漏掉某些参数因为教材里写到的知识点往往比实际遇到的坑更系统。从那以后我每次搭集群都强制走一遍“校验 JDK、配免密、格式化、jps 验活、WordCount 冒烟”这个顺序再也没有出现过集群起不来还不知道从哪查起的情况。希望这份资源能帮你也走通这一整套流程。需要的话把这份章节 PDF 下到本地操作时直接照着翻会顺手很多。本文还有配套的精品资源点击获取 Hadoop集群运行实战：从环境配置到WordCount冒烟测试
简介《第5章 Hadoop集群运行.pdf》是一份面向Hadoop运维初学者的实验指导文档贴合1X职业技能等级证书备考场景。内容围绕集群运行的完整生命周期展开从NameNode和DataNode格式化、启动HDFS到使用jps查看Java进程、通过hdfs dfsadmin -report检查HDFS报告与节点状态再到浏览器监控与stop-all.sh停止集群每一步均配有清晰命令和输出示例。文档还给出了服务器集群、CentOS 7.4等实验环境的准备说明以及格式化前清理工作目录的注意事项。资源包共1个文件类型为单个PDF大小1.33MB方便离线查看。已有204人学习过适合作为课内实验指导或课后自学材料。重点呈现集群运行中的常见操作与排错思路帮助读者避开DataNode进程缺失等典型坑位快速掌握集群状态确认与故障排查的基础技能。1. Hadoop集群运行PDF一份能照着搭集群的纸面导航做大数据开发绕不开 Hadoop而 Hadoop 最劝退的不是 MapReduce 编程是集群起不来。这份《第5章 Hadoop集群运行.pdf》是某高校大数据课程配套教材里的一章内容围绕集群运行全流程展开从环境校验、角色分配、核心配置到格式化、启停、任务提交正好对应 1x 大数据平台运维证书的实操考点。它不空讲原理每个环节都有可执行命令和参数说明适合两类人一类是刚接触集群、想在一套机器上把 Hadoop 跑起来的初学者另一类是备考 1x 证书、需要把集群运维流程走通的学生。照着这份章节操作能绕开不少玄学故障省下大量排查时间。2. 集群前置JDK 与 SSH 免密是起不来的两道坎2.1 为什么先查 JDKHadoop 对 Java 版本很敏感Hadoop 是跑在 JVM 上的分布式框架JDK 版本不对启动脚本执行到一半就报UnsupportedClassVersionError或JAVA_HOME is not set。这份 PDF 的第 5 章开篇就把 JDK 检查放在第一步不是没道理。Hadoop 3.x 需要 JDK 8 或 11很多教材环境用 JDK 1.8因为它兼容性最稳和后续 Hive、Spark 的衔接也顺。先确认三台机器如果有三台的 java 版本一致避免后面节点间行为不一致。# 分别在每台机器上执行 java -version # 查看 JAVA_HOME 是否已写入环境变量 echo $JAVA_HOMEjava -version的输出会显示当前 JDK 版本如果显示的是 1.8.x那基本没问题。echo $JAVA_HOME这一句很多人会忽略Hadoop 启动脚本会直接读取这个环境变量如果它是空的后边start-dfs.sh就会报 “JAVA_HOME is not set”。这时候要去/etc/profile或~/.bashrc里补上export JAVA_HOME/usr/local/jdk1.8 export PATH$PATH:$JAVA_HOME/bin改完执行source /etc/profile让它生效。注意JAVA_HOME的路径以你实际解压目录为准别照抄。集群里每台机器都要配漏一台那一台上的 DataNode 或 NodeManager 进程就起不来。我一般会在三台机器都执行一遍java -version echo $JAVA_HOME看到输出一致才继续。这一步的价值在于把“玄学报错”提前变成“环境问题”排查成本最低。2.2 SSH 免密配置生成密钥与分发公钥Hadoop 的启动脚本依赖 SSH 在节点间免密登录不然你执行start-dfs.sh后它会卡在密码输入上甚至直接失败。原理不复杂主节点生成一对密钥把公钥追加到目标机器的authorized_keys文件里之后 SSH 连接时服务器校验通过就不再要密码。实际操作里常见问题是只配了ssh localhost忘了节点之间的互通。# 在主节点上生成 RSA 密钥对一路回车即可 ssh-keygen -t rsa -P -f ~/.ssh/id_rsa # 将公钥分发到各个节点包括本机 ssh-copy-id -i ~/.ssh/id_rsa.pub hdusernode1 ssh-copy-id -i ~/.ssh/id_rsa.pub hdusernode2 ssh-copy-id -i ~/.ssh/id_rsa.pub hdusernode3-P 表示密钥口令为空这样脚本执行时不需手动输入 passphrase。-f ~/.ssh/id_rsa指定生成路径不写也行默认就是这个位置。分发公钥用的是ssh-copy-id它会自动把公钥追加到远端用户的authorized_keys比手动cat 更省事还会自动创建目录和设置权限。这里有个细节每台机器的用户必须一致比如都用hduser不然目录权限和所有者对上不后边还是会要密码。如果你没有三台机器只在单机做伪分布式「公钥分发」这一步只需要执行本机ssh-copy-id -i ~/.ssh/id_rsa.pub hduserlocalhost这是最多人踩的坑以为集群才有免密伪分布式也需要。PDF 里把这一步放在集群规划之前顺序是对的因为后面所有启动脚本都依赖它。我用一个「从主节点 ssh 到各节点不输密码」作为检查标准通了才算过。2.3 免密自检卡在这步后面全白搭配置完免密不要急着启动集群先做一轮自检。命令很简单但能把问题暴露在早期依次从主节点 SSH 到每一台机器看是否还要密码。ssh node1 ssh node2 ssh node3如果某台机器依然提示输入密码大概率是公钥没追加成功或者~/.ssh目录权限不对。Hadoop 对authorized_keys的权限要求很严格.ssh目录要 700authorized_keys文件要 600权限过宽会被 SSH 直接拒绝。用chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys修正。另外检查一下每台机器的/etc/hosts确保主机名能解析到正确的 IP。主机名解析错误会引发一个隐蔽问题SSH 连上了但 Hadoop 脚本解析节点时找不到对应主机。这一步做完集群的“地基”才算是打牢了。3. 角色规划与配置文件三台机器怎么分工3.1 伪分布式与完全分布式的选择Hadoop 的运行模式有三种本地模式、伪分布式、完全分布式。本地模式不需要启动任何守护进程跑 MapReduce 任务时直接在当前 JVM 里执行适合调试代码逻辑。伪分布式是在一台机器上模拟集群NameNode、DataNode、ResourceManager、NodeManager 都作为独立进程跑。完全分布式则是至少三台机器各角色分配到不同节点。PDF 这一章的定位是集群运行所以它默认你至少是伪分布式起步。如果你只有一台机器就用伪分布式拿整个流程练手如果你有 2 台或者 3 台按完全分布式来搭一步到位。选择上我的建议是能上多台就别用单机因为集群的很多故障只有多节点时才暴露——比如 DataNode 和 NameNode 的通信问题、节点间免密遗漏。单机伪分布式把所有角色塞进一个进程组反而掩盖了网络层面的问题。3.2 从 PDF 中提炼的角色分配表角色分配是集群运行的第一步设计PDF 给出一张示例表类似下面这样节点NameNodeDataNodeResourceManagerNodeManagernode1是是是是node2否是否是node3否是否是这张表在完全分布式里很典型主节点同时承担 NameNode 和 ResourceManager两个角色一个管存储、一个管计算调度放在同一台机器上在入门规模里可以接受。生产环境一般会拆分但学习阶段没必要。两个从节点作为 DataNode 和 NodeManager 提供存储与计算资源。如果只有一台机器做伪分布式所有角色都落在同一台角色分配表这一节可以直接跳过但配置文件里该写的参数一个都不能少。需要注意的是从节点不用配置dfs.namenode.name.dir因为它不跑 NameNode 进程。3.3 四个核心配置文件与参数说明Hadoop 的配置集中在etc/hadoop目录下最常见的四个文件是core-site.xml、hdfs-site.xml、yarn-site.xml和mapred-site.xml。很多人上来就改改完就报错原因是不知道每个参数控制什么。PDF 第 5 章在角色分配后紧接着给出配置模板这正是实操的正确顺序先确定角色再写配置。!-- core-site.xml集群入口与临时目录 -- configuration property namefs.defaultFS/name valuehdfs://node1:9000/value /property property namehadoop.tmp.dir/name value/home/hduser/hadoop_tmp/value /property /configurationfs.defaultFS是集群的统一入口地址所有客户端和节点都通过这个地址访问 HDFS主节点主机名写错后边所有任务提交都会报UnknownHostException。hadoop.tmp.dir是临时目录的根路径NameNode 的数据目录和 DataNode 的数据目录默认都会放在这个路径下所以一定要把它的父目录手动创建好mkdir -p /home/hduser/hadoop_tmp权限也要注意如果当前用户对这个目录没有写权限格式化阶段就会报错。下面是hdfs-site.xml的核心参数它与角色分配直接对应!-- hdfs-site.xmlNameNode 与 DataNode 的数据目录 -- configuration property namedfs.namenode.name.dir/name value/home/hduser/hadoop_tmp/dfs/name/value /property property namedfs.datanode.data.dir/name value/home/hduser/hadoop_tmp/dfs/data/value /property property namedfs.replication/name value2/value /property /configurationdfs.replication是副本数完全分布式默认 3但你只有两个 DataNode副本数设 3 的话第三个副本会一直处于等待状态集群显示不健康。学习环境设成 2 就够了。dfs.namenode.name.dir只在主节点配dfs.datanode.data.dir在每个 DataNode 节点配。如果你在从节点上也写了 name.dir它不会有影响但会造成困惑没必要。然后是 YARN 的配置这一块控制的是计算资源。ResourceManager 跑在主节点NodeManager 跑在从节点!-- yarn-site.xml调度与资源管理 -- configuration property nameyarn.resourcemanager.hostname/name valuenode1/value /property property nameyarn.nodemanager.resource.memory-mb/name value8192/value /property /configurationyarn.resourcemanager.hostname指定 ResourceManager 所在主机从节点不需要改。yarn.nodemanager.resource.memory-mb是每个 NodeManager 可用的最大内存我习惯设置成物理内存的 75% 左右比如 8G 内存的机器设 8192。设得过高会导致容器分配失败任务提交后一直在等待。还有一个参数容易被遗漏yarn.nodemanager.vmem-check-enabled虚拟内存超限检查实测里很多任务因为虚拟内存超限被杀掉把它设为false能减少这类误杀property nameyarn.nodemanager.vmem-check-enabled/name valuefalse/value /property最后是mapred-site.xml在 Hadoop 3.x 里MapReduce 运行框架默认就是 YARN这个文件可以不用额外配置。但很多教材还保留它原因是旧版本需要显式指定。如果你用的是 Hadoop 3.x不配这个文件完全没影响。搞清楚这一点能少改一个文件也少一次出错机会。4. 格式化与启停别让 NameNode 二次格式化坑了你4.1 首次格式化确认目录再下手配置全部写完第一次启动 HDFS 之前必须格式化 NameNode。格式化的作用是初始化文件系统的元数据目录生成一个空的 FsImage相当于给系统做一次“出厂设置”。命令是hdfs namenode -format执行后终端会打印一堆日志最后出现successfully formatted才说明成功。这里有三个容易踩的坑我一个个讲。第一个坑是格式化时机的选择。很多初学者启动失败后不做排查就直接重新格式化这是灾难性的操作。格式化会清空 NameNode 的元数据如果数据已经写入 HDFS重新格式化后 DataNode 的集群 ID 和 NameNode 不一致DataNode 就会拒绝连接表现为datanode进程活着但 Web UI 里看不到活跃节点。第二个坑是格式化目录本身。假如之前格式化过但失败了或者你改了dfs.namenode.name.dir的路径残留目录会让第二次格式化报错。解决方法是先手动清掉旧的元数据目录rm -rf /home/hduser/hadoop_tmp/dfs/name mkdir -p /home/hduser/hadoop_tmp/dfs/name只清理主节点还不够DataNode 的 data 目录也最好一并清掉保持集群元数据一致。第三个坑是格式化时如果dfs.namenode.name.dir指向的目录权限不够格式化直接抛 IOException提前用chown -R hduser:hduser /home/hduser/hadoop_tmp把归属理顺。4.2 分步启动还是脚本一键启各有各的适用场景格式化完成可以启动集群了。Hadoop 提供了start-dfs.sh和start-yarn.sh以及合并的start-all.sh。我建议在入门阶段分步执行而不是一键全启原因很简单分步启动可以清晰看到每类守护进程的启动日志出了问题知道是哪一段挂的。# 第一步启动 HDFS 集群 start-dfs.sh # 第二步启动 YARN 集群 start-yarn.shstart-dfs.sh会读取etc/hadoop/workers文件里的主机列表逐台 SSH 上去启动 DataNode。所以这个 workers 文件里的主机名必须和角色分配表一致漏写一个主机就少一个 DataNode。如果启动过程卡在 “node2: starting datanode” 之后不动多半是 SSH 免密没配置到位回到第 2 章去查。启动完成后再执行start-yarn.sh它负责拉起 ResourceManager 和 NodeManager同样是从主节点 SSH 到各工作节点。如果你确实想一键启可以用start-all.sh但这属于后边熟悉流程后再用的方式。要停集群对应的是stop-dfs.sh stop-yarn.sh停的顺序和启正好相反先停 YARN 再停 HDFS。实际运维里如果你直接 kill 所有 Java 进程会导致 HDFS 心跳超时客户端写入会报异常。按脚本停止能让节点优雅退出数据更安全。4.3 用 jps 验活进程数量对不对一眼看出集群启动完毕后别急着跑任务先在每台机器上执行jps检查守护进程。jps是 JDK 自带的小工具专门查看 Java 进程Hadoop 的所有守护进程都是 Java 进程所以用它能一眼看出谁活着谁挂了。# 在主节点 node1 上执行 jps正常情况下node1 应该出现以下进程NameNode ResourceManager SecondaryNameNode NodeManager DataNode如果你配置了 SecondaryNameNode它也会列出来。有人看到jps输出里有多个 Java 进程名会误以为集群异常其实那是正常情况。伪分布式模式下所有进程都在一台机器上看起来有 5 个 Java 进程完全正确。完全分布式下node2 和 node3 上应该只有DataNode和NodeManager如果出现了NameNode说明你角色分配没写对去检查hdfs-site.xml里的dfs.namenode.name.dir是否被错误地同步到了从节点。如果jps里某个进程缺失优先看对应日志而不是重启进程。日志位置默认在$HADOOP_HOME/logs目录比如 NameNode 日志是hadoop-hduser-namenode-node1.logDataNode 日志是hadoop-hduser-datanode-node2.log。日志尾部通常已经说明了失败原因比如端口被占用、目录不存在、权限不足。养成“先看日志再决定重启”的习惯能省下大量试错时间。5. 常见问题排查三组高频故障与修复记录5.1 免密配置完还要输密码现象start-dfs.sh启动过程中执行到某台从节点时卡住提示输入密码或者直接报Permission denied (publickey,gssapi-keyexch,password)。原因这台机器的authorized_keys文件里没有主节点的公钥或者公钥文件的权限不对。还有一种情况是.ssh目录的属主不是当前用户导致 SSH 拒绝读取公钥文件。解决重新手动把主节点的公钥追加到目标机器并设置好权限。# 在主节点执行把公钥内容复制到远端 cat ~/.ssh/id_rsa.pub | ssh hdusernode2 mkdir -p ~/.ssh cat ~/.ssh/authorized_keys # 在 node2 上执行修正目录与文件权限 chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys我遇到过一种隐蔽情况三台机器都配了免密但hosts表里 node2 配了内网 IP而 SSH 连接时解析到的是这个内网 IP从主节点连过去没问题但start-dfs.sh里用的主机名和hosts不一致导致它 SSH 到另一个地址走了密码登录。所以在hosts里主机名对应关系一定要和配置文件保持一致别图省事只用 IP。5.2 重复格式化后 DataNode 连不上 NameNode现象集群启动后jps显示 DataNode 进程存在但 HDFS Web UI 上看不到活跃的 DataNode命令行执行hdfs dfsadmin -report显示DataNode denied communication with NameNode日志里有Incompatible clusterIDs。原因这是典型的二次格式化导致的集群 ID 不一致。格式化的本质是给 NameNode 生成一个唯一的集群 IDDataNode 在首次连接时会把这个 ID 记录在本地。NameNode 被二次格式化后生成新 IDDataNode 手里的旧 ID 与之对不上就被拒绝。解决把每台 DataNode 上的dfs.datanode.data.dir对应目录清空让 DataNode 下一次启动时重新注册。# 在 node2 和 node3 上分别执行 rm -rf /home/hduser/hadoop_tmp/dfs/data清完重启 DataNode 进程它会重新从 NameNode 获取集群 ID。这个操作会丢失已存储的数据如果集群里还有数据先备份。学习环境一般没有重要数据可以直接清。从那以后我每次格式化前都强制确认一次“这台集群还有没有需要保留的 HDFS 数据”确认没有才动手。5.3 集群起来就卡死内存参数没设现象集群所有进程都起来了jps也正常但提交一个简单的 MapReduce 任务任务一直卡在ACCEPTED状态或者运行到一半Container被NodeManager杀掉日志显示物理内存超限。原因NodeManager 默认内存限制与实际配置不匹配。我遇到过一台 4G 内存的机器yarn.nodemanager.resource.memory-mb设置了 8G结果容器一分配就失败集群看起来活着实际什么事都干不了。解决根据机器物理内存调整参数并关闭虚拟内存检查。property nameyarn.nodemanager.resource.memory-mb/name value3072/value /property property nameyarn.nodemanager.vmem-check-enabled/name valuefalse/value /property这里 3072 是 4G 物理机上相对稳妥的取值给系统本身和其他进程留出余量。改完配置后要重启 YARN 相关进程stop-yarn.sh再start-yarn.sh。内存参数属于“配置时觉得差不多就行跑任务时才知道差很多”的那类问题建议一开始就把数据写准别靠运气。6. 用 WordCount 做冒烟测试验证集群的完整路径6.1 测试任务的准备与提交集群启动完成配置也调好接下来要做一次端到端的验证确认整条链路能通。最稳妥的冒烟测试是 Hadoop 自带的 WordCount 示例。运行时需要先往 HDFS 放一份输入数据再提交作业最后查看输出结果。# 在 HDFS 上创建测试目录 hdfs dfs -mkdir -p /test/input # 创建一个本地文本文件并上传 echo hello hadoop hello hdfs /tmp/test.txt hdfs dfs -put /tmp/test.txt /test/input/ # 提交 WordCount 作业 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /test/input /test/outputhdfs dfs -mkdir -p用于在 HDFS 上递归创建目录-put把本地文件上传到 HDFS。最后一条命令里的 jar 包路径会根据你使用的 Hadoop 版本变化如果目录下没有这个 jar用ls看一下实际文件名。作业提交后终端会输出作业进度包括map和reduce的百分比看到两项都到 100% 才算跑通。作业完成后输入目录里会有_SUCCESS文件作为完成标记。6.2 结果确认与日志查看作业跑完第一件事是确认输出内容是否正确这一步能验证 HDFS 读写和 MapReduce 计算全链路。# 查看输出目录内容 hdfs dfs -ls /test/output # 查看结果文件内容 hdfs dfs -cat /test/output/part-r-00000如果一切正常part-r-00000里会显示每个单词出现的次数比如hadoop 2、hello 2、hdfs 1。这里有一个判断经验如果输出目录已存在作业会直接报错因为 HDFS 不允许作业输出目录存在所以在重复运行时先删掉输出目录hdfs dfs -rm -r /test/output另外一个容易忽略的细节是Web UI 的 YARN 页面会显示历史作业列表里面可以看到每个作业的日志、启动时间、资源消耗。遇到怀疑作业有问题时把页面上拿到的 Application ID 拿到命令行去查yarn logs -applicationId application_1710000000000_0001yarn logs能打印出完整的日志包含 Map 阶段和 Reduce 阶段的输出比看 Web UI 更直观定位报错位置。在作业失败时我基本都是先看这里的日志再看对应的 container 日志。6.3 一轮跑通后的收尾习惯WordCount 跑通说明集群从配置到运行再到任务提交的整条链路已经能闭环。这时候我习惯做一遍收尾检查把这个流程固定成习惯先看jps确认所有进程还在然后去 HDFS Web UI 确认活跃 DataNode 数量与角色分配表一致最后看一眼 YARN 页面里的节点资源总量。这三个检查做完集群运行环境才算是真正稳定。整套操作走完以后建议把这份 PDF 的第 5 章下载下来对照着过一遍命令和配置文件重点确认有没有遗漏掉某些参数因为教材里写到的知识点往往比实际遇到的坑更系统。从那以后我每次搭集群都强制走一遍“校验 JDK、配免密、格式化、jps 验活、WordCount 冒烟”这个顺序再也没有出现过集群起不来还不知道从哪查起的情况。希望这份资源能帮你也走通这一整套流程。需要的话把这份章节 PDF 下到本地操作时直接照着翻会顺手很多。本文还有配套的精品资源点击获取