Hadoop集群高性能搭建：从节点规划到基础环境配置详解

1. 把"高性能"落到实处：先弄清楚Hadoop集群的性能瓶颈在哪

很多朋友一上来就照着教程敲命令，装完之后才发现集群跑起来很慢，或者动不动就卡死。其实这不是Hadoop本身的问题，而是从一开始就没搞明白"高性能"这三个字意味着什么。我做了几年大数据基础设施相关的工作，从测试环境一路折腾到生产集群，最大的感触是：Hadoop集群的性能不是装出来的，是规划出来的。这篇作为系列第一篇，先不讲那些花里胡哨的调优参数，而是把地基打牢——从节点规划、操作系统配置到基础环境搭建，把每一步的"为什么"讲透。

先对齐一下Hadoop集群的性能模型。一个典型的高性能集群，性能瓶颈基本逃不出四个维度：CPU、内存、磁盘I/O、网络带宽。很多人只关注CPU和内存，觉得配个高主频、大内存就够了。但真正的生产场景里，磁盘I/O才是最容易卡脖子的地方。MapReduce任务、HDFS读写、中间结果溢写，全是磁盘操作。我用过机械盘跑集群和用SSD/NVMe跑集群，性能差距不是百分之几十，是几倍甚至十几倍的差距。

网络也是一样。Shuffle阶段是MapReduce最耗时的环节之一，map端输出的中间数据要跨节点传输到reduce端，网络带宽不够，整个作业就卡在传输上。所以高规格的Spark/Hadoop集群，普遍会配万兆网卡，至少也要做千兆网卡的多链路绑定。

内存这块有个很容易被忽略的点：Hadoop的NameNode、ResourceManager这些主节点进程，以及DataNode、NodeManager这些从节点进程，JVM堆内存怎么分配，直接决定了它能支撑多大的元数据量和多少个并发任务。堆内存设小了，集群规模一大就频繁Full GC；设大了，系统留给操作系统页缓存的空间就少，HDFS读性能反而下降。这些都是后面要详细展开的内容。

所以这篇系列第一篇文章，我打算聚焦在最容易被忽视但也最重要的事情上：硬件的选型思路、操作系统的初始化、用户与目录规划、基础网络配置、JDK环境，以及SSH免密登录的建立。这些前置工作做砸了，后面装再多的组件也是白搭。

2. 集群节点规划与硬件选型：高性能是从机器分配开始的

2.1 主节点与从节点的角色拆分

很多新手搭集群，清一色用一模一样的配置。这其实是在浪费钱。Hadoop集群里的节点分两类：主节点（Master）和从节点（Worker）。主节点跑的进程是NameNode、ResourceManager、SecondaryNameNode这些，特点是内存消耗大、CPU要求中等、磁盘I/O要求不高。从节点跑的进程是DataNode、NodeManager，特点是磁盘I/O密集、内存和CPU消耗都大。

我在某实验室搭过一套三节点集群，当时是1主2从的配置。主节点重点关注内存，给了64GB，CPU反而只用了8核。从节点则是32GB内存加8核CPU，但磁盘全部用了NVMe SSD。这套配置跑起TeraSort和WordCount这种测试作业，性能比我之前用均衡配置搭的集群好很多。原因是：主节点要管理整个集群的文件目录树和资源调度，内存就是它的命脉；从节点要干最重的读写活，磁盘就是它的命脉。

如果是个人学习环境，节点不够用，那就采用伪分布式模式，一台机器跑所有角色。这种模式对硬件的要求是：内存至少16GB，磁盘至少要留100GB给HDFS。如果你只有8GB内存，跑Hadoop会比较吃力，因为除了Hadoop进程，你的操作系统、终端、浏览器还要吃内存，内存一不够就开始疯狂交换，整个环境就废了。

2.2 磁盘规划：数据和日志分开，系统盘和数据盘分离

我见过不少人把Hadoop的数据目录直接放在系统盘上，这是个非常糟糕的做法。系统盘如果写满了，操作系统先挂，然后Hadoop的各种进程开始报错，最后日志把磁盘彻底塞满，整个集群就僵死了。

正确的规划方式是这样的：

磁盘格式化的文件系统建议用ext4或者xfs。我倾向于xfs，因为它在处理大文件和高并发读写时表现更好，而且xfs支持在线扩容，后期磁盘不够用的时候不用停机操作。格式化和挂载的细节我后面会用命令展示。

还有一个关键点：不要给DataNode只配一个数据目录。DataNode支持配置多个数据目录，挂载多块磁盘时，把每一块盘都挂到独立的目录，再在配置里把它们都列上。这样HDFS会自动做数据的跨盘均衡分布，能充分发挥多块磁盘的并发I/O能力。我在生产环境里见过用12块盘做数据目录的DataNode，单节点写入吞吐能跑到接近万兆网卡的上限。

2.3 网络拓扑的简单考量

单机架的小集群不用考虑机架感知，但网络还是有讲究的。节点之间的数据副本传输、shuffle过程都会产生大量网络流量。我是建议所有节点都接入同一个交换机，减少跨设备转发的延迟。如果你的机器有双网卡，可以考虑做bonding，也就是链路聚合，把带宽翻倍。当然，前提是你的交换机和网卡都支持。

另外，务必给集群配置固定的内网IP。DHCP动态分配IP地址在重启之后可能变化，Hadoop配置里写死的地址一旦失联，整个集群就找不到节点了。我一般会在规划阶段就列一张IP地址分配表，哪个节点做Master、哪个节点做Worker，全部固定下来，后续的所有配置文件都以这张表为准。

3. 操作系统层面的预处理：用户、目录、防火墙与基础工具

3.1 为什么要单独建一个hadoop用户

生产环境里，用root直接跑集群是很危险的。Hadoop的所有进程都运行在JVM里，一旦代码有漏洞或者配置失误，以root权限运行的进程可能让整台机器失去控制。更现实的问题是，多个用户共用一个系统时，root建的目录其他人也能动，数据安全和权限隔离都是隐患。

我的习惯是创建一个专门的用户，名字就叫hadoop，后面所有大数据组件都用这个用户安装和运行。创建命令很简单：

sudo useradd -m -s /bin/bash hadoop sudo passwd hadoop

创建完之后，未来所有操作都以hadoop用户进行。说到这里要提醒一句：如果你只是随便搭个学习环境，可以不用创建新用户，直接用自己的普通账号也行。但养成好习惯没坏处——等哪天你去维护真正生产集群的时候，就会发现每个公司都在用独立账号管理大数据组件。

3.2 /etc/hosts和主机名规划

/etc/hosts是集群节点之间互认身份的基础。Hadoop的各个节点需要通过主机名互相通信，如果系统解析主机名失败，集群就会报各种连接拒绝或者UnknownHost的错误。我的规划习惯是：主节点叫hadoop-master，从节点叫hadoop-worker1、hadoop-worker2，以此类推。

各节点的/etc/hosts统一加上这些内容：

192.168.1.100 hadoop-master 192.168.1.101 hadoop-worker1 192.168.1.102 hadoop-worker2

这里有个细节很多人会忽略：配置文件里不要用默认的那个主机名，比如Ubuntu的localhost那种带一串随机字母的主机名，而是统一改成你规划的实际主机名。修改主机名的命令在CentOS和Ubuntu上略有不同，CentOS系使用hostnamectl set-hostname，Debian系可以直接改/etc/hostname文件。

还有一个隐藏的坑是DNS解析顺序。如果你所在的环境配置了DNS服务器，而内部DNS解析不出这些主机名，系统可能先去问DNS，导致解析变慢，进而影响Hadoop进程的通信效率。所以/etc/hosts里的这些条目尽量写全，包括主机名和IP对应的IPv4配置，少用IPv6的localhost条目。

3.3 防火墙与安全策略

防火墙这个东西，在集群内部往往是最大的通信障碍。Hadoop组件之间的端口非常多：NameNode的8020/9000端口、DataNode的9866端口、ResourceManager的8088端口、NodeManager的8042端口……一个一个去配放行规则，最后你会疯掉。小规模实验环境，我通常建议直接关闭防火墙。如果你无法关闭，也要把核心端口段一次放行。

关闭防火墙的命令并不复杂：

sudo systemctl stop firewalld sudo systemctl disable firewalld

关闭之后验证一下状态，再用ping和telnet简单测一下节点间是否互通。我只是在这里提一句防火墙的事情，因为常有朋友在群里说"集群起不来"，排查到最后发现是防火墙把端口全挡了。生产环境当然不能这么粗暴，但学习阶段的重点是跑通流程，而不是跟防火墙较劲。

另外顺带提一下SELinux。CentOS上默认开启的SELinux会限制进程访问文件目录的权限，很多Hadoop异常都和它有关。学习环境可以直接把它设为disabled。配置文件在/etc/selinux/config，把SELINUX=enforcing改成SELINUX=disabled。这个操作需要重启系统才会生效。

3.4 文件句柄数和进程数的上限调整

Hadoop是个"高并发"的上瘾者。DataNode和NodeManager要同时处理大量文件的读写，每打开一个文件就要占用一个文件描述符，默认的1024上限根本不够用。我见过DataNode运行一段时间后开始疯狂报"Too many open files"错误，连HDFS的写操作都开始失败，最后排查下来就是文件句柄数没调。

调整方式是修改/etc/security/limits.conf文件，把hadoop用户的限制调高：

hadoop soft nofile 65535 hadoop hard nofile 65535 hadoop soft nproc 65535 hadoop hard nproc 65535

同时还要在/etc/sysctl.conf里加上：

fs.file-max = 100000

这个文件句柄数的调整，属于典型的"平时看不见、用时方恨少"的操作。搭集群的时候顺手配好，能省掉未来无数排查的麻烦。

3.5 时钟同步：避免"时间漂移"引起的诡异问题

集群里所有节点的时间如果不一致，会导致各种莫名其妙的问题，比如HDFS租约过期、Kerberos认证失败、日志时间错乱。生产集群会配置NTP服务或者使用内网的时间同步服务器，学习环境可以简单点，直接配置与公共时间服务器的同步。

CentOS系通常用chrony来同步时间，配置文件在/etc/chrony.conf。Ubuntu一般自带systemd-timesyncd，也可以安装chrony。我这里不展开配置细节，但务必确认一件最基本的事：如果你用的是虚拟机，宿主机暂停或者快照恢复之后，虚拟机的时间会漂移，一定要重新同步。我用虚拟机搭集群时吃过这个亏，快照恢复之后没同步时间，结果集群的ZooKeeper会话老是断开，排查了很久才发现是时间问题。

4. JDK的选择与环境变量配置：版本选不对，后面都是坑

4.1 为什么必须用JDK 8或JDK 11

Hadoop版本和JDK版本有一个对应关系，用错版本就会出现各种编译错误和运行时异常。就目前主流使用的Hadoop 3.x系列来说，JDK 8是兼容性最稳妥的选择，JDK 11在Hadoop 3.3及以上版本也能用，但某些组件会有些小坑。我搭生产集群的经验是，除非你确认你的组件全家桶都已经适配了JDK 11，否则老老实实用JDK 8。

另外一个容易被坑的地方是：不要直接用发行版包管理器安装的OpenJDK，因为版本可能和你后来装的Hadoop组件对不上。我习惯从可靠的镜像站下载特定版本的JDK压缩包，然后手动解压安装。这样能精确锁定JDK版本，避免因为版本漂移导致的不可控问题。

JDK 8有一个小版本号也值得注意，一般选择8u202或者更新的版本。有些太老的版本存在已知的Bug，会影响HDFS在某些场景下的性能。

4.2 从下载到环境变量配置的完整流程

以JDK 8为例，下载jdk-8u202-linux-x64.tar.gz之后，放到/opt目录下解压：

cd /opt tar -zxvf jdk-8u202-linux-x64.tar.gz mv jdk1.8.0_202 /opt/jdk8

为了后期升级方便，我一般会建一个软链接指向具体的JDK版本目录。环境变量配置在hadoop用户的~/.bashrc文件里，加上以下几行：

export JAVA_HOME=/opt/jdk8 export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

保存之后执行source ~/.bashrc让配置生效。然后验证一下：

java -version

如果输出的是java version "1.8.0_202"这样的内容，说明环境变量生效了。

有些教程会让你改/etc/profile文件，把环境变量配成全局的。我的建议是只改hadoop用户的~/.bashrc，原因是：不同大数据组件可能对JDK版本的要求不同，全局铺开之后，其他组件换版本时会互相干扰。全部限定在专用用户内部，这个用户跑什么组件，就配什么版本的JDK，互不牵连。

4.3 一个关于Java环境变量的异常排查

有次我在给一新搭的集群配置JDK时，java -version能出来，但Hadoop启动脚本总是报找不到Java。查了半天发现原因：hadoop用户确实有~/.bashrc配置，但脚本在启动时用的是非登录Shell，而~/.bashrc只在登录Shell中生效。

这种情况的解决方式是在hadoop用户的主目录下建一个.bash_profile文件，让非登录Shell也能加载环境变量：

cat > ~/.bash_profile << 'EOF' if [ -f ~/.bashrc ]; then . ~/.bashrc fi EOF

从那次之后，我的环境变量配置都会同时检查.bashrc和.bash_profile，确保在不同Shell模式下都能正确加载。这个细节如果不亲自踩一次坑，真的很难想起来。

5. SSH免密登录的配置：集群运维的第一道便利工具

5.1 为什么需要免密登录

Hadoop的启动脚本要远程控制所有节点的进程。比如你在主节点执行start-dfs.sh，它会通过SSH连接到每个从节点，启动DataNode进程。如果你每次连接都要输密码，脚本就只能中断，集群根本没法一健启动。所以免密登录不是可选优化，是必备基础。

免密登录的原理是密钥对认证：主节点生成一对密钥，公钥分发到每个从节点的authorized_keys文件里。之后主节点发起SSH连接时，从节点用公钥验证主节点的身份，验证通过就不再询问密码。

5.2 生成密钥并分发的完整操作

在主节点上，切换到hadoop用户，生成密钥对：

ssh-keygen -t rsa -b 4096 -P '' -f ~/.ssh/id_rsa

这里的-P ''表示私钥口令为空，这样每次连接都不用额外输入口令。生产环境出于安全考虑不应该这么做，但学习环境图省事，不设口令。

生成之后，把公钥内容复制到每台机器的authorized_keys里：

ssh-copy-id hadoop@hadoop-master ssh-copy-id hadoop@hadoop-worker1 ssh-copy-id hadoop@hadoop-worker2

ssh-copy-id会自动把本机的公钥追加到目标机器的authorized_keys中。注意你需要在每台机器上都有hadoop用户，而且目标机器的SSH服务已开启。

如果ssh-copy-id不可用，也可以手动追加，效果一样：

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

但如果手动追加，你还要把authorized_keys的文件权限改成600，目录权限改成700。权限不对，SSH服务会拒绝使用该密钥文件。这个权限坑很多人都踩过。

5.3 免密登录的验证范围和常见失败场景

配置完成之后，用一条命令验证主节点能否免密登录所有节点：

ssh hadoop@hadoop-master "hostname" ssh hadoop@hadoop-worker1 "hostname" ssh hadoop@hadoop-worker2 "hostname"

如果每台机器都打印出了自己的主机名，说明免密登录成功了。

常见的失败场景有这么几个：一是主节点生成密钥时的用户不对，比如你用root生成了密钥，又把公钥发给了hadoop用户，那hadoop用户的SSH自然就连接不上；二是authorized_keys文件权限太高；三是ssh-copy-id的时候没有指定正确的端口，如果你改了SSH默认端口，需要在命令里加上-p参数。还有一个很容易忽略的点是~/.ssh目录下最好加一个config文件，在配置多集群时可以避免密钥混淆，但单集群场景不需要。

5.4 SSH连接慢的问题：反向DNS解析

搭好免密登录之后，每次SSH连接都要等几秒才出现提示，很多人以为是密钥配错了。其实这个是SSH服务在做反向DNS解析。在每台机器的/etc/ssh/sshd_config里加上：

UseDNS no GSSAPIAuthentication no

然后重启SSH服务：

sudo systemctl restart sshd

再连接就能体验到秒开的感觉。集群节点一多，这个优化带来的体验提升非常明显。

6. 数据目录规划与目录权限：别把所有鸡蛋放在一个篮子里

6.1 HDFS数据目录的多盘配置思路

HDFS的副本机制本身已经做了数据冗余，但你如果只有一个数据目录，就只会在那一块盘上写数据。配置多个数据目录之后，DataNode会尽量均匀地把数据分布到这些目录里，实现物理层面的并发I/O。我在部署测试集群时用过一块NVMe加一块SATA SSD的组合，两个数据目录都配给同一DataNode，实测写入吞吐比只配一个目录时提升了不少。

目录规划的实操很简单。假设你有一块独立数据盘挂载到了/data目录，我建议按组件再细分一层：

sudo mkdir -p /data/hdfs/dfs/name sudo mkdir -p /data/hdfs/dfs/data sudo chown -R hadoop:hadoop /data/hdfs

其中name目录是NameNode的元数据存储目录，data目录是DataNode的数据块存储目录。两块目录必须分开，因为NameNode的元数据极其金贵，如果和数据块混杂在一个磁盘上，磁盘故障时元数据和数据一起丢，整个集群就废了。NameNode元数据丢失是无法用数据块重建的，我强调再多都不为过。

6.2 临时目录的容量与清理策略

MapReduce作业在运行时会产生大量临时文件，位置默认在/tmp。如果你的/tmp空间太小，作业跑到一半磁盘就满了，表现是作业卡住、任务反复失败。我的建议是在规划时就给/tmp单独分一个较大的文件系统，比如20GB以上。另外要小心系统自带的清理机制，有些发行版会定时清理/tmp下的旧文件，如果你的临时数据超过一天没处理完，就可能在运行中断掉。

为了避免这类问题，也为了路径清晰，我把Hadoop的临时目录单独指向一个路径，比如/data/hdfs/tmp。在后续配置core-site.xml时会用到这个路径，现在先把目录建好、权限调好，放到位。

6.3 权限与属主：一个频频发生的目录权限事故

目录建好之后，如果属主不是hadoop用户，Hadoop进程就无法在目录里写数据。数据节点起不来、NameNode格式化失败这种问题，大概率就是目录属主不对。

我第一次搭集群时，所有操作都是用root做的，数据目录也都是root创建的。结果切到hadoop用户启动集群，DataNode直接报Permission denied，整个集群只有主节点起来，从节点全是红的。那次之后，我建立了一条铁律：凡是给Hadoop使用的目录，创建完成后必须检查属主和权限。

chown -R hadoop:hadoop /data/hdfs chmod -R 755 /data/hdfs

这两条命令执行之后，再用ls -l确认一下。命令输出里目录属主显示hadoop hadoop，权限包含读写执行位，才算合格。

7. 通用的系统性能参数：内核参数的初步调优

7.1 网络参数和文件系统挂载选项

如果你追求"高性能"，一些常规内核参数值得提前调整。网络方面主要调大TCP缓冲区，让网络传输在Shuffle阶段更顺畅。在/etc/sysctl.conf里追加：

net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216

这些数值的单位是字节，调整之后网络数据包在吞吐量较高时不至于频繁丢包。我遇到过很多场景都是因为TCP缓冲区太小，导致数据跨节点复制时速度上不去。当然这些参数不是越大越好，太大的缓冲区会占用不少内存，要根据你的内存容量来综合判断。

文件系统挂载选项也值得调一下。ext4和xfs默认挂载选项在某些场景下没什么问题，但如果你用的是机械盘，可以加上noatime选项：

mount -o noatime,defaults /dev/sdb /data

noatime会关闭文件访问时间的更新，减少每次读文件时的一次写操作，对机械盘性能提升帮助很明显。如果是SSD，效果相对小一些，但也没坏处。

7.2 关闭透明大页（THP）

这是一个比较冷门但影响显著的调优点。Linux内核的透明大页（Transparent Huge Pages）特性在某些Hadoop场景下会导致内存分配效率下降，而且为了对齐大页频繁做内存整理，可能引起明显的性能抖动。大数据领域里很多项目都明确建议关闭THP，这是大家踩坑踩出来的共识。

关闭命令：

echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag

这两个命令在重启后会失效，所以需要写入开机启动脚本，或者写到rc.local里。也可以用systemd的方式来管理，写一个service文件，启动时自动执行。我习惯在/etc/rc.local里追加，虽然老派，但简单可靠。

7.3 进程数与内存分配策略

Hadoop的并发执行模型时，操作系统默认的进程数限制可能会成为瓶颈。在/etc/security/limits.conf里已经调过nproc了，再配合内核参数kernel.pid_max调大，可以支撑更多并发任务。这个在内存足够大的机器上尤其重要。

另外有个参数非常隐蔽：vm.swappiness。大多数Linux发行版默认的swappiness值是60，表示系统在内存紧张时会积极使用交换分区。但大数据场景下，交换分区会导致JVM进程出现长暂停，严重影响作业性能。建议把swappiness调低：

echo 'vm.swappiness = 10' >> /etc/sysctl.conf

这个值不是越低越好，设为0有可能导致内存回收过于激进，反而引起别的性能问题。10左右是个比较稳妥的取整值，既不会频繁交换，又能在内存确实紧缺时兜底。

这些内核参数的调整不需要在搭建阶段全部做完，但提前做好，后面跑性能测试的时候你的集群起点就比别人的高一个台阶。很多性能优化的教程都是到"怎么调yarn参数"才大篇幅铺开，但如果你系统层面的I/O和网络就已经慢了，应用层的调优只能在一个被限制的天花板下面腾挪，发挥的空间有限。

8. 搭建完成后的连通性验证与常见报错速查

8.1 从节点连通性验证清单

前置准备工作全部做完之后，不要急着装Hadoop。先用几分钟把环境整体验证一遍，能在安装之前暴露很多基础配置错误。我给自己列的验证清单包括：

• 所有节点执行hostname，输出主机名是否与规划一致
• 执行ssh到每个从节点，确认免密登录顺畅
• 用ping测节点之间的网络延迟，确保没有丢包
• 用df -h确认数据目录挂载正确、剩余空间充足
• 用java -version确认JDK版本符合预期
• 用free -h查看内存总量，确认可用内存没有被吃满

这个清单看起来琐碎，但每一项都对应后续安装阶段可能出现的具体故障。花两分钟跑一遍，能帮你在接下来的安装过程里节省大把排查时间。

8.2 与"文件句柄、目录权限、主机名解析"相关的报错实测记录

我把几个在安装过程中常遇到的报错整理成一张速查表，全部是我实际处理过的，参考性很强：

这张表我建议你截屏存下来，等实际搭集群的时候对照着查。每一种报错和对应的解决方式，都是我从一次次"把集群装崩了然后重来"的经历里总结出来的，省掉这些坑，你至少能快半天下线。

8.3 一个完整的"由hosts配置错误引起的集群失联"案例

我记忆比较深刻的一次事故，是某台从节点重装系统后没有更新/etc/hosts，结果Master节点一直解析不了它的主机名。表现症状是：从节点能看到自己的进程在跑，但Master的UI上始终少这台机器。我当时用jps看从节点进程是正常的，但去Master执行hdfs dfsadmin -report时，列表里就是少一个DataNode。

排查过程是这样的：先用ping检查从节点的IP连通性，通了。接着用ssh免密登录，也正常。然后用curl访问从节点的DataNode HTTP端口，发现能访问。最后忽然想到看从节点的/etc/hosts，发现主机名和Master节点上的hosts记录不一致。修改从节点的hosts之后，DataNode就跟集群正常通信了。

这个案例说明一个核心观点：集群搭建过程中，最不值钱的是操作本身，最值钱的是排查思路。先把链路的主线明确出来，再沿着网络、DNS、进程、权限的顺序逐层排查，大多数问题都能在十分钟内定位。

9. 写在最后：准备工作的完成度决定集群的天花板

我现在搭集群，已经不太依赖图形界面了，所有基础配置都是命令行加配置文件完成。这样做的好处是：操作可追溯、配置可复制、故障可排查。把一套标准化的前置步骤沉淀下来，以后新加节点时直接照着操作，半小时就能把一台裸机变成合格的集群成员。

如果你是完全的新手，我建议你不光要照着命令敲，还要手动打开每一个配置文件看看内容。比如limits.conf里的具体数值、sshd_config里的每个参数含义，花几分钟搞清楚，比背十条命令有价值多了。以后遇到问题，你能自己判断是配置问题还是系统问题，不用每次都把报错信息全文贴到搜索框里。

系列第一篇到这里收尾，基础环境算是全部就绪了。下一篇文章应该会深入到Hadoop本身的安装，包括HDFS和YARN的配置细节、格式化NameNode的操作、以及启动流程。等你把所有前置工作做完，再回头看Hadoop的配置过程，会觉得顺畅很多。