1. 项目概述这不是装个软件而是搭一座数据工厂的地基“大数据生态系统Hadoop的安装部署”——这九个字背后不是一条命令敲完就能跑起来的玩具而是一整套分布式计算基础设施的物理落成。我带过三届某高校实验室的实训项目每次开课前第一件事就是让学员亲手把 Hadoop 集群从零搭起来。为什么非得自己装因为跳过这一步后面所有 MapReduce、Spark 作业、Hive 查询、HBase 写入全都会变成黑盒里的幻影。你调不通一个hdfs dfs -ls /就永远不知道 NameNode 是在监听 9000 还是 8020DataNode 是卡在 SSH 免密登录失败还是磁盘挂载点权限没放开。Hadoop 不是“开箱即用”的应用它是一套需要你亲手拧紧每一颗螺丝的重型机械。它的核心价值在于把廉价 x86 服务器变成一台逻辑上统一、存储与计算可线性扩展的超级计算机。而安装部署就是把这台机器的底盘、传动轴、油路和电路全部接通的过程。关键词里反复出现的“大数据生态系统”指的正是以 HDFS 为存储底座、YARN 为资源调度中枢、MapReduce 为原生计算引擎并向外延伸出 Hive、HBase、Spark、Flink 等组件的完整技术栈。今天我们要做的就是把这个生态最底层、最硬核的那块基石——Hadoop 3.x 分布式集群——稳稳地夯进你的物理或虚拟机环境里。无论你是刚学完 Java 基础想进大数据领域的新人还是运维老手要给测试环境配一套最小可行集群这套部署方案都经过了上百次实操验证它不依赖 Docker 或 Kubernetes 这类抽象层直面 Linux 权限、网络配置、JVM 参数这些真实世界里的毛刺它不追求一键脚本的虚假便捷而是让你每一步都清楚“我在改什么、为什么这么改、不这么改会怎样”。接下来的内容没有一句是教科书复述全是我在机房里蹲着看日志、改配置、重装系统时记下的血泪笔记。2. 整体设计与思路拆解为什么选伪分布完全分布双模式而不是直接上云2.1 为什么拒绝“一键安装包”和“Docker Compose 快速启动”市面上确实有各种 Hadoop 一键安装脚本甚至还有封装好的 Docker 镜像几条命令就能拉起一个“看起来能跑”的集群。但我在某公司做内部培训时发现用这类方案的学员三个月后连hdfs namenode -format执行失败的原因都查不出来。问题出在抽象层级太高Docker 把/etc/hosts、SSH 密钥分发、Java 环境变量隔离、日志路径挂载这些底层细节全吞掉了一键脚本则把core-site.xml和hdfs-site.xml的关键参数硬编码进 shell 变量里你根本看不到它们长什么样。真正的生产环境不会给你一个预装好的容器它只给你一台裸机、一个 root 密码、一段网络策略文档。所以我们的设计起点非常明确必须暴露所有配置项必须手动控制每一个服务进程的启停必须能随时进入任意节点的 shell 查看实时状态。这不是复古而是建立“系统直觉”的必经之路。就像学开车不能只坐自动驾驶汽车你得亲手感受离合器的咬合点、方向盘的虚位、刹车的点头感——Hadoop 的jps输出、tail -f logs/hadoop-xxx-namenode-xxx.log的滚动日志、netstat -tuln | grep 9870的端口监听状态就是这个系统的“驾驶反馈”。2.2 伪分布模式单机上的“微缩沙盒”专治概念模糊症很多初学者一上来就想搞三台虚拟机搭完全分布集群结果卡在 SSH 免密登录三天。我们反其道而行之先在一台机器上跑伪分布Pseudo-Distributed模式。这不是妥协而是精准打击认知盲区。伪分布意味着NameNode、DataNode、ResourceManager、NodeManager 全部跑在同一台机器的不同 JVM 进程里但它们严格遵循分布式架构的通信协议和配置逻辑。HDFS 的客户端依然要通过hdfs://localhost:9000访问YARN 的 ApplicationMaster 依然要向 ResourceManager 申请 Container只是这些“远程”调用实际走的是本地回环地址。这种模式的价值在于它用最低硬件成本100% 复现了分布式环境的核心约束——比如 DataNode 必须向 NameNode 定期发送心跳默认3秒如果 NameNode 持续收不到心跳就会把该 DataNode 标记为 dead再比如 YARN 的 NodeManager 启动后必须能被 ResourceManager 识别并纳入资源池否则yarn node -list就永远为空。你在单机上调试通了这些机制再扩到多机只是把localhost换成真实 IP把免密登录从本机扩展到多机思维模型完全平移。我见过太多人在三节点集群里start-dfs.sh报错却连hadoop fs -ls /在伪分布下是否成功都懒得验证——这就像没学会走路就想跑马拉松。2.3 完全分布模式三节点黄金组合平衡学习深度与资源消耗当伪分布稳定运行后我们立刻升级到三节点完全分布Fully-Distributed集群。为什么是三台而不是两台或五台这是经过大量教学实践验证的“黄金比例”。两节点存在单点故障风险如果 NameNode 和 ResourceManager 都挤在一台机器上它一宕机整个集群就瘫痪你无法体会高可用HA的必要性五节点则徒增管理复杂度光是同步/etc/hosts、分发密钥、检查每台机器的磁盘空间就可能耗掉半天时间冲淡对核心原理的关注。三节点分工明确Node1 专职 NameNode ResourceManager主控节点Node2 和 Node3 均作为 DataNode NodeManager工作节点。这个结构天然模拟了生产环境的主从架构同时留出了冗余空间——比如你可以把 Node1 的 SecondaryNameNode 单独拎出来或者后续把 ZooKeeper 集群部署在 Node2 上为 NameNode HA 做准备。更重要的是三节点能真实暴露网络问题当hdfs dfsadmin -report显示某个 DataNode 的状态是InDead你必须用ping、telnet、ss -tuln一层层排查是防火墙挡了 9866 端口还是/etc/hosts里 IP 和主机名映射错了还是 SELinux 拦截了 socket 绑定这些实战经验是任何文档都写不出来的。2.4 版本选择Hadoop 3.3.6 是当前最稳的“教学锚点”Hadoop 版本迭代很快但教学场景追求的是稳定性与文档完备性。我们锁定 Hadoop 3.3.6截至2024年中最新稳定版原因有三第一它彻底移除了对 JDK 7 的支持强制要求 JDK 8u161 或 JDK 11这迫使你直面现代 Java 环境的配置避免陷入“为什么我的 JDK 7 跑不起来”的无谓争论第二它默认启用了纠删码Erasure Coding和基于容器的 YARN 调度虽然教学中我们暂时不用但配置文件里能看到dfs.namenode.ec.system.default.policy这样的新参数让你感知到技术演进的方向第三它的官方文档和社区问答Stack Overflow、Hadoop 用户邮件列表关于 3.3.x 的内容最丰富遇到报错Google 一下错误码90% 的答案都是针对这个版本的。有人会问为什么不选最新的 3.4.x因为新版本往往伴随一些未被广泛验证的默认行为变更比如某个 RPC 超时参数的默认值调整可能导致你在某台特定配置的虚拟机上莫名卡住。教学的第一目标是“可预期”而不是“尝鲜”。就像学游泳先确保能在浅水区站稳再考虑深水区的蝶泳技巧。3. 核心细节解析与实操要点那些配置文件里藏着的魔鬼细节3.1 Java 环境不是装了 JDK 就万事大吉关键是“谁在用哪个 JDK”Hadoop 对 Java 的依赖极其苛刻。它不是一个普通 Java 应用而是一个由多个子项目HDFS、YARN、MapReduce组成的巨无霸每个子项目都可能有自己的 JVM 启动参数。很多人卡在第一步hadoop version报错JAVA_HOME is not set明明echo $JAVA_HOME显示路径正确。问题出在Shell 环境变量的作用域。Hadoop 的启动脚本如start-dfs.sh会重新加载自己的环境配置它读取的是$HADOOP_HOME/etc/hadoop/hadoop-env.sh里的JAVA_HOME而不是你.bashrc里设置的那个。所以你必须在hadoop-env.sh文件顶部取消注释并精确填写export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64注意路径必须是 JDK 的根目录不是 JRE 目录必须用绝对路径不能用~必须确认该路径下存在bin/java和lib/rt.jarJDK 11 后是lib/modules。我踩过的最大坑是在 Ubuntu 上用apt install openjdk-11-jdk安装后JAVA_HOME默认指向/usr/lib/jvm/java-11-openjdk-amd64但如果你的系统是 ARM 架构比如树莓派路径末尾应该是-arm64写错一个字母hadoop-daemon.sh就会静默退出日志里只有一行JAVA_HOME not found。验证方法很简单在hadoop-env.sh修改后执行source $HADOOP_HOME/etc/hadoop/hadoop-env.sh echo $JAVA_HOME确保输出和你写的完全一致。这是所有后续操作的基石宁可在这里花十分钟确认也不要等到start-dfs.sh失败后再回头翻日志。3.2 SSH 免密登录不是为了省事而是分布式通信的“信任握手”Hadoop 集群启动时主控节点NameNode/ResourceManager 所在机器需要通过 SSH 无密码登录到所有工作节点DataNode/NodeManager 所在机器去启动对应的守护进程。这不是一个便利性功能而是分布式协调的底层机制。start-dfs.sh脚本的实质就是遍历slaves文件Hadoop 3.x 改名为workers里的主机名对每一台执行ssh hostname hadoop-daemon.sh start datanode。如果 SSH 需要输密码脚本就卡在那里永远不会继续。配置步骤看似简单但细节决定成败首先在主控节点生成密钥对ssh-keygen -t rsa -P -f ~/.ssh/id_rsa-P 表示空密码这是关键其次把公钥id_rsa.pub的内容用ssh-copy-id -i ~/.ssh/id_rsa.pub userworker1命令追加到每个工作节点的~/.ssh/authorized_keys文件末尾最后也是最容易被忽略的确保所有节点的~/.ssh目录权限是 700authorized_keys文件权限是 600。Linux 的 SSH 服务极其严格如果authorized_keys权限是 644它会直接拒绝使用该密钥报错Authentication refused: bad ownership or modes for directory /home/user/.ssh。我曾经在一个 CentOS 7 虚拟机上折腾了两小时就是因为scp传输时自动把权限改成了 644。解决方法是登录到工作节点执行chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys。记住这不是一次性的配置每次你重建虚拟机或重装系统都必须重复这个过程。3.3 HDFS 核心配置core-site.xml和hdfs-site.xml的参数哲学HDFS 的配置文件不是参数罗列而是一套分布式共识协议的文本化表达。core-site.xml定义了整个 Hadoop 生态的“世界观”其中最关键的参数是fs.defaultFSproperty namefs.defaultFS/name valuehdfs://node1:9000/value /property这个值告诉所有 Hadoop 客户端“默认的文件系统是运行在 node1 主机 9000 端口上的 HDFS”。注意这里写的是node1不是localhost或127.0.0.1。因为在完全分布模式下DataNode 进程启动后会向node1:9000发起注册请求如果这里写localhostDataNode 就会试图连接自己本机的 9000 端口而那个端口上根本没有 NameNode 在监听。hdfs-site.xml则定义了 HDFS 自身的“宪法”核心参数是dfs.namenode.name.dir和dfs.datanode.data.dirproperty namedfs.namenode.name.dir/name valuefile:///opt/hadoop/data/namenode/value /property property namedfs.datanode.data.dir/name valuefile:///opt/hadoop/data/datanode/value /property这两个路径一个是 NameNode 存储元数据文件系统树、块映射关系的地方一个是 DataNode 存储实际数据块的地方。它们必须是绝对路径且目录必须存在、可写。我建议统一放在/opt/hadoop/data/下而不是默认的/usr/local/hadoop/...因为/opt是 Linux 标准的第三方软件数据存放目录语义清晰。创建目录后务必执行chown -R hadoop:hadoop /opt/hadoop/data假设你用hadoop用户运行服务否则启动时会报Permission denied。还有一个隐藏陷阱dfs.replication默认值是 3意思是每个文件块会复制三份。但在单节点伪分布模式下你只有 1 个 DataNodeHDFS 会拒绝写入报错File /test.txt could only be replicated to 0 nodes instead of minReplication (3)。解决方案是在伪分布模式下临时将dfs.replication改为1等切换到三节点集群时再改回3。这个参数的调整就是理解“副本数”与“可用 DataNode 数量”之间硬约束的最好课堂。3.4 YARN 核心配置yarn-site.xml里的资源博弈YARN 是 Hadoop 的资源管家它负责把集群的 CPU、内存切分成一个个“容器”Container分给 MapReduce、Spark 等计算框架使用。yarn-site.xml的配置本质上是在回答一个问题“我有多少资源可以分怎么分才公平”最关键的三个参数是property nameyarn.resourcemanager.hostname/name valuenode1/value /property property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property property nameyarn.nodemanager.resource.memory-mb/name value4096/value /property第一个参数yarn.resourcemanager.hostname和core-site.xml里的fs.defaultFS一样必须写主机名node1不能写localhost否则 NodeManager 无法注册到 ResourceManager。第二个参数yarn.nodemanager.aux-services值必须是mapreduce_shuffle这是 MapReduce 任务 Shuffle 阶段Map 输出传给 Reduce 输入所依赖的辅助服务如果写错或漏掉hadoop jar运行 WordCount 就会卡在ACCEPTED状态永远不变成RUNNING。第三个参数yarn.nodemanager.resource.memory-mb定义了每个 NodeManager 节点最多能提供多少内存给容器使用。假设你的工作节点有 8GB 内存这里设为40964GB是安全的因为操作系统、Hadoop 自身进程、DataNode 进程都需要内存。设得太高会导致节点 OOM内存溢出设得太低又浪费资源。一个经验法则是为每个工作节点预留 2GB 给系统和其他服务剩下的给 YARN。这个参数的调整会让你第一次真切感受到“资源调度”不是玄学而是可以用数字精确计算的工程实践。4. 实操过程与核心环节实现从零开始一步步把集群点亮4.1 环境准备三台虚拟机的标准化初始化以 Ubuntu 22.04 为例我们以最通用的 Ubuntu 22.04 LTS 为操作系统创建三台最小化安装的虚拟机VMware Workstation 或 VirtualBox 均可。每台分配 2 核 CPU、4GB 内存、40GB 硬盘。初始化步骤必须严格一致这是集群稳定的基础更新系统并安装基础工具sudo apt update sudo apt upgrade -y sudo apt install -y openjdk-11-jdk ssh curl wget vim net-tools注意openjdk-11-jdk是必须的ssh客户端和服务端都要装sudo apt install -y openssh-server openssh-clientnet-tools提供ifconfig和netstat比ip命令更直观。创建专用用户并配置 sudo 权限sudo adduser hadoop sudo usermod -aG sudo hadoop强烈建议不要用 root 用户运行 Hadoop创建hadoop用户既符合安全规范又能避免因权限混乱导致的奇奇怪怪的错误比如日志文件属主不对。配置静态 IP 和主机名映射 编辑/etc/netplan/00-installer-config.yamlUbuntu 22.04 使用 Netplan为每台机器分配固定 IPNode1主控192.168.56.101Node2工作192.168.56.102Node3工作192.168.56.103然后编辑/etc/hosts在所有三台机器上添加192.168.56.101 node1 192.168.56.102 node2 192.168.56.103 node3这是 Hadoop 集群的“电话簿”所有组件都靠这个映射来互相寻址。IP 和主机名之间必须用 Tab 键分隔不能用空格否则某些旧版 Hadoop 会解析失败。关闭防火墙教学环境sudo ufw disable生产环境当然要精细配置端口白名单但教学阶段关掉防火墙能避免 90% 的“连不上”问题。Hadoop 需要开放的端口非常多NameNode 9870, 9000; DataNode 9864, 9866; ResourceManager 8088; NodeManager 8042逐一配置太耗时。完成以上四步三台机器就变成了一个干净、统一、可预测的“画布”我们可以开始绘制 Hadoop 这幅巨作了。4.2 Hadoop 安装与分发解压、配置、同步的流水线下载与解压 在 Node1 上用wget下载 Hadoop 3.3.6 二进制包hadoop-3.3.6.tar.gz然后解压到/opt/目录cd /opt sudo wget https://downloads.apache.org/hadoop/common/hadoop-3.3.6/hadoop-3.3.6.tar.gz sudo tar -xzf hadoop-3.3.6.tar.gz sudo mv hadoop-3.3.6 hadoop sudo chown -R hadoop:hadoop /opt/hadoop关键点chown必须在解压后立即执行确保hadoop用户拥有整个目录的完全控制权。配置hadoop-env.sh 编辑/opt/hadoop/etc/hadoop/hadoop-env.sh找到export JAVA_HOME这一行修改为export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64并取消注释export HADOOP_OPTS-Djava.security.krb5.conf/etc/krb5.conf这一行即使不用 Kerberos也要保留避免某些发行版报错。配置核心 XML 文件core-site.xml设置fs.defaultFS为hdfs://node1:9000hdfs-site.xml设置dfs.namenode.name.dir和dfs.datanode.data.dir为/opt/hadoop/data/...dfs.replication设为1伪分布或3完全分布yarn-site.xml设置yarn.resourcemanager.hostname为node1yarn.nodemanager.aux-services为mapreduce_shuffleworkers文件在完全分布模式下删除localhost写入node2和node3每行一个分发到所有节点 在 Node1 上用scp把整个/opt/hadoop目录同步到 Node2 和 Node3scp -r /opt/hadoop hadoopnode2:/opt/ scp -r /opt/hadoop hadoopnode3:/opt/注意scp命令本身也依赖 SSH 免密登录所以这一步能成功就证明你的 SSH 配置已经 OK 了。同步完成后登录到 Node2 和 Node3执行chown -R hadoop:hadoop /opt/hadoop确保权限一致。4.3 伪分布模式启动与验证用五个命令建立信心伪分布模式是信心的起点。在 Node1 上以hadoop用户身份执行以下命令格式化 NameNode/opt/hadoop/bin/hdfs namenode -format这是 HDFS 的“初始化硬盘”操作它会在dfs.namenode.name.dir指定的路径下创建初始的元数据文件。首次运行会输出一大段日志最后一行是Storage directory ... has been successfully formatted.看到这个你就成功了一半。启动 HDFS/opt/hadoop/sbin/start-dfs.sh这个脚本会启动 NameNode在本机和 DataNode也在本机。执行后用jps命令查看进程jps # 应该看到NameNode, DataNode, Jps启动 YARN/opt/hadoop/sbin/start-yarn.sh同样用jps查看jps # 应该看到NameNode, DataNode, ResourceManager, NodeManager, Jps验证 HDFS 健康状态/opt/hadoop/bin/hdfs dfsadmin -report输出中Configured Capacity应该是一个正数DFS Used%应该是 0%Live datanodes数量应该是 1。如果看到Dead datanodes说明 DataNode 没起来回去检查hadoop-env.sh和hdfs-site.xml。运行一个经典测试echo Hello Hadoop World input.txt /opt/hadoop/bin/hdfs dfs -mkdir -p /user/hadoop/input /opt/hadoop/bin/hdfs dfs -put input.txt /user/hadoop/input/ /opt/hadoop/bin/hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /user/hadoop/input /user/hadoop/output /opt/hadoop/bin/hdfs dfs -cat /user/hadoop/output/part-r-00000这个 WordCount 例子会把input.txt上传到 HDFS运行 MapReduce 计算把结果写回 HDFS最后打印出来。如果最终输出Hello 1Hadoop 1World 1恭喜你你的伪分布集群已经活了这五个命令就是 Hadoop 的“Hello World”它比任何理论讲解都更能让你触摸到分布式计算的脉搏。4.4 完全分布模式启动与排障从单机到集群的跃迁当伪分布稳定运行后我们进行最关键的跃迁把 DataNode 和 NodeManager 进程从 Node1 迁移到 Node2 和 Node3。修改配置切换模式在hdfs-site.xml中把dfs.replication从1改为3在workers文件中确保只有node2和node3删除localhost在所有节点的core-site.xml和yarn-site.xml中确认fs.defaultFS和yarn.resourcemanager.hostname都指向node1清理旧数据重新格式化 因为现在是多节点NameNode 的元数据和 DataNode 的数据块必须重新对齐。在 Node1 上# 清理 NameNode 数据 rm -rf /opt/hadoop/data/namenode/* # 清理所有 DataNode 数据需要分别登录到 node2 和 node3 执行 ssh node2 rm -rf /opt/hadoop/data/datanode/* ssh node3 rm -rf /opt/hadoop/data/datanode/* # 重新格式化 /opt/hadoop/bin/hdfs namenode -format启动集群 在 Node1 上依次执行/opt/hadoop/sbin/start-dfs.sh # 启动 HDFSNameNode 在 node1DataNode 在 node2/node3 /opt/hadoop/sbin/start-yarn.sh # 启动 YARNResourceManager 在 node1NodeManager 在 node2/node3核心验证命令hdfs dfsadmin -report应该显示Live datanodes 2并且node2和node3的 IP 和状态都正常。yarn node -list应该显示两个RUNNING状态的 NodeManager。hdfs dfs -ls /应该能列出根目录证明 HDFS 可读。hadoop fs -du -h /查看 HDFS 各目录的磁盘使用情况确认数据真的分布在不同节点上。如果hdfs dfsadmin -report显示Dead datanodes这就是典型的“排障练兵场”。我总结了一个快速排查流程表现象可能原因排查命令解决方案node2显示Dead但node3正常node2的 DataNode 进程未启动ssh node2 jps登录node2执行/opt/hadoop/sbin/hadoop-daemon.sh start datanodenode2和node3都Deadnode1的 NameNode 没起来或workers文件配置错误jpson node1;cat /opt/hadoop/etc/hadoop/workers检查 NameNode 进程确认workers文件里没有空行或多余字符node2Deadjps显示 DataNode 进程存在DataNode 无法连接 NameNodessh node2 telnet node1 9000检查node1的防火墙检查node1的/etc/hosts是否正确解析node1这个表格是我过去三年在实验室里帮学员解决的前 100 个问题的精华浓缩。它不教你理论只告诉你“看到什么就做什么”这才是工程实践的真谛。5. 常见问题与排查技巧实录那些让你抓狂却又无比珍贵的“坑”5.1 “Connection refused” 错误网络层的无声杀手这是完全分布模式下最常见、也最容易让人崩溃的错误。当你在 Node1 上执行start-dfs.sh日志里疯狂刷Connection refused或者hdfs dfsadmin -report一直卡住不动。别急着重装先做三件事确认 NameNode 端口是否监听在 Node1 上执行ss -tuln | grep 9000。如果没有任何输出说明 NameNode 根本没起来。这时候去看/opt/hadoop/logs/hadoop-hadoop-namenode-node1.log的最后 20 行通常会看到java.net.BindException: Address already in use意思是 9000 端口被其他程序占用了。解决方案sudo lsof -i :9000找出 PIDsudo kill -9 PID杀掉它。确认 DataNode 能否访问 NameNode在 Node2 上执行telnet node1 9000。如果显示Connected to node1说明网络通如果显示Connection refused说明要么node1的防火墙开着要么node1的 NameNode 进程没起来要么node1的/etc/hosts里node1解析到了错误的 IP比如127.0.1.1。telnet是最原始、也最可靠的网络连通性测试工具比ping有用得多因为它测试的是 TCP 端口。确认主机名解析是否正确在 Node2 上执行getent hosts node1。它应该返回192.168.56.101 node1。如果返回空或者返回了错误的 IP问题就出在/etc/hosts文件。Linux 的getent命令会按/etc/nsswitch.conf的顺序查询能准确反映系统真实的解析行为比ping node1更可靠。这三个命令构成了一个坚不可摧的“网络三叉戟”90% 的连接问题都能被它斩于马下。记住分布式系统的问题80% 出在网络和配置上而不是代码逻辑上。5.2 日志文件你最忠实、也最啰嗦的“技术顾问”Hadoop 的日志是解决问题的唯一真相来源。它的日志文件分散在$HADOOP_HOME/logs/目录下命名规则是hadoop-user-daemon-hostname.log。比如hadoop-hadoop-namenode-node1.log就是 Node1 上 NameNode 的日志。新手常犯的错误是一出错就百度错误信息结果被各种过时的、针对旧版本的解决方案带偏。正确的做法是打开日志从最后一行往前看找到第一个ERROR或FATAL级别的记录然后仔细读它前面的几行上下文。日志不是小说它是按时间倒序写的“事故报告”。举个真实案例某学员的 DataNode 总是启动几秒后就自动退出jps看不到它。他翻遍了 Google试了各种“修改 ulimit”、“增加 swap”的方案都没用。我让他发给我hadoop-hadoop-datanode-node2.log的最后 50 行。里面有一行ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: Exception in secureMain java.io.IOException: All directories in dfs.datanode.data.dir are invalid: ...再往前翻看到WARN org.apache.hadoop.util.DiskChecker: Incorrect permission for /opt/hadoop/data/datanode, expected: rwxr-xr-x, current: rwxrwxr-x真相大白他用chmod 777给了datanode目录满权限而 Hadoop 的安全策略要求 DataNode 目录必须是755不能有w权限给 group 和 others。解决方案chmod 755 /opt/hadoop/data/datanode。这个错误任何搜索引擎都很难精准匹配但日志里清清楚楚写着。所以我的第一条实操心得是养成习惯任何问题先看日志任何日志先看 ERROR 行任何 ERROR 行先看它前面的 WARN 和 INFO 行。日志是你最好的老师只是它说话有点啰嗦。5.3 “Safe mode” 陷阱NameNode 的自我保护机制当你执行 hdfs dfsadmin -safemode get