头歌上那道 HDFS 初体验的题目真正卡人的地方从来不是后面几条命令而是第2关这一步——配置开发环境把 Hadoop 装起来、把伪分布式集群跑起来。我见过太多人前面几关点得飞快到这里对着终端发呆明明照着步骤改了文件jps出来的进程就是少一个好不容易 NameNode 起来了浏览器敲localhost:9870又是打不开。其实这一关考的压根不是记忆力而是对 Hadoop 启动链路的一次完整理解——环境变量怎么传、SSH 为什么必须先通、四个 XML 各管什么、格式化和启动的先后顺序为什么不能反。把这条链路捋顺了Hadoop 开发环境搭建和伪分布式集群搭建就是一件二十分钟能搞定的事捋不顺你能在里面耗一整个下午。下面我按自己踩过的顺序把这一关拆开讲一遍顺便把 HDFS 的初体验一起做完适合刚接触大数据、需要在单机上把 HDFS 跑通的人参考。1. 伪分布式到底伪在哪里先把这一步的边界划清楚1.1 一台机器上挤着的三个角色很多教程上来就让你改配置却不告诉你伪分布式到底是个什么形态结果配置改完了心里还是虚的。所谓伪分布式英文一般叫 Pseudo-Distributed Mode本质是把本来应该分散在多台机器上的守护进程全部塞进同一台机器、同一套文件系统里跑。它跟真正意义上的单机模式Standalone / Local Mode不一样单机模式下 Hadoop 根本不启动任何服务进程你跑 MapReduce 就是在本地 JVM 里算一遍连 HDFS 都不碰而伪分布式会老老实实启动 NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager 这几个 Java 进程它们通过本机的网络端口互相通信对外表现得就像一个缩小到一台机器上的集群。这个区别非常关键。因为一旦涉及网络通信就会牵出一连串真实集群才有的问题端口会不会冲突、主机名能不能解析、SSH 免密通不通、临时目录权限对不对。也就是说伪分布式是用一台机器的成本去换一套真实集群的调试体验。你在这一关遇到的所有报错几乎都能在真实集群里原样复现这也是为什么教学环节一定要安排这一步而不是让你直接上三台虚拟机。1.2 端口地图先记住这几个数排查时能省一半时间伪分布式最迷惑人的地方在于进程名字和端口对不上号。我把几个必须记住的端口整理成一张表配置和排错的时候对着看会快很多组件进程名jps 里看到的默认端口作用NameNodeNameNode9000RPCHadoop 3 常配 8020客户端读写 HDFS 的入口NameNode Web UI无独立进程9870Hadoop 3.x/ 500702.x浏览器查看集群与文件系统状态DataNodeDataNode9864Web/ 9866数据传输实际存放数据块的地方ResourceManagerResourceManager8088WebYARN 资源调度入口NodeManagerNodeManager8041 附近单节点上的资源执行者SecondaryNameNodeSecondaryNameNode9868Web辅助合并镜像不是热备我特别想强调 9870 和 50070 这两个数字的区别。Hadoop 2.x 时代 NameNode 的 Web 端口是 50070到了 3.x 改成了 9870中间还有一批端口整体做了迁移。网上大量老教程还在写 50070你照着敲进去打不开很容易误判成我的集群没起来其实是版本对不上。做法很简单grep -r 9870 $HADOOP_HOME/etc/hadoop/或者直接看hdfs-site.xml里dfs.namenode.http-address配了什么以你自己配置文件里的为准别以网上的截图为准。1.3 为什么实验环境偏爱伪分布式而不是真集群从教学角度看伪分布式有三个不可替代的好处。第一是可复现一台机器、一套目录、几个配置文件谁来做结果都一样出错了也好给人截图第二是成本低不用开三台虚拟机抢内存笔记本上 4G 内存就能跑起来第三是问题密度高真实集群里那些某个节点起不来副本数不对日志在哪看的问题在伪分布式里全都能碰到只是规模缩小了。反过来说你也要清楚它的局限伪分布式的dfs.replication只能填 1因为只有一个 DataNode副本数填 3 系统也放不下只会一直提示副本不足。所以看到副本相关的告警别慌那是配置层面的必然结果不是集群坏了。2. JDK 这个地基没打平后面全是玄学报错2.1 Hadoop 3.x 到底认哪个 JDKHadoop 是纯 Java 写的没有可用的 JDK后面每一步都会以各种奇怪的方式失败——可能报JAVA_HOME is not set也可能报一个完全看不懂的类加载异常。所以第一件事永远是确认 JDK。版本上给一个实用结论Hadoop 3.x 系列用 JDK 8 最稳Hadoop 3.3 之后的版本虽然编译时支持更高版本的 JDK但跑起来仍然可能碰到模块化相关的反射限制。如果你是在一个有网络的环境里装 JDK 8 是最省心的选择。装的方式无非两种包管理器直接装或者下载压缩包解压后手工配环境变量。我个人的习惯是后者因为解压式安装的路径完全由我控制后面排查问题时能一眼看清文件在哪不用去猜发行版把东西丢到了哪个目录。# 以解压式安装为例假设放在 /opt/module 下 sudo mkdir -p /opt/module sudo tar -zxvf jdk-8uXXX-linux-x64.tar.gz -C /opt/module/ ls /opt/module # 确认解压出来的目录名比如 jdk1.8.0_XXX提示解压完一定要ls看一眼真实目录名。压缩包里的目录名常常带具体的小版本号你复制教程里的路径时如果少了那串数字后面所有引用都会失败。2.2 JAVA_HOME 写在哪里Hadoop 才认这一步是新手最容易漏的。很多人只在~/.bashrc里配了JAVA_HOMEjava -version也能正常输出但 Hadoop 启动脚本就是找不到 Java。原因是 Hadoop 的启动脚本hadoop-env.sh里有自己的一份 Java 路径设置在某些配置下它并不完全依赖 Shell 环境变量。所以稳妥的做法是两边都写。先在~/.bashrc或/etc/profile里配系统级的export JAVA_HOME/opt/module/jdk1.8.0_XXX export HADOOP_HOME/opt/module/hadoop-3.3.4 export PATH$PATH:$JAVA_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbin然后显式地去改$HADOOP_HOME/etc/hadoop/hadoop-env.sh把其中的export JAVA_HOME这一行改成你自己的路径。这里有个细节很多版本的hadoop-env.sh里这一行是被注释掉的你得先把行首的#去掉再改光改不改注释等于没改。改完可以顺手把内存参数也调一下在内存紧张的实验环境里这一步能救命# hadoop-env.sh 里常见的两行 export JAVA_HOME/opt/module/jdk1.8.0_XXX export HDFS_NAMENODE_OPTS-Xmx512m -Xms256mXmx是 JVM 堆上限Xms是初始堆大小。在一台只有 2G 到 4G 内存的机器上默认堆大小可能让 NameNode 直接起不来或者被系统 OOM 杀掉压到 512M 通常就够用了。这个调整没有什么玄学纯粹是资源约束下的取舍。2.3 怎么验证JDK 和 Hadoop 确实握手了不要只看java -version。那个命令只能证明你当前这个 Shell 能找到 Java证明不了 Hadoop 能找到。真正有效的验证顺序是echo $JAVA_HOME—— 确认输出是你期望的路径不是空行。$HADOOP_HOME/bin/hadoop version—— 这一步最有用。如果 Java 环境有问题这个命令会直接把报错吐出来比如提示找不到 Java 或者 JAVA_HOME 设置无效。只有当hadoop version正常打印出版本号和编译信息才算地基打平了。我把这个命令放在所有的配置动作之前跑一遍成了一个固定习惯。因为它能在你还没改任何 XML 之前就把环境变量层的问题全部暴露出来避免后面把两类问题混在一起排查。很多人的配置改了没用根源其实是最早这一步就没过后面所有改动都是在错误的地基上叠砖。3. 免密登录不是仪式感SSH 配置与主机名映射3.1 Hadoop 的启动脚本为什么非要 SSH第一次看到配置 SSH 免密登录这一条时我的反应是我在自己机器上启动自己机器上的进程为什么还要登录一次答案藏在 Hadoop 的启动脚本里。start-dfs.sh这个脚本并不是简单地nohup java ...起进程它内部会去读取一个节点列表workers或者老版本的slaves文件然后对列表里的每一个主机名执行一次 SSH 远程命令去拉起对应的守护进程。在伪分布式里这个列表里写的是localhost所以它就会 SSH 到 localhost 一次。这就解释了两件事为什么没有免密登录时启动过程会反复停下来问你密码以及为什么/etc/hosts和hostname配置错了会直接导致启动失败——脚本拿着主机名去解析地址解析不出来就连不上。理解了这个机制你就不会觉得这一步是教程凑字数而是启动链路上真实的一环。3.2 生成密钥然后把公钥交给自己操作本身只有三条命令但顺序和权限有讲究# 1. 生成密钥对一路回车即可不需要设密码短语 ssh-keygen -t rsa # 2. 把公钥追加到授权文件里 cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys # 3. 权限必须收紧否则 sshd 会拒绝使用这个文件 chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys第 3 步是重灾区。authorized_keys的权限如果太开放比如 644OpenSSH 出于安全考虑会直接忽略它表现就是我明明配了免密还是要输密码。我第一次遇到时反复检查公钥内容最后发现是权限问题。另外一个常见情况是目标机器上压根没装 SSH 服务端只有客户端那么ssh localhost会直接报连接被拒绝这时候需要先把openssh-server装上并确认服务在跑。验证方式很直接ssh localhost能免密直接进去看到提示符变化就说明通了。如果它问你密码就说明上面某一步没生效别急着往下走先把这一步解决。3.3 hostname 和 /etc/hosts一对必须对齐的东西伪分布式里通常用localhost但有些环境尤其是容器化的实验环境里hostname返回的是容器 ID 或者一串随机字符串而/etc/hosts里没有这个名字对应的条目。这时候启动脚本拿着这个主机名去连就会出现解析失败。排查方法很简单hostname # 看看当前主机名是什么 cat /etc/hosts # 看看这个名字在里面有没有映射如果hostname的输出在/etc/hosts里找不到就补一行把主机名指向127.0.0.1。注意是补到127.0.0.1而不是127.0.1.1两者的差别在某些发行版上会影响服务监听地址的绑定。改完之后再ping $(hostname)确认能通就没问题了。提示如果实验环境是每次进入都重新分配的容器/etc/hosts里已有的映射不要随手删掉只做追加。删了可能会连带影响其他服务的主机名解析。4. 四个 XML 逐个拆解改哪一行为什么改Hadoop 的配置文件看起来很多实际在这个阶段需要动的只有四个 XML 加一个环境脚本。我把它拆成每个文件真正决定什么来讲比照着教程照抄行号要有用得多。4.1 core-site.xml声明默认文件系统是谁这个文件在最前面因为它是全局的。核心只有一个属性fs.defaultFS它告诉 Hadoop当用户不指定具体地址时默认去哪个文件系统读写。configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/opt/module/hadoop-3.3.4/data/tmp/value /property /configurationhdfs://localhost:9000这个值直接决定了你后面所有hdfs dfs命令的行为。如果你写成hdfs://localhost:8020那就必须保证 NameNode 真的监听在 8020两边要一致。而hadoop.tmp.dir是很多人忽略的一项它决定了 Hadoop 运行时产生的临时数据放在哪。默认情况下它在/tmp下面而/tmp在很多系统上会被定时清理容器重启也可能清空——一旦临时目录被清掉而你的 NameNode 元数据又刚好依赖它集群就会出现莫名其妙的状态错乱。所以我强烈建议显式指定一个不会被自动清理的目录这是踩过坑之后养成的习惯。4.2 hdfs-site.xml副本数、目录、Web 端口这个文件决定 HDFS 自己的行为伪分布式下要动的有三个点configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name valuefile:///opt/module/hadoop-3.3.4/data/namenode/value /property property namedfs.datanode.data.dir/name valuefile:///opt/module/hadoop-3.3.4/data/datanode/value /property /configurationdfs.replication填 1 是伪分布式的必然选择理由前面说过整个集群只有一台 DataNode副本数大于可用节点数只会让写入过程一直等。dfs.namenode.name.dir是元数据的落地位置dfs.datanode.data.dir是数据块的实际存放位置这两个目录的价值在于当你想彻底重来一次的时候只要停掉集群、把这两个目录清空、重新格式化就能回到干净的初始状态。如果你没有显式配它们它们会落到hadoop.tmp.dir下面清理的时候就得连带处理容易漏。file://这个前缀也不能少它表示这是本地文件系统路径而不是 HDFS 路径。少了它Hadoop 在解析时会尝试当成 HDFS URI 处理直接报错。4.3 mapred-site.xml 与 yarn-site.xml 的配合这两个文件是一对。mapred-site.xml里的mapreduce.framework.name决定 MapReduce 程序跑在哪种资源调度框架上伪分布式下一般填yarnyarn-site.xml则负责把 YARN 自己的服务配起来。两者对不上的话会出现作业提交了但一直卡住的现象。!-- mapred-site.xml -- property namemapreduce.framework.name/name valueyarn/value /property property nameyarn.app.mapreduce.am.env/name valueHADOOP_MAPRED_HOME/opt/module/hadoop-3.3.4/value /property property namemapreduce.map.env/name valueHADOOP_MAPRED_HOME/opt/module/hadoop-3.3.4/value /property!-- yarn-site.xml -- property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property property nameyarn.resourcemanager.hostname/name valuelocalhost/value /propertyyarn.nodemanager.aux-services和它配套的 ShuffleHandler 类名是 YARN 版本升级后特别容易出问题的地方。老版本里mapreduce_shuffle需要额外指定实现类新版本通常只要写mapreduce_shuffle就行写多了一层或者少了一层都会在跑作业时报类找不到。HADOOP_MAPRED_HOME这三行同样属于教程不写、但真跑起来会需要的配置它的作用是让 YARN 启动的容器知道去哪里找 MapReduce 相关的 jar 包。如果第一次跑作业报了一堆跟 classpath 有关的错误大概率就是这里没配。4.4 hadoop-env.sh 里另外两个容易被忽略的变量除了JAVA_HOME这个脚本里还有两个位置值得动一动。一个是HADOOP_LOG_DIR它决定日志写在哪。在实验环境里我习惯把它指到一个明确路径比如$HADOOP_HOME/logs这样出问题的时候不用猜日志藏在哪个角落。另一个是各个组件的*_OPTS前面提过用来控制 JVM 堆大小。日志路径这件事值得多说一句Hadoop 所有启动失败但没报错的情况答案都在日志里。jps只告诉你进程在不在不告诉你为什么不在。养成进程没起来就去 logs 目录按组件名和日期找最新一个文件的习惯排查效率会有质的提升。日志文件名一般长这样hadoop-用户名-datanode-主机名.log直接tail -100看最后一段堆栈信息通常就在那儿。5. 格式化、启动、验证可以照抄的一条完整链路5.1 格式化只做一次顺序不能反配置改完之后的第一个动作是格式化 NameNodehdfs namenode -format这一步的作用是在dfs.namenode.name.dir指定的目录下生成初始的元数据结构包括那个关键的fsimage和VERSION文件。有两条经验非常值钱第一格式化必须发生在所有配置改完之后。如果你先格式化再改dfs.namenode.name.dir那么格式化生成的数据在旧目录新目录是空的集群启动时会认为未初始化。第二格式化只能做一次除非你打算清库重来。每次格式化都会生成一个新的clusterID而 DataNode 的数据目录里存着它注册时记住的那个clusterID。两者对不上DataNode 就会拒绝启动日志里的报错字样通常是 clusterID 不一致。很多人反复格式化之后发现 DataNode 起不来就是这个原因。如果确实需要重来正确姿势是停止所有进程 → 删除dfs.namenode.name.dir和dfs.datanode.data.dir两个目录下的内容 → 重新格式化 → 重新启动。三个动作缺一个都不干净。格式化时你会看到一句 Successfully formatted但别被它骗了如果它同时提示 Re-format filesystem 并让你确认说明目录里已经有旧数据这时候按 CtrlC 退出去检查比按 y 继续要明智。5.2 启停脚本与 jps 的自查逻辑启动分两步先 HDFS 后 YARN$HADOOP_HOME/sbin/start-dfs.sh $HADOOP_HOME/sbin/start-yarn.sh启动完立刻用jps看进程。一个健康的伪分布式应该能看到这几个名字NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager加上jps自己一共六行左右。这里有个细节jps是当前用户视角的如果你之前是用 root 启的进程现在用普通用户执行jps可能什么都看不到。这种情况下先whoami确认身份再看ps -ef | grep java更靠谱。进程缺一个的时候排查顺序建议是从下往上先看这个组件的日志再看它的数据目录在不在、有没有权限最后才怀疑 XML 配置。我见过不少人一上来就反复改配置文件实际上问题只是数据目录残留了上一次的 clusterID属于清理层面的事跟配置无关。停止的顺序反过来先 YARN 后 HDFS$HADOOP_HOME/sbin/stop-yarn.sh $HADOOP_HOME/sbin/stop-dfs.sh如果哪天忘了顺序、或者进程状态很乱直接ps -ef | grep java找到相关 PIDkill掉也行但要注意别误杀别的 Java 服务。在只有一个实验环境的机器上这个风险可以忽略。5.3 Web 界面和命令行两条验证通道都要走进程起来了不等于服务可用还得验一遍。Web 端访问http://localhost:9870进去之后看Overview页面重点确认两件事Live Nodes是不是 1DFS Used有没有数字。如果 Live Nodes 显示 0 或者节点处于 Dead 状态说明 DataNode 没真正注册上回头去看 DataNode 的日志。命令行端更直接hdfs dfsadmin -report这个命令会把整个文件系统的基本状况打出来包括总容量、可用容量、DataNode 数量和每个节点的主机名。它的好处是不依赖浏览器和端口转发纯粹走 RPC在 Web 打不开的场景下也能确认集群本身是否健康。所以我的习惯是先用dfsadmin -report确认集群活着再去浏览器看细节。这样一旦浏览器打不开能立刻分清是集群问题还是网络/端口问题。6. HDFS 初体验把文件真正丢进去再拿出来6.1 HDFS 命令和本地文件命令的对照HDFS 的命令行接口设计得刻意贴近 Linux 文件命令学过一遍本地命令的人上手很快。对照关系如下本地命令HDFS 对应写法说明mkdir -phdfs dfs -mkdir -p递归建目录lshdfs dfs -ls列目录cphdfs dfs -put/-get本地→HDFS / HDFS→本地cathdfs dfs -cat打印内容rm -rhdfs dfs -rm -r递归删除df -hhdfs dfs -df -h查看容量duhdfs dfs -du -h查看目录大小有一点必须提醒hdfs dfs -rm -r不会问你确认也不进回收站除非主动开启了回收站功能。在实验环境里删错东西无非重来一次但在真实环境里这一条能让人记一辈子。养成删之前先-ls看一眼的习惯成本很低。6.2 一次完整的上传、查看、下载闭环光看命令清单记不牢走一遍完整流程最有效。假设我想把一个本地文件放进 HDFS 再取回来# 1. 建目录注意 HDFS 里当前用户的默认目录是 /user/用户名 hdfs dfs -mkdir -p /user/$(whoami)/input # 2. 确认目录建好了 hdfs dfs -ls /user/$(whoami) # 3. 上传先造一个本地测试文件 echo hello hdfs, this is a pseudo distributed cluster /tmp/test.txt hdfs dfs -put /tmp/test.txt /user/$(whoami)/input/ # 4. 查看 HDFS 上的内容 hdfs dfs -ls /user/$(whoami)/input hdfs dfs -cat /user/$(whoami)/input/test.txt # 5. 取回本地换个文件名避免覆盖 hdfs dfs -get /user/$(whoami)/input/test.txt /tmp/test_back.txt diff /tmp/test.txt /tmp/test_back.txt echo 内容完全一致这个闭环里藏着几个知识