1. 先搞清楚单机版Hadoop到底解决什么问题1.1 为什么一上来就搭集群的人最容易翻车很多人学Hadoop脑子里第一个念头就是搭一个“像样”的分布式集群三台虚拟机起步一个Master两个Slave然后照着网上教程一路敲命令。结果是什么呢大概率是卡在SSH免密登录、节点之间互相ping不通、ResourceManager起不来、DataNode注册不上折腾一整天回到原点。我见过不少同学卡在这一步就放弃了理由是“分布式环境太复杂不适合入门”。这个判断其实是个误解——你真正需要的是先把Hadoop的架构、启动流程、配置文件之间的关系跑通然后再去谈集群。放在单机上跑一遍伪分布式是最稳的一条学习路径。何为“单机版部署”严格来说它有两种形态本地模式Standalone不启动守护进程所有组件运行在一个Java进程里主要用于跑MapReduce作业单元测试。伪分布式模式Pseudo-Distributed在单台机器上启动全部HDFS和YARN守护进程每个守护进程都是独立Java进程分别模拟NameNode、DataNode、ResourceManager、NodeManager。我们这篇要做的就是第二种。它是从“能跑”到“会跑”之间的关键桥梁也是后续学习完全分布式时唯一靠谱的经验基础。1.2 伪分布式和真集群之间的对应关系用一张表说清楚三种模式的差异对比项本地模式伪分布式本篇实操完全分布式需要机器数量1台1台至少3台HDFS进程不启用NameNodeDataNode均单机启动分别部署在不同节点YARN进程不启用ResourceManagerNodeManager均单机启动分别部署在不同节点配置文件无需修改需修改4个XML文件需修改并分发到所有节点学习目的验证Java接口理解组件间协作关系生产环境实测踩坑概率极低中等主要为配置细节高网络、同步、权限等伪分布式模式里的这台机器等于把整个集群“压缩”在一个节点上。NameNode和DataNode都跑在同一台机器上但它们仍然是独立的进程、独立的端口、独立的日志目录这就足以让你体会HDFS底层的交互流程了。搞清楚这个前提之后再往下走才不会被各种错误信息带偏——这不是集群问题这是配置问题。2. 部署前的准备工作JDK版本与SSH免密算是两座山2.1 JDK版本选不对后面全白搭Hadoop本身是Java写的依赖JDK运行。这个环节最大的坑不是“装不上”而是版本不匹配。不同Hadoop发行版对JDK的支持范围差别很大比如Hadoop 2.x普遍要求JDK 7或8而Hadoop 3.3.x则官方推荐JDK 8或11。我在实操中比较稳妥的做法是选用Hadoop 3.3.x版本配JDK 8对应包名如jdk-8u版本系列。用tar方式解压JDK到/usr/local/java/目录不用系统自带的OpenJDK避免路径识别混乱。配置JAVA_HOME环境变量并把$JAVA_HOME/bin加进PATH。配置示例写入/etc/profile或~/.bashrcexport JAVA_HOME/usr/local/java/jdk1.8.0_202 export PATH$JAVA_HOME/bin:$PATH export HADOOP_HOME/usr/local/hadoop export PATH$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$PATH export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop保存后执行source /etc/profile或者重新登录终端运行java -version验证。这里有个容易被忽略的细节Hadoop的启动脚本start-dfs.sh内部会读取JAVA_HOME但脚本本身需要SSH到本机来启动各种守护进程。如果你的环境里JAVA_HOME只在某个用户配置里生效而start-dfs.sh是以另一个用户身份执行的就会出现“java命令找不到”的诡异报错。保险做法是把JAVA_HOME写入/etc/profile而不是只写进某个用户的~/.bashrc。2.2 SSH免密登录整个部署链路上最容易“卡脖子”的环节伪分布式模式启动HDFS时start-dfs.sh会通过SSH登录localhost来启动NameNode、DataNode等进程。如果你每次都还要输入密码脚本会卡住直接导致启动失败。配置SSH免密很多人知道要执行ssh-keygen -t rsa但容易漏掉一个关键步骤——把公钥写入并正确授权。完整的流程如下ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys chmod 700 ~/.ssh注意最后两步权限设置。如果authorized_keys或.ssh目录权限过宽比如755SSH服务出于安全策略会拒绝使用密钥登录然后依然提示你输密码。这是我见过频率最高的问题新手基本都会栽一遍。验证是否配置成功ssh localhost如果无需输入密码直接进入说明配置完成。如果还是提示密码先检查权限再检查/etc/ssh/sshd_config里的PubkeyAuthentication是否被注释掉或者设为no。另外一个容易被忽略的点ssh localhost和ssh 本机IP操作的是两个不同的连接目标Hadoop 启动脚本默认连接的是配置文件里fs.defaultFS指定的主机名。因此建议在/etc/hosts里把localhost和你的机器主机名都映射到127.0.0.1避免启动时解析不到主机名。3. 核心配置文件逐个拆解四个XML是全部秘密所在3.1 先认识Hadoop的配置体系Hadoop的行为完全由一组XML配置控制核心文件位于$HADOOP_HOME/etc/hadoop/下分别是文件名称作用core-site.xml定义HDFS的访问入口NameNode地址、临时目录等hdfs-site.xml定义HDFS存储目录、副本数、NameNode端口等参数mapred-site.xml定义MapReduce运行框架是否走YARNyarn-site.xml定义YARN核心服务位置和辅助服务这四份配置彼此关联不是各自独立的。比如core-site.xml里的fs.defaultFS会告诉客户端“HDFS在哪里”而hdfs-site.xml里的dfs.namenode.http-address则决定了NameNode的Web管理端口。如果前后不一致就会出现“客户端连上了NameNode但Web界面打不开”这种困惑。3.2 单机部署时每个参数该怎么填下面是一份我在单机部署实测没有问题的配置组合以Hadoop 3.3.x为例core-site.xmlconfiguration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/usr/local/hadoop/tmp/value /property /configuration第一个参数是HDFS的文件系统入口伪分布式模式下固定写hdfs://localhost:9000端口可以默认。第二个参数指定Hadoop临时文件目录建议提前建好并赋予当前用户写权限mkdir -p /usr/local/hadoop/tmp否则启动时自动创建目录可能因为权限不足而报错。hdfs-site.xmlconfiguration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/usr/local/hadoop/dfs/name/value /property property namedfs.datanode.data.dir/name value/usr/local/hadoop/dfs/data/value /property /configurationdfs.replication必须设为1因为只有一台机器默认3的话DataNode会一直尝试复制文件却始终凑不够数表现出来就是磁盘文件写入后在Web界面看到Under-Replicated状态。name.dir和data.dir分别定义元数据与数据块的存放路径需要手工创建。mapred-site.xmlconfiguration property namemapreduce.framework.name/name valueyarn/value /property property namemapreduce.application.classpath/name value$HADOOP_HOME/share/hadoop/mapreduce/*:$HADOOP_HOME/share/hadoop/mapreduce/lib/*/value /property /configuration第一项告诉MapReduce任务调度交给YARN去执行而不是跑在本地的MR框架里。第二项在Hadoop 3.x版本里比较容易缺不填的话跑WordCount时会报找不到JobResourceUploader之类的类加载错误。yarn-site.xmlconfiguration property nameyarn.resourcemanager.hostname/name valuelocalhost/value /property property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property /configurationyarn.resourcemanager.hostname指定ResourceManager所在地址yarn.nodemanager.aux-services是关键中的关键——MapReduce作业跑在YARN上时MapTask和ReduceTask之间的数据交换依赖shuffle服务如果这个aux-service没配置作业会卡在Map阶段一直停留在RUNNING状态。3.3 还有个容易被遗忘的hadoop-env.sh除了上面四个XMLhadoop-env.sh里通常需要手动修改一项。打开该文件找到JAVA_HOME配置取消注释并将其指向你的JDK绝对路径export JAVA_HOME/usr/local/java/jdk1.8.0_202虽然系统环境变量里已经配置了JAVA_HOME但Hadoop脚本在执行时可能处于非登录Shell环境未必能读到显式写在这里最保险。4. 从格式化到访问成功启动全流程与验证手段4.1 格式化NameNode这一步不能回头配置全部就绪后第一件事是格式化NameNodehdfs namenode -format看到输出末尾出现successfully formatted字样说明初始化成功。这里有一个特别注意格式化操作会生成一个新的namespaceID如果之前已经初始化过一次再格式化会导致DataNode里的clusterID与NameNode不一致启动时DataNode会报错并退出。所以如果你后面因为某些原因想重新部署不要只重复执行格式化命令要把dfs.namenode.name.dir和dfs.datanode.data.dir指向的目录先清空再重新格式化否则踩的就是“DataNode启动失败”的坑。4.2 启动HDFS和YARN格式化完成执行start-dfs.sh脚本会依次启动NameNode、DataNode和SecondaryNameNode。启动过程日志输出在logs/hadoop-用户-datanode-主机名.log等文件里。启动完HDFS再启动YARNstart-yarn.sh它会启动ResourceManager和NodeManager。进程是否全都正常最直接的验证方式是用jps命令[rootlocalhost ~]# jps 12345 NameNode 12346 DataNode 12347 SecondaryNameNode 12348 ResourceManager 12349 NodeManager这五个进程一个都不能少。如果只是部分进程存在说明某个组件启动失败需要立刻去检查对应日志。4.3 Web界面验证与HDFS基本操作HDFS的NameNode管理界面默认在http://localhost:9870Hadoop 3.x能看到节点状态、存储容量、目录树。YARN的ResourceManager界面在http://localhost:8088可以看到正在运行和已完成的应用列表。文件系统层面做一次完整体验hdfs dfs -mkdir -p /test/input hdfs dfs -put /etc/profile /test/input/ hdfs dfs -ls /test/input能正常读写说明HDFS链路已经打通。接下来可以跑一个最简单的MapReduce任务来验证YARN链路。官方自带的示例包是个好选择hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /test/input /test/output跑完查看输出hdfs dfs -cat /test/output/part-r-00000如果能看到profile 48之类的结果说明MapReduce、YARN、HDFS三个层面全部工作正常。到这一步单机版部署测试算是真正完成了。5. 常见启动失败排查思路从日志倒推原因5.1 NameNode启动失败的定位路径NameNode启动失败通常伴随现象start-dfs.sh执行完jps里没有NameNode或者进程启动几秒后自动退出。这时候不要盲目重启按步骤来排查打开logs/hadoop-用户名-namenode-主机名.log查看错误堆栈。如果日志里出现Cannot create directory ... Permission denied是目录权限问题用chown -R 用户:用户组 /usr/local/hadoop解决。如果日志里出现java.io.IOException: NameNode is not formatted说明没有执行格式化或者格式化目录与实际配置目录不一致。如果出现端口占用Address already in use用netstat -anp | grep 9000查看端口占用进程清理后重启。多数的NameNode问题都出在目录权限和格式化状态这两项检查完问题基本能定位。5.2 DataNode起不来的典型场景clusterID不一致这是伪分布式部署里经典中的经典前面已经提到过重复执行了namenode -format导致NameNode的clusterID变化但DataNode目录里保存的是旧的clusterID启动时DataNode连接NameNode校验失败直接退出。DataNode日志里通常出现ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: Initialization failed for block pool ... java.io.IOException: Incompatible clusterIDs解决方法有两种彻底清理重来删除dfs.namenode.name.dir和dfs.datanode.data.dir下的所有内容重新格式化再启动。临时修改找出DataNode的VERSION文件把clusterID改成当前NameNode的clusterID。这个方法只适合应急不推荐作为常规操作。生产环境不会让你随意格式化所以这个坑在单机学习阶段踩一次印象会很深以后搭建真集群时会主动避开。5.3 YARN页面访问不了先确认进程再查端口如果你按照上述步骤配置完jps显示ResourceManager存在但浏览器访问http://localhost:8088没反应需要按照下面的顺序排查确认ResourceManager进程是否真的在运行。存在一种情况进程被启动又立刻被杀掉jps输出的结果有时候是残留的临时状态。检查端口监听状态netstat -anp | grep 8088没有监听就是没起来。查看ResourceManager启动日志确认是否是mapreduce_shuffle没配导致的Nodemanager连接异常这会让ResourceManager进入standby或者快速退出。如果是浏览器本身的问题尝试curl http://localhost:8088看看能不能拿到HTML返回。90%的YARN问题集中在shuffle服务配置和资源内存参数上前者是我们已经做掉的后者可以参考这个参数避免内存溢出property nameyarn.nodemanager.resource.memory-mb/name value2048/value /property property nameyarn.scheduler.maximum-allocation-mb/name value2048/value /property数值根据你的机器内存微调单机环境2GB起步够用机器内存只有4GB的把两个参数都调成1536更稳。6. 部署完之后的进阶测试和后续学习建议6.1 用一个更接近真实的数据集跑通全链路如果你已经成功跑完官方的wordcount示例恭喜你基础设施已经没问题了。但我的建议是别急着庆祝再做一个稍微复杂一点的测试——用一份结构化文本做分组统计。比如生成一个CSV模拟日志文件mkdir -p /tmp/testdata for i in {1..1000}; do echo user$(($RANDOM % 10)),event_type_$(($RANDOM % 5)),$(date %s) /tmp/testdata/events.log done上传到HDFS后写一个简短的MapReduce统计每个用户的操作次数重点体验分区、shuffle、归并的过程。这是单机版部署完最值得做的第二步——因为部署本身是手段理解数据在HDFS和MapReduce之间的流动才是目的。6.2 接下来有几个方向可以选择单机版部署完成之后学习路径的岔路口很多我身边人走下来比较有效的是这条路线先深入学习HDFS尝试手动模拟NameNode故障恢复观察SecondaryNameNode的检查点机制体验dfsadmin -report等命令。再理解YARN的调度逻辑在单机上同时提交两个作业观察资源分配和排队情况。之后可以过渡到完全分布式先在虚拟机里克隆2-3台节点把单机的配置经验平移过去重点解决网络互通与配置分发问题。更进阶的路线是引入容器化环境在容器里跑Hadoop集群隔离性更好重现环境更简单但前提依然是需要你理解单机版的配置原理。如果打算通过认证或者面试建议亲手记录一份部署测试报告把每个配置文件参数的用途、启动失败的日志定位、故障恢复的步骤都写清楚。这种实战记录比背面试题要扎实得多。6.3 我在多次部署后的几点体会这么多轮部署下来我的感受是单机版部署最大的价值不在于“装成功”本身而在于它强迫你理解Hadoop各组件的职责边界和协作方式。一开始我犯过一个错误看到start-dfs.sh执行后所有进程都起来了就以为部署完成了结果一跑MapReduce作业发现task一直卡住不执行查了半天最后发现是yarn-site.xml里没有配mapreduce_shuffle。那种时刻你会意识到跑通示例和真正理解框架是两码事。所以建议你也把部署过程中的每一步都当成一次学习实验来对待尤其是异常日志不要只看报错信息要追踪日志文件理解组件间互相调用失败的模式。踩过一次NameNode格式化的坑后面学习集群的高可用、联邦等架构时脑子里自然就有画面了。最后分享一个小技巧部署时养成看日志的习惯不用每次出错就去网上搜“Hadoop xxx报错”先看logs/目录下对应进程的.log文件把关键错误行复制出来再结合配置定位排查速度远比盲目试命令要快。这个习惯一旦养成以后跑其他分布式组件也受益。