Hadoop完全分布式集群搭建实战：从零部署到问题排查-代码聚汇网

Hadoop完全分布式集群搭建实战：从零部署到问题排查

Hadoop完全分布式集群搭建

|难度：普通|阅读约 41 分钟

1. 搭建前的思维准备与整体架构

1.1 先搞清楚：完全分布式和伪分布式到底差在哪

很多零基础的朋友第一次接触Hadoop，最先搭的往往是伪分布式，也就是一台机器上跑完整套Hadoop。这种做法对于理解原理、跑通代码确实够用，但严格来说它并不能算“分布式”——因为所有的进程都挤在同一台机器上，NameNode、DataNode、ResourceManager、NodeManager全都共用一个CPU和内存，根本没有网络传输和节点协调的概念。

而完全分布式是指把Hadoop的各个角色拆到多台物理机或虚拟机上，每台机器各司其职，通过网络互相通信，数据也真正分散存储在不同的节点上。这才是生产环境中Hadoop的真实形态，也是面试里经常被追问的“集群是怎么协同工作的”背后的答案。

我的建议是：如果你手里只有一台电脑，想通过虚拟机模拟集群环境，完全没问题。很多人以为完全分布式必须要三台真机，其实用VMware或VirtualBox开三台虚拟机照样能完整还原整个搭建过程，而且方便快照、方便回滚，踩坑成本低得多。我自己最开始练手时就是一台8G内存的笔记本，开了三台各分配2G内存的CentOS虚拟机，跑起来虽然不算飞快，但学习和测试完全够用。

1.2 角色分配与节点规划：先想清楚再动手

搭建集群前，第一步不是装软件，而是设计节点的角色分配。Hadoop的核心角色主要有这么几个：

NameNode（NN）：管理整个HDFS的元数据，相当于文件系统的“大脑”，记录所有文件被切成了哪些块、每个块存在哪几台机器上。
DataNode（DN）：真正存数据的节点，负责实际读写数据块。
SecondaryNameNode（SNN）：很多人误以为它是NameNode的热备，其实不是。它的主要工作是定期合并NameNode的编辑日志和镜像文件，帮NameNode分担压力。在Hadoop 2.x之后它更像是“检查点节点”。
ResourceManager（RM）：集群资源调度的总管家，负责分配CPU、内存等资源给各个任务。
NodeManager（NM）：每台计算节点上的资源监控和任务执行者，和ResourceManager配合完成分布式计算。
JobHistoryServer：记录作业运行历史，方便之后查看日志和任务详情。

常见的规划方式通常有两种：一种是三节点方案，即一台机器同时承担NameNode和ResourceManager，另外两台作为DataNode和NodeManager；另一种是四节点或更多节点的方案，把NameNode和ResourceManager拆到不同机器上，还会有专门的客户端节点。

这里我推荐零基础的朋友直接用三节点方案，角色分配如下：

节点	主机名	IP（示例）	角色
节点1	hadoop01	192.168.163.101	NameNode、ResourceManager、SecondaryNameNode
节点2	hadoop02	192.168.163.102	DataNode、NodeManager
节点3	hadoop03	192.168.163.103	DataNode、NodeManager

为什么这样分配？因为NameNode和ResourceManager都是管理角色，把它们放在同一台机器上，机器压力会大一些，但对三节点集群来说完全合理，还能省机器。SecondaryNameNode默认会和NameNode放在一起，这对测试环境没问题，生产环境建议单独拆分。

注意：主机名的命名不要太随意。我用过hadoop001、hadoop002这样的编号，也用过node1、node2，都可以，但要保证简短、不含下划线、不含特殊字符。主机名如果带下划线，后面启动Hadoop时很可能遇到各种莫名的报错，别问我是怎么知道的。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 基础环境准备：每一步都是后面成功的前提

2.1 系统安装与JDK选型

我用的环境是CentOS 7.9（当然你用CentOS 8、Ubuntu Server也行，配置逻辑基本一致，差别主要在包管理命令上），三台机器都安装最小化系统即可，不需要装图形界面。装系统的时候记得把网络连接方式设为NAT或桥接，保证三台机器能互相ping通。

然后是JDK版本。Hadoop 3.x要求JDK 8以上，我用的是JDK 1.8（即JDK 8），这是最稳妥、资料最多的组合。如果你用Hadoop 2.x，那JDK 8更是标配。安装JDK时建议用Oracle JDK或者OpenJDK都行，生产上开源项目用OpenJDK多一些，个人学习两者皆可。

安装步骤就是下载JDK的tar包，解压到 /usr/local/java/ 目录，然后配置环境变量。这部分我默认各位有基础，但为了照顾零基础的读者，还是把完整的操作写出来：

bash复制mkdir -p /usr/local/java
tar -zxvf jdk-8u202-linux-x64.tar.gz -C /usr/local/java/

然后编辑 /etc/profile，在文件末尾追加以下内容：

bash复制export JAVA_HOME=/usr/local/java/jdk1.8.0_202
export PATH=$PATH:$JAVA_HOME/bin

执行 source /etc/profile 让配置生效，再用 java -version 验证。这里建议三台机器一次性都配好，免得后面来回切换。

2.2 SSH免密登录：集群通信的“通行证”

完全分布式集群有一个非常高频的操作：在主节点上执行 start-dfs.sh 时，脚本需要通过SSH远程登录到每一台DataNode去启动对应的进程。如果每次都要手动输密码，整个启动过程就没法自动完成了，所以必须配置SSH免密登录。

配置的思路是生成密钥对，然后把公钥分发到所有需要被登录的机器上。具体步骤如下：

第一步，在每台机器上生成密钥对：

bash复制ssh-keygen -t rsa

生成过程中一路回车即可，默认会在 ~/.ssh/ 目录下生成 id_rsa（私钥）和 id_rsa.pub（公钥）。

第二步，把主节点（hadoop01）的公钥追加到所有机器的 authorized_keys 文件中。这里包括三台机器本身，因为主节点启动时要同时向本机和两个从节点发起SSH连接。

我在实际配置时习惯先把所有机器的公钥都集中放到一个地方，再统一分发，这样最省事：

bash复制# 在hadoop01上执行
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
cat ~/.ssh/id_rsa.pub | ssh hadoop02 'cat >> ~/.ssh/authorized_keys'
cat ~/.ssh/id_rsa.pub | ssh hadoop03 'cat >> ~/.ssh/authorized_keys'

第三步，验证免密登录是否生效：

bash复制ssh hadoop01 hostname
ssh hadoop02 hostname
ssh hadoop03 hostname

注意：很多人只配置主节点到从节点的免密，却忽略了主节点到自己的免密，结果执行启动脚本时报错“Permission denied (publickey)”，排查半天才发现是本机连自己都没通。这一步看着简单，漏掉的人可不少。

2.3 hosts映射、时间同步与防火墙：容易被忽略的三个细节

三台机器之间通信，除了IP直连，更建议配置hosts映射，这样主机名能直接解析成IP，配置文件里写主机名会比写IP清晰得多。编辑 /etc/hosts 文件，在三台机器上都追加同样内容：

code复制192.168.163.101 hadoop01
192.168.163.102 hadoop02
192.168.163.103 hadoop03

配置完用 ping hadoop02 测试一下，能通就说明解析正常。

时间同步这块，很多新手会忽略。Hadoop集群对节点间时间偏差比较敏感，如果各节点的时钟差太大，轻则日志时间对不上，重则部分RPC通信会异常。最简单的做法是在每台机器上安装NTP服务并指向同一个时间源，或者干脆写一个crontab定时执行时间同步命令。测试环境如果时间差不大，影响不会立刻暴露，但最好养成同步的习惯。

防火墙方面，CentOS 7默认的firewalld会挡掉Hadoop的通信端口，建议测试环境直接关闭：

bash复制systemctl stop firewalld
systemctl disable firewalld

如果你是生产环境，不能随便关防火墙，那就需要把HDFS和YARN相关的端口（如8020、9870、8088、8030-8033、9000等）全部加到白名单里。这个问题我会在后面的问题排查部分再细说。

3. 核心配置详解：五类文件必须手把手弄明白

3.1 配置文件的整体逻辑

Hadoop的配置分散在好几个目录里，但配置文件本体主要位于Hadoop安装目录的 etc/hadoop/ 子目录下。需要重点修改的文件有：core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml，以及 workers（在Hadoop 2.x里叫 slaves）。

在动手改之前，我想先给零基础的朋友吃一颗定心丸：这些配置文件看似参数很多，但实际上完全分布式的核心配置就十来个参数。把每个参数的含义搞明白，比死记硬背路径有用得多，因为你以后遇到问题、要调优，都是基于对参数的理解。

我采用的方式是：先把三台机器的Hadoop安装包解压好，然后只在hadoop01上做完所有的配置修改，最后用 scp 命令把整个配置好的目录分发到其余两台机器。这样能确保三台机器的配置完全一致，避免手改时漏掉某个文件或写错某一个参数。

3.2 core-site.xml：集群的“默认值管理中心”

core-site.xml 负责配置HDFS的访问入口和临时文件目录，最关键的是 fs.defaultFS，它决定了客户端连接到哪个NameNode以及使用哪个端口。

xml复制<configuration>
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://hadoop01:8020</value>
    </property>
    <property>
        <name>hadoop.tmp.dir</name>
        <value>/usr/local/hadoop/tmp</value>
    </property>
</configuration>

hadoop.tmp.dir 是我个人非常想提醒大家注意的一个参数。它指定了Hadoop运行时存放临时数据的根目录，NameNode的元数据、DataNode的数据块目录，都会以它为基准生成。如果这个参数不配置，默认会使用 /tmp/hadoop-${user}，而系统在重启后可能会清理 /tmp 目录，到时候元数据丢失，集群直接“失忆”。所以一定指定一个常规数据目录，比如 /usr/local/hadoop/tmp，并确保目录存在、有写权限。

3.3 hdfs-site.xml：搞定副本数和元数据路径

hdfs-site.xml 里最重要的参数有两个：副本数和NameNode元数据存储路径。

xml复制<configuration>
    <property>
        <name>dfs.replication</name>
        <value>2</value>
    </property>
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>file:///usr/local/hadoop/tmp/dfs/name</value>
    </property>
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>file:///usr/local/hadoop/tmp/dfs/data</value>
    </property>
</configuration>

dfs.replication 表示每个数据块要保存几份副本。集群一共三台机器，其中两台是DataNode，理论上副本数最大能设为2（存两份，分别在不同节点上），最小可以设成1。如果你设成3，而集群只有两台DataNode，HDFS会一直报副本不足的警告，因为第三份副本根本找不到地方放。所以这里设成2最合适。

dfs.namenode.name.dir 和 dfs.datanode.data.dir 分别指定NameNode元数据目录和DataNode数据块目录。理解这两个目录的区别很重要：NameNode存的是“目录树”和“数据块映射表”，不存实际内容；DataNode存的才是真正的数据块。之所以叫“完全分布式”，精髓之一就在这里——NameNode没有数据，DataNode没有目录树。

3.4 yarn-site.xml：计算资源怎么协调

YARN负责整个集群的计算资源管理，yarn-site.xml 里最核心的是指定ResourceManager所在节点，以及为每台NodeManager配置资源上限。

xml复制<configuration>
    <property>
        <name>yarn.nodemanager.aux-services</name>
        <value>mapreduce_shuffle</value>
    </property>
    <property>
        <name>yarn.resourcemanager.hostname</name>
        <value>hadoop01</value>
    </property>
    <property>
        <name>yarn.nodemanager.env-whitelist</name>
        <value>JAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_MAPRED_HOME</value>
    </property>
</configuration>

yarn.nodemanager.aux-services 设置为 mapreduce_shuffle 是运行MapReduce作业的前提，它允许NodeManager执行MapReduce所需的Shuffle阶段数据传输。yarn.resourcemanager.hostname 则是告诉所有NodeManager，ResourceManager在哪台机器上。

注意：Hadoop 3.x 的环境变量白名单如果不配置好，跑MapReduce作业时经常出现Container启动失败、找不到 hadoop 命令之类的报错。

3.5 mapred-site.xml 与 workers：剩下的两个关键文件

mapred-site.xml 用来指定MapReduce作业使用什么资源调度框架，默认要配置成YARN：

xml复制<configuration>
    <property>
        <name>mapreduce.framework.name</name>
        <value>yarn</value>
    </property>
</configuration>

workers 文件（Hadoop 3.x）里填的是所有DataNode和NodeManager的主机名，一行一个：

code复制hadoop01
hadoop02
hadoop03

注意，这里每台机器一行，不要有空格缩进，文件末尾也不要有多余的空行。如果不小心把主节点也漏掉了，那这个节点既不会有DataNode也不会启动NodeManager，集群容量就少了一大块。

3.6 环境变量与目录分发的细节

在hadoop01上配置完所有文件后，还要编辑 /etc/profile，追加Hadoop的环境变量：

bash复制export HADOOP_HOME=/usr/local/hadoop
export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin

然后需要确保 hadoop-env.sh 里指定的JAVA_HOME正确，尤其是当你手动指定过JDK路径时，强烈建议在 hadoop-env.sh 中显式写上：

bash复制export JAVA_HOME=/usr/local/java/jdk1.8.0_202

最后，把整个Hadoop目录和环境变量配置分发到hadoop02和hadoop03：

bash复制scp -r /usr/local/hadoop hadoop02:/usr/local/
scp -r /usr/local/hadoop hadoop03:/usr/local/
scp /etc/profile hadoop02:/etc/
scp /etc/profile hadoop03:/etc/

分发完成后，记得在hadoop02和hadoop03上执行 source /etc/profile，并确认 hadoop version 能正常输出。

4. 格式化与启动：第一次启动是最容易“踩雷”的环节

4.1 格式化NameNode：只能做一次的“初始化”

配置完成后，终于到了启动前的最后一步：格式化NameNode。这一步相当于给文件系统的元数据做一次初始化，生成一份空的FsImage。执行命令：

bash复制hdfs namenode -format

第一次执行会生成集群ID（cluster ID），这个ID非常重要。集群中所有DataNode都会通过这个ID来识别自己属于哪个集群。如果后续你因为配置改动又格式化了一次，而旧DataNode上的数据目录还保留着之前记录的集群ID，那么新格式化的NameNode生成的cluster ID和DataNode的不一致，DataNode就会拒绝注册，导致集群无法正常工作。

这是完全分布式搭建中最常见的“坑”之一。我的建议是：在真正启动之前，确认所有配置文件都改好了，再格式化，并且格式化之后不要轻易再执行第二次。如果非要重新格式化，把之前各节点上的临时目录（比如 /usr/local/hadoop/tmp）全部删掉，让一切从零开始。

4.2 启动集群：一条命令背后的流程

启动命令很简单，在hadoop01上执行：

bash复制start-dfs.sh
start-yarn.sh

也可以一条命令搞定：start-all.sh。但生产环境里我更推荐分开启动，这样能更清楚地看到HDFS和YARN各自的状态，定位问题也方便。

执行 start-dfs.sh 时，脚本会通过SSH依次连接到各个节点，启动NameNode、SecondaryNameNode和DataNode。正常情况下，你会看到日志输出了每个节点的启动情况。接着执行 start-yarn.sh，启动ResourceManager和NodeManager。

启动完成后，用 jps 命令验证各节点的Java进程。hadoop01上应该出现：

code复制NameNode
SecondaryNameNode
ResourceManager

hadoop02和hadoop03上应该出现：

code复制DataNode
NodeManager

如果每个角色都正确出现在对应节点上，说明集群启动成功了。

4.3 通过Web界面验证集群状态

Hadoop集群还提供了Web UI用来查看状态，这个功能对检查健康状态特别友好。

HDFS的Web界面地址是 http://hadoop01:9870（Hadoop 3.x），在这里可以看到NameNode的状态、数据节点列表、HDFS存储容量、文件块分布情况。YARN的Web界面是 http://hadoop01:8088，可以查看正在运行的应用程序、队列资源分配、节点列表等。

我第一次启动完就在HDFS页面上看到“Live Nodes只有2个”但我明明配了3个节点，排查了半天才发现是DataNode进程根本没起来。这类问题基本都能在Web界面上快速定位，所以建议读者养成启动后先看Web UI的习惯。

4.4 用上传文件和跑WordCount做最终验证

光看进程还不够，真正的验证是让数据流转起来。我习惯在验证阶段做两件事：

第一件事，创建目录并上传文件到HDFS：

bash复制hdfs dfs -mkdir -p /user/test
echo "hello hadoop world" > test.txt
hdfs dfs -put test.txt /user/test/
hdfs dfs -cat /user/test/test.txt

如果上传和读取都正常，说明HDFS的写入链路没有问题，NameNode和DataNode之间通信正常。

第二件事，跑一个MapReduce的离线计算任务，用来验证整个计算链路。Hadoop安装包里自带了许多示例程序，最经典的就是WordCount：

bash复制hadoop jar /usr/local/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.1.jar wordcount /user/test/test.txt /user/test/output

然后查看结果：

bash复制hdfs dfs -cat /user/test/output/part-r-00000

如果能正确输出单词统计结果，说明YARN的资源调度、NodeManager的任务执行、数据在节点间的Shuffle全部工作正常。到这一步，完全分布式集群就算真正“跑通”了。

5. 常见问题与排查技巧实录

5.1 我踩过的最典型的几个坑

完全分布式的搭建过程里，我踩过的坑太多了，这里挑几个出现频率最高、也最值得提前预防的说。

第一个坑是 NameNode格式化之后DataNode启动不了。症状是主节点日志显示DataNode反复连接NameNode失败。原因绝大多数是之前格式化过多次，DataNode数据目录里存的cluster ID和NameNode新的cluster ID对不上。解决办法就是删除所有节点上 /usr/local/hadoop/tmp 目录，重新格式化NameNode，再启动。所以真心建议：格式化之前先确认好所有配置，格式化就是“一锤子买卖”。

第二个坑是 启动start-dfs.sh时SSH连接报错。常见提示是 Permission denied (publickey,gssapi-keyex,chpasswd)，或者在机器列表里卡住不动。排查步骤是：在hadoop01上手动 ssh hadoop02 测一下，看是否能免密登录。如果不行，检查 ~/.ssh/authorized_keys 的权限是否为600，~/.ssh 目录权限是否为700，这是SSH的安全策略，权限不对，公钥认证直接不生效。

第三个坑是 Web UI打不开。如果你用的是云服务器或者Windows宿主机访问虚拟机里的Hadoop，要么是防火墙没关，要么是宿主机的hosts文件里没有添加虚拟机的IP映射。Windows下建议在 C:\Windows\System32\drivers\etc\hosts 里加上三台虚拟机的IP和主机名映射。另外检查防火墙，我前面推荐测试环境直接关掉firewalld，就是这个原因。

第四个坑是 运行WordCount时任务一直失败或者Container卡死。这通常和内存有关。虚拟机如果只分配了1G或1.5G内存，YARN默认分配Container的内存可能直接就把节点内存吃光了。解决方案是调小YARN的资源配置，比如在 yarn-site.xml 里加：

xml复制<property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>1024</value>
</property>
<property>
    <name>yarn.scheduler.maximum-allocation-mb</name>
    <value>1024</value>
</property>

同时调小MapReduce的内存参数，在 mapred-site.xml 里设置：

xml复制<property>
    <name>yarn.app.mapreduce.am.resource.mb</name>
    <value>512</value>
</property>
<property>
    <name>mapreduce.map.memory.mb</name>
    <value>256</value>
</property>
<property>
    <name>mapreduce.reduce.memory.mb</name>
    <value>256</value>
</property>

5.2 一份排查用的速查表

症状	可能原因	排查命令/方法
jps看不到DataNode	集群ID不一致、配置错误	查看日志 `/usr/local/hadoop/logs/hadoop-hadoop-datanode-*.log`
启动脚本卡住不动	SSH免密没配置好	手动ssh到对应节点，检查authorized_keys
Web UI无法访问	防火墙、hosts映射、端口未开	执行 `systemctl status firewalld` 检查
上传文件报错“No space”	磁盘空间不够	执行 `df -h` 检查各节点磁盘
200 MB+文件上传失败	块大小设置与实际环境不匹配	可以适当调小 `dfs.blocksize` 方便测试

5.3 日志文件才是真正的好老师

最后分享一个我个人的习惯。遇到问题的时候，别急着乱改配置，先去翻日志。Hadoop的日志默认放在 /usr/local/hadoop/logs/ 目录下，文件名通常以 hadoop-用户名-角色-主机名.log 的格式命名。比如DataNode启动失败，看 hadoop-hadoop-datanode-hadoop02.log 就能找到真正的原因；ResourceManager有问题，看 hadoop-hadoop-resourcemanager-hadoop01.log。

日志里最常见的几种关键信息包括：Cluster ID mismatch（集群ID不一致）、Permission denied（权限问题）、No space left on device（磁盘满）、Java heap space（JVM堆内存不够）。只要你能看懂这几类日志信息，90%的常见问题都能自己解决掉。

6. 常见问题与实操心得补充

6.1 生产环境和学习环境的差别

搭建过程中我一直强调学习环境的操作方式，但这里必须补充说明生产环境的差异。生产集群通常会有独立的Namenode节点、独立的ResourceManager节点，有的还会单独部署一个客户端节点用来提交作业。安全方面，Kerberos认证、Sentry/Ranger权限控制都是必选项，而不是像测试环境一样所有端口全开、防火墙全关。

另外生产环境通常还会考虑高可用（HA）部署，也就是用两个NameNode加ZooKeeper实现自动故障切换，两个ResourceManager同理。这套东西如果零基础一上来就学，很容易被绕晕。我个人的建议是：先把单NameNode的完全分布式跑通，理解所有角色在做什么，再去研究HA，一步一个脚印。

6.2 快速重启集群的正确姿势

日常使用中，我因为改配置、重启虚拟机，重启集群的次数多得数不清。这里提供一个标准流程，减少踩坑概率：

bash复制# 1. 停止集群（在hadoop01上）
stop-yarn.sh
stop-dfs.sh

# 2. 如果有残留进程，用jps检查并kill掉
jps

# 3. 确认所有节点的/tmp临时目录是否需要清理
# 注意：只有要重新初始化时才删，平时不用删

# 4. 重新启动
start-dfs.sh
start-yarn.sh

重启集群时最怕的是HDFS进入安全模式（Safe Mode），启动初期NameNode会先加载元数据并等待DataNode汇报数据块，这时候集群处于只读或不可写状态。如果你在启动后立刻执行上传文件的命令，很可能会报 Name node is in safe mode 的错误。解决办法是等待一会儿，或者用管理员命令强制退出安全模式：

bash复制hdfs dfsadmin -safemode leave

6.3 为什么说“完全分布式”值得亲手搭一遍

现在云平台和容器化技术已经很成熟了，很多人可以一键拉起一个Hadoop集群，几分钟就搞定。但从零开始手工搭建一次完全分布式，依然是一件值得做的事。因为搭一次集群，你才能直观地感受到哪些角色在哪些机器上、哪些端口在通信、哪些配置参数决定行为、哪些文件在启动时被读取、哪些日志在故障时值得去翻。

这种对“分布式系统如何被组织起来”的底层感知，是之后学习HDFS源码、做性能调优、排查线上问题的基础。就像学车一样，教练还没让你上路，你先要把油门、刹车、离合的配合练到肌肉记忆，虽然费时间，但值得。

我在实际带新人的时候，一直坚持让他们至少手动搭一次完全分布式，而且要求所有配置都自己写，不允许复制粘贴。凡是认真搭过一遍的人，后面接触各种大数据组件都顺利得多，因为他们已经习惯了“通过日志找问题、通过参数理解行为”的工作方式。

6.4 后续如果你还想往下走

集群跑通之后，可以继续尝试的方向有很多。比如搭建Hadoop和ZooKeeper的整合环境，这其实是HA高可用的前置步骤，ZooKeeper负责监控NameNode的状态并实现自动切换。再比如HDFS的扩容，也就是往现有集群里新增一个DataNode节点，这个操作在生产中很常见，你能在扩容过程中进一步感受集群的“自愈”能力——新的DataNode注册进来后，HDFS会自动把部分副本迁移到新节点上。

还有一个非常推荐做的练习是：自己写一个简单的MapReduce程序，用Java或者Python跑一遍，体验一把“代码提交到集群、分布式执行、结果回到HDFS”的完整闭环。在这个过程中你会发现，真正难的不是写Map和Reduce逻辑，而是理解数据分区、Shuffle、Combiner这些流程到底在干什么。

6.5 最后再分享一个小技巧

如果你经常需要在多台机器上操作，我特别建议你在本地终端里给每台机器保存一个配置文件，比如在 ~/.ssh/config 里加一段：

code复制Host hadoop01
    HostName 192.168.163.101
    User root

Host hadoop02
    HostName 192.168.163.102
    User root

这样以后直接执行 ssh hadoop02 就能连接，不用记IP。这些小习惯虽然不会直接提升你对Hadoop的理解，但能让你把精力集中在真正重要的事情上，减少在上层操作上的损耗。