李枝蔚第一次搭 Hadoop 完全分布式集群，我照着网上的教程敲了一整天，NameNode 起不来、DataNode 连不上，最后发现是 /etc/hosts 里多了一个空格。这种“配置全对但就是跑不起来”的体验，估计每个搭过集群的人都经历过。这篇文章把我从零到一把三节点完全分布式集群跑通的完整过程，包括踩过的坑、报错信息背后的原理、每一步为什么要这么配，一次性写清楚。不管你是课程设计要交差，还是想在本地搞一套测试环境做实验，按这个流程走完，能少走不少弯路。
1. 先把架构讲明白：完全分布式和那些“起不来”的根子
1.1 三大组件在集群里到底怎么协作
在展开配置之前，先说清楚完全分布式集群里到底有哪些角色。Hadoop 的底层存储是 HDFS，计算框架是 MapReduce，资源调度靠 YARN。这三部分的进程各有分工：HDFS 里有 NameNode 和 DataNode，YARN 里有 ResourceManager 和 NodeManager，另外还有 SecondaryNameNode 这个辅助角色。
NameNode 负责整个文件系统的元数据，可以理解成图书馆的总目录；DataNode 负责真正存放数据块，相当于书架上的实体书。客户端要读一个文件，先去找 NameNode 问“这个文件在哪些节点上”，然后拿着地址去对应 DataNode 拉数据。这也是为什么 NameNode 挂了整个集群就不可用——它是 HDFS 的单点。
ResourceManager 是 YARN 的大脑，负责接收客户端提交的计算任务并分配资源；NodeManager 是每台机器上的执行者，负责启动和监控容器。SecondaryNameNode 这个名字很有迷惑性，它并不是 NameNode 的热备节点，它的职责是定期合并 NameNode 的编辑日志（edits）和镜像文件（fsimage），为的是让 NameNode 重启时恢复得快一点，防止日志无限膨胀。这个区别也是面试里经常被问到的点。
1.2 配置全对还是失败，问题多半出在这四个前置条件
我先按三节点集群来规划：node01 作为主节点，跑 NameNode、ResourceManager、SecondaryNameNode；node02 和 node03 作为工作节点，跑 DataNode 和 NodeManager。如果机器不够，也可以让 node01 同时当 DataNode 和 NodeManager，但那样主节点负载会高一些，测试环境无所谓，生产环境不建议这么干。
除了角色规划，还有四个前置条件是最容易被忽略的：
- 内存。Hadoop 的进程本来就是 JVM 进程，光一个 NameNode 就默认占用 1G 左右的堆内存，加上 ResourceManager、NodeManager，每台机器至少要有 2G 内存，否则后面跑 MapReduce 任务时很容易 OOM。
- 时钟同步。集群内节点时间差太大会导致心跳异常甚至认证失败，本地测试环境如果时间差不大还好，但最好统一一下时间，否则后面排查问题时很难想到这一层。
- 网络。保证各节点 IP 固定，
/etc/hosts内容一致，防火墙要放行集群通信端口，或者直接关掉防火墙。 - SSH 免密登录。
start-dfs.sh和start-yarn.sh启动时会通过 SSH 远程到所有节点拉起进程，没有免密只能手动一台台启动，集群脚本就完全失去了意义。
这四个条件里，我见过太多人挂在第 3 个和第 4 个上：hosts 文件写错、SSH 免密配不完全，结果启动脚本报错的时候，日志里根本看不到明确信息。先把这个基础打好，后面配置文件的坑反而都是明面上的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三台机器的准备：版本选型与基础环境
2.1 JDK 和 Hadoop 版本怎么搭配最稳
版本选择是一个经常被忽略但决定成败的环节。我建议用 Hadoop 3.3.6（或 3.3.x 的最新小