简介这是一份面向“1X”大数据平台运维考证及Hadoop入门学习者的第5章配套PDF讲义聚焦Hadoop集群从启动到停止的完整运维闭环。内容主要讲解集群运行前的NameNode/DataNode格式化配置、使用jps查看Java进程、通过hdfs dfsadmin -report查看HDFS报告与节点状态以及利用浏览器监控节点、执行stop-all.sh停止集群等核心操作覆盖实验目的、环境要求与具体步骤适合配套教材边看边练。资源为1个PDF文件大小1.33MB文档结构清晰含命令示例与结果截图方便读者对照实操。目前已吸引204人学习适合作为课内实验或备考复习的速查资料。该章节强调集群运维中易忽略的细节如重复格式化需先清理工作目录有助于规避实验事故。1. Hadoop集群运行先看懂角色再谈启动“第5章 Hadoop集群运行”讲的不是单机跑通一个WordCount那么简单而是把HDFS和YARN两套体系同时拉起来让数据能存、任务能算、节点挂了还能恢复的完整链路。我见过不少刚接触分布式的开发者伪分布式跑得挺顺一上多节点就卡在角色分工、配置同步、启动顺序上折腾一天集群还是黑的。这章内容就是围绕集群运行中最容易出问题的几个环节展开先搞清楚谁管元数据、谁存数据块、谁调度资源再用伪分布式做最小验证最后落到多节点部署、启动、监控和排错。适合正在搭实验环境的学生、刚接手集群的运维工程师以及想从Demo跨到真实集群的开发者。只要会用Linux基本命令就能跟上不需要预先搭过任何分布式框架。2. 部署两条路伪分布式先跑通完全分布式再落地部署Hadoop集群我不建议一上来就铺多节点。踩过坑的人都懂集群第一次起不来八成不是配置写错而是你还没理解每一个进程的角色边界。先用伪分布式把角色关系跑熟再横向扩展到多台机器成功率会高很多。这一章把两条路线都走一遍并且给出部署完成后必须执行的自检命令。2.1 伪分布式一台机器上的最小可运行集群伪分布式的本质是让NameNode、DataNode、ResourceManager、NodeManager四个核心进程跑在同一台机器上进程之间有完整的通信链路但互相不抢资源。它的价值不是性能而是让你用最小成本验证配置文件语法、目录权限、端口占用这些基础问题。很多团队把伪分布式当作“冒烟测试环境”任何配置改动先在这里验证一遍再推到真实集群这个习惯能省掉大量线上故障。常见做法是在一份干净的Linux环境里下载某个主流Hadoop发行版压缩包解压到指定目录后配置JAVA_HOME。这里不指定具体版本号选择发行版时留意跟JDK版本的匹配关系即可JDK 8配Hadoop 3.x是经过大量验证的组合。解压后先改etc/hadoop/hadoop-env.sh# 设置JDK路径路径以实际安装位置为准 export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 # 指定Hadoop运行用户避免用root直接跑 export HADOOP_HOME/data/hadoop export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop这段配置里JAVA_HOME必须指向真实存在的JDK目录很多启动失败都栽在这一行写错路径上。HADOOP_HOME和HADOOP_CONF_DIR是为了后续命令简短不写也行但不写后面每条命令都要带全路径排查时会多花不少时间。环境变量只改这一步还不够我通常还建议把/data/hadoop/bin和/data/hadoop/sbin加进PATH这样后面启停脚本不需要写全路径。但要注意sbin目录下的start-dfs.sh、stop-dfs.sh这些命令跟bin目录里的hdfs命令是两回事前者负责启停进程后者负责执行文件系统操作别混在一起。伪分布式还需要在core-site.xml里把fs.defaultFS指到hdfs://localhost:9000在hdfs-site.xml里把副本数设成1。这两个文件第3章会展开讲这里先记住一个原则伪分布式跑通证明配置语法没问题完全分布式跑通才证明网络和角色协作没问题。如果在伪分布式阶段就频繁报错先回头检查JAVA_HOME和目录权限不要急着怀疑Hadoop版本。2.2 完全分布式节点规划与互信配置从伪分布式跳到完全分布式首先要做节点规划。常见的最小完整集群是三台机器一个主节点跑NameNode和ResourceManager两个从节点跑DataNode和NodeManager。主节点再承担SecondaryNameNode会比较吃力生产上不建议这么做但实验环境无所谓。关键是IP和主机名的对应关系要提前定死因为HDFS的元数据里记的是主机名不是IP。如果后面IP变了或者写配置时一会儿用IP一会儿用主机名DataNode注册时会反复报错日志里全是地址不匹配的异常。规划好之后三台机器都要改/etc/hosts让每个节点都能解析另外两台的主机名# 三台机器都要写同样的内容IP按实际规划替换 192.168.10.11 hadoop-master 192.168.10.12 hadoop-worker-1 192.168.10.13 hadoop-worker-2这里有个容易被忽略的点hosts文件改完后要立刻用ping hadoop-worker-1验证ping不通就重启网络服务再测。很多部署教程直接跳过验证步骤结果启动脚本ssh连不上worker节点日志停留在“连接被拒绝”排查半天才发现是hosts解析没生效。然后配置SSH免密登录目的是让主节点能无密码ssh到所有worker节点这样start-dfs.sh才能远程拉起DataNode进程。做法是把主节点的公钥追加到每台机器的authorized_keys里。完成之后还要确认主节点的etc/hadoop/workers文件内容# 主节点的 etc/hadoop/workers 文件每行一个worker主机名 hadoop-worker-1 hadoop-worker-2这个文件决定start-dfs.sh会把DataNode进程推到哪些机器。很多人配置了免密、改了XML文件但忘了维护workers文件启动后所有worker节点上根本没有DataNode进程只有主节点上孤零零一个NameNode还以为集群跑起来了。配置完用ssh hadoop-worker-1 hostname实测一条命令能返回主机名才算通。注意免密配置完要实测一条命令再继续不要只看到文件权限设成600就以为成功。2.3 部署完成后第一个自检命令部署完成后先别急着启动跑一遍自检能省掉后面大量排查时间。我把自检拆成三步按顺序执行。第一步检查进程依赖确认java进程存在、端口没被占用jps # 主节点期望看到NameNode、ResourceManager # 从节点期望看到DataNode、NodeManagerjps是JDK自带的小工具它会把当前用户启动的Java进程列出来。集群启动后每个节点上应该能看到对应的守护进程。有一个坑jps只能看到当前Linux用户启动的进程如果你用A用户启动却用B用户执行jps列表可能是空的别误判成进程没起来。第二步检查数据节点注册情况hdfs dfsadmin -report # 关注Live datanodes数量和每个DataNode的容量、剩余空间这个命令直接连NameNode查元数据能看到所有注册上来的DataNode。如果Live节点数比实际少说明有的DataNode没注册成功需要去对应节点看日志。第三步验证YARN资源池yarn node -list -all # 期望看到所有NodeManager状态为RUNNING这条命令验证的是计算侧的资源是否都被纳管。到这里部署自检结束可以进入启动流程。3. 启动流程与必调参数从格式化到第一个任务启动集群不是随便敲一条start-all.sh就完事。格式化、配置、启动顺序这三件事任何一件做错集群都可能在“看似启动成功”的状态下隐藏故障。这一章把从格式化到提交第一个任务的完整流程拆开每个关键动作都解释“为什么要这么做”。3.1 格式化NameNode做了什么为什么不能重复执行第一次启动HDFS之前必须格式化NameNode目的是在NameNode的存储目录里生成初始的元数据镜像和edit日志文件。换句话说它是在给整个文件系统“建目录结构”相当于给一块新硬盘分区。格式化之前先确认配置文件里的存储目录路径是真实存在且可写的否则格式化会失败# 在master节点执行STORAGE_DIR由hdfs-site.xml的dfs.namenode.name.dir指定 hdfs namenode -format # 看到 successfully formatted 即完成格式化会在指定目录生成一个新的clusterID所有DataNode首次注册时会被分配这个ID。如果集群运行中重新执行了格式化新clusterID和DataNode本地缓存的旧ID不一致DataNode就会拒绝注册表现为主节点上看不到任何DataNode。所以有个原则必须守住格式化只能在第一次启动前执行后面无论遇到什么故障都不要用重复格式化来“修复”问题。格式化确实能解决一部分玄学故障但代价是元数据全部清空跑在上面的所有目录、文件、权限全没了。如果NameNode元数据损坏正规做法是找回镜像备份或从SecondaryNameNode恢复不是重新格式化。注意格式化意味着元数据丢失集群运行中永远不要拿它当修故障的手段。3.2 三个核心配置文件与参数速查集群运行的行为基本由三个XML文件决定。core-site.xml管全局hdfs-site.xml管存储yarn-site.xml管计算。把它们理解成三个抽屉第一个放钥匙第二个放货架第三个放调度台。core-site.xml里平时必调的就是fs.defaultFS它决定HDFS的访问入口configuration property namefs.defaultFS/name valuehdfs://hadoop-master:9000/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property /configuration第二项hadoop.tmp.dir特别容易被忽略。很多发行版默认把它放在/tmp下而Linux的/tmp会被定期清理一旦被清NameNode下次启动会因找不到元数据而失败。我一般建议把所有存储路径都放到独立的数据盘目录不放在系统盘也不放在/tmp。hdfs-site.xml要管两块NameNode的元数据存储位置和DataNode的数据块位置configuration property namedfs.namenode.name.dir/name valuefile:///data/hdfs/namenode/value /property property namedfs.datanode.data.dir/name valuefile:///data/hdfs/datanode/value /property property namedfs.replication/name value2/value /property /configurationdfs.replication这个参数在写代码时不用显式声明但它的值直接决定数据冗余度。三节点集群设成2比较稳妥磁盘占用和容错能平衡实验环境只有一台机器时一定要设成1否则副本数永远等不到满足块会一直处于under-replicated状态Web界面上看像故障其实只是配置不合适。yarn-site.xml里最关键的参数是ResourceManager的地址和调度器配置configuration property nameyarn.resourcemanager.hostname/name valuehadoop-master/value /property property nameyarn.nodemanager.resource.memory-mb/name value8192/value /property property nameyarn.scheduler.maximum-allocation-mb/name value4096/value /property /configurationyarn.nodemanager.resource.memory-mb表示每个NodeManager能分配的内存总量必须小于机器的物理内存。yarn.scheduler.maximum-allocation-mb则是单个容器能申请的上限如果任务配置的executor内存超过它任务会一直等待资源。这两个参数配合不好时表现就是任务提交后卡在ACCEPTED状态第5章会细讲。3.3 启动顺序与失败形态判断配置文件改完后严格按照“先HDFS后YARN”的顺序启动# 在master节点按顺序执行 start-dfs.sh start-yarn.sh # 确认顺序执行成功后再单独启动历史作业服务 mapred --daemon start historyserver我不推荐直接敲start-all.sh虽然它一条命令全启动但把两个体系的启停捆在一起任何一个启动失败都得从头查。分步启动的好处是HDFS没起来时你不会去查YARN的日志问题边界清晰得多。启动阶段常见的失败形态有三种。第一种是进程存在但立即退出日志里报端口占用。原因是之前启动过但没正常停止残留进程还占着端口解决方法是先stop相关脚本再检查端口清理残留进程。第二种是NameNode起来了DataNode反复连接失败多半是hosts解析不一致主节点解析不了worker的主机名或者DataNode的配置文件里fs.defaultFS指向了错误地址。第三种是ResourceManager活着但Web界面看不到NodeManager这种往往不是网络问题而是NodeManager所在机器的可用内存低于yarn.nodemanager.resource.memory-mb的配置值把内存值降到物理内存的70%以下即可。启动之后不要急着把窗口关掉花两分钟把logs/hadoop-*-namenode-*.log和logs/yarn-*-resourcemanager-*.log的末尾盯一眼确认没有ERROR级别输出再离开。这一步能做到的人不多但每次都能提前暴露问题。启动完成不等于集群健康下一章讲怎么看监控和日志。4. 监控、日志与资源观察集群跑起来只是开始把进程拉起来不代表集群健康。数据块是否均衡、任务有没有排队、磁盘什么时候会满这些都要靠持续监控来回答。把集群当黑匣子运维在分布式系统里活不过三周。这一章给出监控入口、日志排查方法以及内存调优的参考边界。4.1 Web UI与关键指标怎么看集群装好后主节点的两个端口提供Web界面NameNode的9870端口和ResourceManager的8088端口。9870首页看HDFS总容量、已用空间、Live节点数8088首页看活跃应用、队列资源、节点列表。我每次看监控都先盯三个数字Live DataNode数量是不是等于实际节点数、HDFS已用比例是否超过80%、队列里Pending任务数有没有长期不为0。这三个数字只要有一个异常就值得点进去看原始指标而不是只盯CPU和内存。# 命令行快速看HDFS健康 hdfs dfsadmin -report -live # 快速看YARN每个节点的资源 yarn node -list -allWeb UI的优势是直观命令行的优势是可脚本化。比如用crontab每小时执行一次dfsadmin -report把输出重定向到日志文件出了问题能往前翻历史。很多集群故障的根因是“持续恶化”而非“突发”有历史数据才能看到趋势。把命令输出落盘这个习惯能让你在故障复盘时多出一份关键证据。4.2 日志布局与一次典型排查Hadoop的日志按角色放在各节点安装目录的logs下文件名带角色前缀。NameNode的日志是hadoop-用户名-namenode-主机名.logDataNode对应的是datanodeResourceManager和NodeManager同理。遇到问题别急着看完整日志先用grep定向过滤我习惯先查ERROR和FATAL再往前翻上下文# 在NameNode节点查最近30行错误日志 grep -E ERROR|FATAL logs/hadoop-*-namenode-*.log | tail -n 30有一次某跨平台系统集群突然所有任务失败用这条命令定位到zookeeper连接超时进而发现是某节点的时钟偏差太大。整个过程不到五分钟但如果上来就全文搜关键词反而容易被大量INFO日志干扰。日志文件默认单个50MB滚动老日志会按时间重命名排查历史问题时往logs目录下找带日期后缀的文件不要只盯当前这个某些故障的报错信息会在滚动后被截断真正原因可能藏在上一份文件里。4.3 内存参数调优让集群在有限资源里稳定跑内存配置是集群运维里最常翻车的环节。物理机32GB内存yarn-site里给到28GB跑几个任务之后系统突然卡顿swap开始频繁使用这是把NodeManager当吞内存怪兽的典型现象。NodeManager的内存上限必须低于物理内存减去系统和HDFS进程的开销一般做法是留出物理内存的20%到30%给操作系统和文件缓存剩下的才让YARN去分配。同时还要注意DataNode的内存不会跟NodeManager撞车。DataNode主要吃堆外内存做读写缓冲JVM堆设置2到4GB足够不要学别人把-Xmx调到内存的一半。分布式系统是多个进程共享一台物理机内存需要整体规划而不是每个进程都独立最大配置。参数调整后去ResourceManager的Web UI节点详情页能看到每台机器已分配和剩余内存。如果调整没生效检查yarn-site.xml是否同步到了所有节点只改主节点配置文件而worker节点没同步是最常见的“改了也白改”。5. 集群运行避坑指南5个高频故障的排查路径这一章把我在模拟项目X里遇到过的高频故障整理成五条排查路径。每条都按“现象、原因、解决”来写遇到类似问题可以直接按顺序试。Hadoop的报错信息往往不是根因顺着日志往上翻两层才是真正的问题所在。5.1 现象DataNode启动后不久进程消失现象是jps能看到DataNode但几秒到几分钟后进程自动退出NameNode的日志里出现连接被拒绝的错。原因通常是DataNode向NameNode注册时网络地址或者端口回调失败。某次排查中发现DataNode所在机器有多网卡回调地址指向了内网段主节点无法访问该地址。解决方法是明确HDFS监听地址在hdfs-site.xml里把dfs.namenode.rpc-bind-host和dfs.datanode.registered.hostname等参数定死不让进程去猜网卡。改完后重启相关进程逐个节点看datanode日志里的注册结果直到出现“successful registration”字样。5.2 现象NameNode起不来报元数据目录找不到现象是执行格式化或启动时报路径不存在或无法写入。原因是Linux对目录权限要求严格Hadoop以普通用户启动时没有在数据目录上写入的权限。解决方法是先创建目录、再授权、再格式化。很多教程直接让你在root下跑跑通了但后续每次启动都要切root这只会掩盖权限问题# 在master节点以运行用户执行 mkdir -p /data/hdfs/namenode /data/hdfs/datanode chown -R hadoop:hadoop /data/hdfs hdfs namenode -format注意chown指定的用户要跟启动脚本的用户一致不然格式化写入的属主不对后面进程起来仍然没权限写增量日志。这种故障的隐蔽之处在于格式化时用了root启动时用了普通用户两个阶段权限不一致排查时很难想到是文件属主的问题。5.3 现象任务提交后一直卡在ACCEPTED现象是yarn application -list能看到任务状态为ACCEPTED或RUNNING但所有容器都在等待资源。原因是NodeManager的总内存配置低于任务申请的最小容器内存或者队列的最大容量被限制。解决方法是先看ResourceManager的调度器页面确认各队列使用情况再调整yarn.nodemanager.resource.memory-mb和yarn.scheduler.maximum-allocation-mb。注意调度器页面里的Used和Pending两列Pending长期有值就说明资源不足或配置上限过低。还有一种情况是任务本身申请的容器内存超过了集群最大限制提交命令里带着大内存参数但集群侧配置根本给不了这么多。看任务提交时的申请参数比只盯集群配置更容易定位。5.4 现象磁盘明明满了删除文件后空间没释放现象是df显示的磁盘使用率居高不下HDFS里的文件删了一部分但空间没有回升。原因是HDFS删除文件不是物理删除而是先移动到回收站回收站文件同样占物理空间且默认保留7天。解决方法是定时清理超过保留期的回收站文件或者在确认不需要恢复后直接永久删除# 查看回收站占用 hdfs dfs -du -h /user/user/.Trash # 清理过期回收站内容 hdfs dfs -rm -r -skipTrash /user/user/.Trash/*注意skipTrash参数意味着不可恢复执行前确认数据确实不需要。另外要检查是否有块卡在坏副本状态文件删了但块没有从所有DataNode上清除也会出现“删了不释放”的情况。遇到这种问题先跑一次hdfs fsck / -files -blocks看哪些块处于异常状态。提示skipTrash一旦执行就没有后悔药清回收站前先确认数据可弃。5.5 现象节点状态在RUNNING和LOST之间反复横跳现象是ResourceManager界面里某个NodeManager时不时丢失过一会又回来。原因是节点的心跳超时设置太长或者太短加上节点时钟偏差。HDFS元数据操作依赖时间戳时间偏差超过阈值会让心跳被视为过期。解决方法是统一所有节点的系统时间生产环境配NTP服务实验环境至少保证每台机器跟同一时间源同步。时间同步这件事是典型的“平时没事出事就要命”。某次集群任务全部失败查了一天发现是两台worker的时间差了5分钟日志里的时间戳让所有排序结果错位教训很深。如果集群规模大建议把时间同步写进初始化脚本新节点上线自动完成校对不要依赖人工执行。6. 用一波真实负载验证集群一个可复现的收尾实验到这里集群能启动、监控能看、故障能查。但“能跑”和“经得住跑”是两回事。收尾我习惯跑一个经典测试作业不为性能为的是验证完整链路客户端提交任务ResourceManager分配容器NodeManager启动任务任务读写HDFS。这个链路通了集群才算真正健康。我常用的是自带的wordcount示例程序不需要写代码。找一个超过50MB的文件丢进HDFS跑一遍统计然后对比输出结果的行数是否跟预期一致# 准备数据目录并上传测试文件 hdfs dfs -mkdir /test-input hdfs dfs -put /data/sample.log /test-input/sample.log # 提交分布式计算任务 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar wordcount /test-input /test-output # 查看输出结果的前几行 hdfs dfs -cat /test-output/part-r-00000 | head -20这里的hadoop jar把示例jar包里的wordcount类作为入口后面两个参数分别是输入和输出路径。输出目录不能预先创建否则任务会报错。Map阶段做分词计数Reduce阶段做汇总最后写入part-r-00000文件。执行时注意当前用户要有对/test-input的读权限和对/test-output所在目录的写权限。跑完后去ResourceManager的8088页面看这个任务的Application状态再点进任务详情看Map和Reduce完成数。如果状态是SUCCEEDED且reduce输出非空整个链路基本就验证通过了。然后顺手删掉测试输出目录保持集群路径干净。跑完这个验证后我还会做一件小事把ResourceManager和NameNode的Web页面地址写进自己的维护笔记同时记录每个节点的数据盘容量。这些信息平时用不上等要扩容或迁移时就是唯一的凭据。好记性不如烂笔头分布式集群尤其如此。自己亲手把一个卡在启动阶段的集群盘活之后再去看日志、调参数心态会完全不一样。遇到玄学问题别慌按现象、原因、解决三段走大多数故障都能在日志里找到答案。希望帮到你。本文还有配套的精品资源点击获取
