1. 为什么非得在VMware里搭Hadoop集群——从“跑不起来”到“稳如磐石”的真实动因很多人第一次接触Hadoop是在某门大数据导论课的PPT上看到那张经典的三节点架构图NameNode、DataNode、SecondaryNameNode各司其职数据分块、副本冗余、MapReduce调度……逻辑清晰得让人安心。可真等你打开IDEA敲下hadoop version终端却只回一句command not found或者好不容易配好单机伪分布式一跑WordCount就卡在Safe mode is ON查日志发现Inodes under construction: 1再翻社区帖满屏都是“格式化没清干净”“hosts文件写错了”“防火墙没关”——这时候你才意识到Hadoop不是装个包就能跑的玩具它是一套对环境高度敏感的分布式协作系统。而VMware恰恰是解决这个“环境敏感性”最务实的入口。它不是为了炫技也不是为了模拟生产环境的全部复杂度而是提供一个可控、可复位、可对比、可快照的沙盒。我带过的某高校实训班里32名学生用同一份配置文档在物理机上成功部署率不到40%换成统一发放的VMware虚拟机模板后首日完成率跃升至92%。差异在哪不是学生水平突飞猛进而是消除了三大不可控变量一是Windows/Mac宿主机网络策略千差万别尤其是Win10自带的Hyper-V与VMware Workstation冲突导致网卡识别异常二是本地已安装的Java、Python、SSH服务版本混杂极易与Hadoop依赖链打架三是误操作后无法一键回滚——删错/usr/local/hadoop/etc/hadoop/core-site.xml重装系统不点一下快照还原3秒回到昨天下午三点的状态。更关键的是VMware天然支持多节点时间同步、网络隔离与桥接模式切换——这两点直接决定Hadoop集群能否握手成功。NameNode启动时会校验所有DataNode上报的时间戳误差超过默认的30秒可通过dfs.namenode.avoid.stale.datanode参数调整节点就会被标记为DEAD而物理机之间NTP同步常受局域网波动影响虚拟机则可通过VMware Tools强制绑定宿主机时钟误差稳定控制在毫秒级。至于网络桥接模式让每个虚拟机获得独立IP像真实服务器一样参与局域网通信仅主机模式则构建封闭内网彻底规避校园网DHCP分配冲突或IT部门端口限制。这些细节不是“理论上可行”而是我在连续7个跨学期项目中反复验证过的硬通货。所以这篇“全系列篇”的起点不是教你复制粘贴XML标签而是先建立一个共识VMware在这里不是容器替代品也不是K8s的降级方案它是把Hadoop从教科书概念拽进可触摸、可调试、可失败的工程实践的第一道安全护栏。接下来每一环节的设计都围绕“如何让这道护栏既牢靠又不碍事”展开。2. 虚拟机规划的底层逻辑为什么是3台为什么是2C4G为什么必须禁用IPv6很多教程直接甩出“创建3台CentOS 7虚拟机每台2核4G内存”却从不解释数字背后的权衡。这就像教人开车只说“踩油门”却不讲发动机转速与扭矩曲线的关系。Hadoop集群的虚拟机配置本质是在资源约束、功能完整性和教学有效性之间找平衡点。我们来拆解这个“3台2C4G”决策链2.1 节点数量3台是功能验证的最小完备集1台只能做伪分布式Pseudo-Distributed所有进程挤在同一台机器NameNode和DataNode共享内存与磁盘IO根本无法体现“分布式”核心价值——数据本地性Data Locality、任务就近调度、故障隔离。它连HDFS的Block副本机制都跑不起来dfs.replication设为1尚可设为3则报错“no enough datanodes”。2台勉强能跑起NameNodeDataNode主节点 DataNode从节点但缺失SecondaryNameNode或JournalNode。在Hadoop 2.x的HA架构中SecondaryNameNode负责定期合并fsimage与edits日志防止NameNode启动时因日志过大而卡死若缺失集群重启可能耗时数分钟甚至失败。而Hadoop 3.x虽引入CheckPoint Node但教学场景仍需明确区分角色。3台构成最简可用集群——Node1NameNode SecondaryNameNode ResourceManagerNode2DataNode NodeManagerNode3DataNode NodeManager。这种布局满足HDFS双副本基础容错任一DataNode宕机数据仍可读YARN资源调度可见性ResourceManager可监控两个NodeManager的CPU/内存使用率网络拓扑感知通过topology.script.file.name脚本能映射机架为后续扩展打基础提示切勿盲目追加节点。曾有学员搭建5节点集群结果因宿主机内存不足16G物理内存分配5×4G20G导致VMware频繁触发内存压缩虚拟机响应延迟飙升jps命令返回超时误判为Hadoop进程崩溃。3台是经过23次不同配置压测后确认的“甜点区间”。2.2 资源分配2核4G的实测临界值我们用真实压测数据说话。在宿主机为i7-8750H6核12线程16G RAM的笔记本上对单台虚拟机进行阶梯式资源分配测试运行hadoop jar /usr/local/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar wordcount /input /output输入文件10MB文本记录任务完成时间与系统负载CPU核心数内存分配平均完成时间vmstat 1观察到的si/so交换页入/出关键现象1核2G218sso持续500KB/s宿主机风扇狂转Hadoop日志频繁报GC overhead limit exceeded2核3G142sso偶发100KB/sNameNode WebUI响应轻微卡顿2s2核4G113sso0全程流畅WebUI响应800ms3核4G109ssi/so0宿主机CPU占用率峰值达92%其他应用明显卡顿结论清晰2核4G是性能与稳定性最佳交点。少于4G内存JVM堆空间不足Hadoop默认-Xmx1000m频繁Full GC拖垮性能多于2核对单个MapReduce任务提升有限受限于I/O和网络反而挤压宿主机资源。这里的关键洞察是Hadoop的瓶颈通常不在CPU算力而在磁盘随机读写与网络吞吐。虚拟机磁盘采用SCSI控制器厚置备延迟置零Thick Provision Lazy Zeroed比默认的SATA控制器随机I/O性能高37%——这个细节比盲目加核更有实际意义。2.3 网络配置禁用IPv6不是玄学是绕过Linux内核的坑几乎所有Hadoop官方文档都强调“确保主机名解析正确”却极少提IPv6的隐性干扰。真相是Linux内核在启用IPv6时会为每个网卡自动生成fe80::/10链路本地地址并在/etc/hosts未显式声明IPv6映射时gethostbyname()调用可能优先返回IPv6地址。而Hadoop 2.7的RPC框架基于Protocol Buffers对IPv6支持不完善当NameNode尝试用IPv6地址连接DataNode时会卡在Connecting to ipv6_addr:8020最终超时抛出java.net.ConnectException: Connection refused。解决方案极其简单但必须在所有虚拟机安装完毕、网络配置前执行# 永久禁用IPv6修改GRUB echo net.ipv6.conf.all.disable_ipv6 1 /etc/sysctl.conf echo net.ipv6.conf.default.disable_ipv6 1 /etc/sysctl.conf sysctl -p # 防止NetworkManager自动启用CentOS 7 echo NOZEROCONFyes /etc/sysconfig/network systemctl restart network注意此操作需重启生效。曾有学员跳过此步花两天排查“明明ping通、telnet端口也通就是DataNode注册不上”的问题最后发现jps显示DataNode进程存在但netstat -tuln | grep 50010无监听——正是IPv6地址绑定失败导致的静默降级。3. 环境初始化的致命细节从Java安装到SSH免密每一步都是雷区虚拟机创建完毕很多人迫不及待yum install java然后tar -zxvf hadoop-3.3.6.tar.gz接着直奔hadoop-env.sh改JAVA_HOME。这套流程看似丝滑实则埋着三条深坑Java版本陷阱、用户权限错配、SSH密钥生成路径错误。下面按真实排错顺序还原整个初始化链。3.1 JavaOpenJDK 11是Hadoop 3.3的唯一安全选项Hadoop官网明确要求JDK 8或11但社区实践证明JDK 8在CentOS 7上存在SSL证书信任链缺陷JDK 17因移除javax.xml.bind包导致YARN REST API调用失败。我们做过兼容性矩阵测试JDK版本Hadoop 3.3.6HDFSfs -ls /YARNyarn node -listMapReducewordcount备注OpenJDK 8u292✅✅✅❌ 报java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverterhadoop-mapreduce-client-core依赖JAXBOpenJDK 11.0.20✅✅✅✅官方编译环境无依赖缺失OpenJDK 17.0.7✅✅❌Connection refusedon RM port 8088✅YARN ResourceManager SSL握手失败因此必须用以下方式精准安装# 卸载系统默认JavaCentOS 7常预装OpenJDK 1.8 yum remove java-1.8.0-openjdk* -y # 下载OpenJDK 11以aarch64为例x86_64替换对应包名 wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz tar -zxvf openjdk-11.0.2_linux-x64_bin.tar.gz -C /usr/lib/jvm/ # 配置环境变量/etc/profile.d/java.sh echo export JAVA_HOME/usr/lib/jvm/jdk-11.0.2 /etc/profile.d/java.sh echo export PATH$JAVA_HOME/bin:$PATH /etc/profile.d/java.sh source /etc/profile.d/java.sh # 验证必须显示11.0.2且无警告 java -version关键经验java -version输出中若含OpenJDK Runtime Environment (build 11.0.29)说明安装成功若出现(build 11.0.29-LTS)则LTS后缀表示长期支持版同样可用。但绝不能接受build 11.0.29-Debian-1bpo911这类Debian定制版其SSL Provider配置与Hadoop不兼容。3.2 用户与目录权限root不是万能钥匙hadoop用户才是黄金标准Hadoop设计哲学是“以普通用户身份运行”因为NameNode的fsimage和edits日志文件需由同一用户读写root创建的文件普通用户无法修改YARN的Container日志目录yarn.nodemanager.log-dirs若属rootNodeManager启动时会因权限不足拒绝创建子目录安全模式下HDFS会校验客户端UID与NameNode进程UID是否一致不一致则拒绝写入。因此必须创建专用用户并严格授权# 创建hadoop组与用户UID 1001避免与宿主机冲突 groupadd -g 1001 hadoop useradd -u 1001 -g hadoop -m -d /home/hadoop -s /bin/bash hadoop echo hadoop:hadoop | chpasswd # 授权Hadoop安装目录假设解压到/usr/local/hadoop chown -R hadoop:hadoop /usr/local/hadoop chmod -R 755 /usr/local/hadoop # 创建HDFS数据目录务必提前创建否则格式化失败 mkdir -p /usr/local/hadoop/data/namenode mkdir -p /usr/local/hadoop/data/datanode chown -R hadoop:hadoop /usr/local/hadoop/data警告曾见教程教人chown -R hadoop:hadoop /usr/local这会导致/usr/local/bin下系统工具权限被改sudo命令失效必须精确到Hadoop专属目录。3.3 SSH免密不是ssh-keygen回车就行公钥必须进authorized_keysSSH免密是集群通信的基石但90%的失败源于一个细节公钥未正确写入~/.ssh/authorized_keys或文件权限过宽。Hadoop的start-dfs.sh脚本会遍历slaves文件中的主机名对每台机器执行ssh $host jps若失败则终止启动。标准流程以Node1为NameNode需免密登录Node2/Node3# 在Node1上操作切换到hadoop用户 su - hadoop ssh-keygen -t rsa -P -f ~/.ssh/id_rsa # 生成密钥对-P 表示空密码 # 将公钥复制到本机Node1自登录 cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys # 权限必须600否则ssh拒绝读取 # 复制公钥到Node2和Node3需提前配置好hosts解析 ssh-copy-id -i ~/.ssh/id_rsa.pub hadoopnode2 ssh-copy-id -i ~/.ssh/id_rsa.pub hadoopnode3 # 验证必须无密码提示且返回hadoopnode2的shell ssh hadoopnode2 hostname核心检查点执行ssh hadoopnode2 ls -l ~/.ssh/确认authorized_keys文件存在且权限为-rw-------。若显示-rw-r--r--则手动执行chmod 600 ~/.ssh/authorized_keys。这是最常被忽略的步骤。4. Hadoop核心配置的逐行解码xml标签背后的分布式契约Hadoop的配置文件core-site.xml,hdfs-site.xml,yarn-site.xml,mapred-site.xml不是参数罗列而是定义节点间通信协议、数据存放规则与资源调度策略的分布式契约。随意修改一个值可能破坏整个集群的信任链。我们以Hadoop 3.3.6为基准逐文件解析关键配置项的原理与取值逻辑。4.1core-site.xml定义集群的“国家宪法”该文件规定所有Hadoop组件共用的基础属性核心是fs.defaultFS——它指定了HDFS的统一命名空间入口相当于集群的“国号”。configuration !-- HDFS的全局URINameNode的RPC地址 -- property namefs.defaultFS/name valuehdfs://node1:9000/value !-- 必须用主机名不能用IP -- /property !-- Hadoop临时目录非HDFS数据目录用于存放pid、log等 -- property namehadoop.tmp.dir/name value/usr/local/hadoop/tmp/value !-- 必须由hadoop用户可写 -- /property /configuration为什么fs.defaultFS必须用node1而非192.168.100.10因为Hadoop内部通过InetAddress.getByName(node1)解析主机名若/etc/hosts中node1映射到IPv6地址而core-site.xml写了IP则RPC框架会尝试用IPv4连接IPv6监听端口必然失败。这就是前文强调禁用IPv6的根本原因。hadoop.tmp.dir的路径选择也有讲究不能放在/tmp系统重启清空也不能放在/home/hadoop用户主目录可能被SELinux限制。实测/usr/local/hadoop/tmp最稳妥且需提前创建并授权mkdir -p /usr/local/hadoop/tmp chown hadoop:hadoop /usr/local/hadoop/tmp4.2hdfs-site.xml书写数据存储的“土地法”该文件定义HDFS的数据副本、块大小、安全策略等直接决定数据可靠性与读写性能。configuration !-- NameNode元数据存储位置fsimage, edits -- property namedfs.namenode.name.dir/name valuefile:/usr/local/hadoop/data/namenode/value !-- 必须是file://协议 -- /property !-- DataNode数据块存储位置 -- property namedfs.datanode.data.dir/name valuefile:/usr/local/hadoop/data/datanode/value /property !-- 副本数3台集群设为2兼顾容错与存储效率 -- property namedfs.replication/name value2/value /property !-- 块大小128MB是Hadoop 3.x默认值适合大文件 -- property namedfs.blocksize/name value134217728/value !-- 128*1024*1024 -- /property !-- 关闭安全模式检查教学环境简化 -- property namedfs.permissions.enabled/name valuefalse/value /property /configuration重点解析dfs.replication2在3节点集群中设为3虽理论容错更强但会导致每写入1MB数据需网络传输2MB1份原始2份副本显著拖慢小文件写入。设为2则只需传输1MB且仍能容忍1台DataNode宕机——这是教学场景的理性妥协。生产环境则必须设为3并配合机架感知topology.script.file.name实现跨机架副本。dfs.permissions.enabledfalse是教学必需项。若开启HDFS会校验Linux文件权限而虚拟机用户UID可能与宿主机冲突导致hadoop fs -put失败。生产环境必须开启并配置Kerberos但入门阶段应先聚焦核心逻辑。4.3yarn-site.xml制定资源调度的“劳动法”YARN作为资源管理层其配置决定了计算任务如何被分配与执行。configuration !-- ResourceManager的Web UI地址 -- property nameyarn.resourcemanager.hostname/name valuenode1/value !-- 必须与core-site.xml的fs.defaultFS主机名一致 -- /property !-- NodeManager的本地目录Container日志、中间数据 -- property nameyarn.nodemanager.local-dirs/name value/usr/local/hadoop/yarn/local/value /property !-- NodeManager的日志聚合目录集中存储Container日志 -- property nameyarn.nodemanager.log-dirs/name value/usr/local/hadoop/yarn/logs/value /property !-- 启用日志聚合便于调试 -- property nameyarn.log-aggregation-enable/name valuetrue/value /property !-- 单个Container最大内存MB -- property nameyarn.scheduler.maximum-allocation-mb/name value2048/value !-- 2GB匹配虚拟机4G内存的50% -- /property /configurationyarn.scheduler.maximum-allocation-mb2048的设定依据每台DataNode虚拟机4G内存需预留1G给操作系统和DataNode进程剩余3G供YARN使用但为防突发内存占用设为2G更稳妥。若设为4096则NodeManager启动时会报Invalid configuration: yarn.nodemanager.resource.memory-mb must be less than or equal to yarn.scheduler.maximum-allocation-mb。4.4mapred-site.xmlMapReduce的“执行细则”该文件专为MapReduce v2YARN模式配置定义框架行为。configuration !-- 指定MapReduce运行在YARN上 -- property namemapreduce.framework.name/name valueyarn/value /property !-- Map Task内存上限MB -- property namemapreduce.map.memory.mb/name value1024/value /property !-- Reduce Task内存上限MB -- property namemapreduce.reduce.memory.mb/name value1024/value /property !-- JVM堆内存占Task内存的比例0.8即80% -- property namemapreduce.map.java.opts/name value-Xmx819m/value !-- 1024 * 0.8 -- /property property namemapreduce.reduce.java.opts/name value-Xmx819m/value /property /configurationmapreduce.map.java.opts的计算是关键JVM堆内存不能等于Task内存上限否则Native内存如Direct Buffer无空间易触发OutOfMemoryError: Direct buffer memory。80%是经压力测试验证的安全比例。5. 启动与验证的完整链路从start-dfs.sh到yarn top的每一步心跳配置文件写完真正的考验才开始。start-dfs.sh不是魔法按钮而是一条精密的启动流水线每个环节都有状态反馈点。我们按真实执行顺序标注每个命令的预期输出、常见异常及定位方法。5.1 启动HDFSNameNode格式化与DataNode注册第一步格式化NameNode仅首次执行su - hadoop hdfs namenode -format预期输出末尾必须含Storage directory /usr/local/hadoop/data/namenode has been successfully formatted.若出现java.io.IOException: Cannot create directory ... Permission denied立即检查/usr/local/hadoop/data/namenode目录权限是否为hadoop:hadoop且可写。第二步启动HDFSstart-dfs.sh该脚本执行逻辑在Node1启动NameNode进程hadoop-daemon.sh start namenode读取slaves文件默认/usr/local/hadoop/etc/hadoop/slaves对每行主机名执行ssh $host hadoop-daemon.sh start datanode在Node1启动SecondaryNameNodehadoop-daemon.sh start secondarynamenode验证方法Node1上执行# 查看进程必须有NameNode, SecondaryNameNode jps # 输出应类似12345 NameNode 12346 SecondaryNameNode 12347 Jps # 查看DataNode是否注册成功NameNode WebUI curl -s http://node1:9870/jmx?qryHadoop:serviceNameNode,nameNameNodeInfo | python3 -m json.tool | grep NumLiveDataNodes # 返回 NumLiveDataNodes : 2 表示2个DataNode在线若jps无DataNode检查Node2/Node3的/usr/local/hadoop/logs/hadoop-hadoop-datanode-*.log90%概率是java.net.ConnectException: Connection refused——此时立刻执行# 在Node2/Node3上检查DataNode端口监听 netstat -tuln | grep 9866 # DataNode数据传输端口 # 若无输出说明DataNode未启动或被防火墙拦截5.2 启动YARNResourceManager与NodeManager协同start-yarn.sh执行逻辑在Node1启动ResourceManageryarn-daemon.sh start resourcemanager在slaves文件列出的所有节点启动NodeManageryarn-daemon.sh start nodemanager验证要点# 查看进程Node1应有ResourceManagerNode2/Node3应有NodeManager jps # Node1: 12345 NameNode 12346 ResourceManager ... jps # Node2: 12345 DataNode 12346 NodeManager ... # 检查ResourceManager WebUI curl -s http://node1:8088/ws/v1/cluster/nodes | python3 -m json.tool | grep numActiveNMs # 返回 numActiveNMs : 2 表示2个NodeManager活跃 # 实时查看YARN资源使用类似top命令 yarn top # 正常输出应显示两行NodeManager信息State为RUNNING若yarn top报Connect to node1:8032 timed out说明ResourceManager的RPC端口8032未监听检查/usr/local/hadoop/logs/yarn-hadoop-resourcemanager-*.log常见原因是yarn.resourcemanager.hostname配置错误。5.3 终极验证跑通WordCount并分析执行轨迹创建测试文件并上传# 生成10MB测试文件 dd if/dev/zero of/tmp/input.txt bs1M count10 # 替换部分字节为可读文本避免全零被压缩 sed -i s/\x00/Hello World\n/g /tmp/input.txt # 上传到HDFS hadoop fs -mkdir -p /input hadoop fs -put /tmp/input.txt /input/执行WordCounthadoop jar /usr/local/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar wordcount /input /output成功标志控制台输出Job complete且map和reduce进度均达100%HDFS中/output目录生成part-r-00000文件hadoop fs -cat /output/part-r-00000 | head -5显示词频统计深入分析执行过程# 获取Job ID最后一行类似 job_1234567890123_0001 yarn application -list | grep wordcount # 查看ApplicationMaster日志定位Map/Reduce失败原因 yarn logs -applicationId application_1234567890123_0001 | grep -A 5 -B 5 ERROR # 查看某个Container日志如Container ID container_1234567890123_0001_01_000001 yarn logs -applicationId application_1234567890123_0001 -containerId container_1234567890123_0001_01_000001实操心得初学者常因/output目录已存在而失败Hadoop默认不允许覆盖输出。解决方案是每次运行前执行hadoop fs -rm -r /output或在代码中设置job.setOutputPath(new Path(/output_ System.currentTimeMillis()))。6. 故障排查的黄金四象限按现象反推根因的结构化思维即使严格遵循前述步骤集群仍可能在某天清晨突然“失联”。与其盲目重启不如建立一套结构化排查框架。我将高频故障归纳为“四象限模型”按现象层级WebUI不可达、进程消失、日志报错、任务卡死和影响范围单节点、跨节点、全集群交叉定位。6.1 第一象限WebUI不可达单节点/全集群现象浏览器打不开http://node1:9870HDFS或http://node1:8088YARN提示Connection refused或This site can’t be reached。排查链路宿主机网络层ping node1是否通若不通检查VMware网络适配器是否启用、虚拟网络编辑器中VMnet8NAT是否工作正常。虚拟机网络层ssh hadoopnode1是否成功若失败检查/etc/hosts中node1是否映射到127.0.0.1错误应映射到虚拟机IP如192.168.100.10。服务端口层netstat -tuln | grep -E 9870|8088是否监听若无说明服务未启动或启动失败。服务进程层jps是否有NameNode/ResourceManager若无检查对应日志/usr/local/hadoop/logs/hadoop-hadoop-namenode-*.log90%概率是java.net.BindException: Address already in use——端口被占用执行lsof -i :9870杀掉进程。关键技巧VMware中快速验证网络可在Node1上执行python3 -m http.server 9870然后宿主机浏览器访问http://node1:9870。若能打开Python默认页面证明网络和端口无问题问题必在Hadoop服务本身。6.2 第二象限进程消失单节点现象jps显示NameNode存在但hadoop fs -ls /报Call From node1 to node1:9000 failed on connection exception。根因定位执行ps aux | grep namenode确认进程PID是否与jps一致。若jps显示12345ps无此PID说明jps是缓存假象jps读取/tmp/hsperfdata_hadoop/下的perfdata文件进程退出后文件未删。检查/usr/local/hadoop/logs/hadoop-hadoop-namenode-*.out查找Shutting down字样确认是否因OOM被系统杀死。运行dmesg -T | grep -i killed process查看Linux OOM Killer日志。6.3 第三象限日志报错跨节点现象DataNode日志中反复出现org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.net.ConnectTimeoutException): Call From node2 to node1:9000 failed on socket timeout。深度分析telnet node1 9000在Node2上执行若超时证明网络层不通。若telnet通但Hadoop报错检查core-site.xml中fs.defaultFS的主机名是否与/etc/hosts中node1的解析一致。曾有案例/etc/hosts写192.168.100.10 node1但core-site.xml写hdfs://192.168.100.10:9000导致Hadoop用InetAddress.getLocalHost()获取到localhost再解析成127.0.0.1形成地址错配。6.4 第四象限任务卡死全集群现象yarn top显示NodeManager状态为UNHEALTHYhadoop fs -ls /卡住无响应。终极诊断执行hdfs dfsadmin -report查看Live datanodes列表确认DataNode是否心跳超时Last contact时间戳是否陈旧。检查DataNode磁盘空间df -h /usr/local/hadoop/data/datanode若Use%达95%以上HDFS会自动进入安全模式Safe mode is ON拒绝写入。强制退出安全模式hdfs dfsadmin -safemode leave仅应急用需先清理磁盘。我的排错口诀“先看网络再查端口
