Hadoop完全分布式集群搭建实战：从原理到故障排查

先交代一个前提：我写这篇东西不是让你照着敲一遍命令就完事，而是希望你理解每一步到底在干什么。Hadoop完全分布式搭建这件事，网上教程满天飞，但很多人照着抄完还是起不来，或者起来了一次、重启就挂了。原因基本都一样：只知其然，不知其所以然。所以我这篇会把重点放在“为什么要这么配”和“配错了会看到什么现象”上，最后再给你一张可以直接照着干的配置清单。

这套环境我前前后后搭过不下十次，从两台机器到几十台节点的生产集群都碰过。下面这些内容，是我觉得最适合入门、又能让你真正理解Hadoop运行机制的一条路径。

1. 搭建前的核心认知：完全分布式到底在解决什么问题

1.1 从伪分布式到完全分布式，差的不是数量而是架构

很多初学者是从伪分布式（Pseudo-Distributed）入门的，也就是在一台机器上同时跑NameNode、DataNode、ResourceManager、NodeManager。这种方式的好处是让你快速感知Hadoop的组件构成，但代价是它掩盖了分布式系统最核心的复杂性——网络通信、节点间协调、故障隔离。

完全分布式（Fully Distributed）集群，指的是把不同角色部署到不同的物理或虚拟机器上。NameNode和ResourceManager作为主节点，DataNode和NodeManager作为从节点，它们之间通过RPC和HTTP协议通信。当你有3台以上的机器时，才能真正模拟出一个生产环境的运行形态。

我自己带人的经验是：如果只玩过伪分布式就直接去面大数据岗位，面试官一问“DataNode宕机了会发生什么”，基本就露馅了。因为你没在真实的多节点环境里观察过这个过程。完全分布式的搭建，本质上是让你亲手构建一个微缩版的数据中心，哪怕只有三台机器，也能完整走一遍“数据分块—副本放置—任务调度—容错恢复”的全流程。

1.2 版本选型：别一上来就追最新版

Hadoop的版本选择是个老生常谈的话题，但每次都有新人踩坑。目前主流的分支是Apache Hadoop 3.x系列，但3.3.x和3.4.x之间也有差异。我的建议是：学习阶段直接选Apache Hadoop 3.3.6或3.3.4，这两个版本经过了大量生产验证，网上的踩坑资料最多，遇到问题基本都能搜到解决方案。

不要选CDH或HDP这类商业发行版，虽然它们封装得好，但会隐藏太多底层细节，不适合学习。也不要追最新的3.4.x，因为一些生态组件（比如Spark、Flink的某些版本）对它的兼容性还有待验证。

JDK版本方面，Hadoop 3.x要求JDK 8或JDK 11。我推荐JDK 8（具体是8u202或更高），不是因为老，而是因为Hadoop生态里大量组件对JDK 8的兼容性最稳。用JDK 11也可以，但有些老项目的MapReduce程序会踩到模块化相关的坑，对新手不友好。

1.3 集群规划：三台机器是最低配，也是最佳学习配置

最少需要几台机器才能叫“完全分布式”？答案是3台。原因很简单：HDFS默认副本数是3，如果你只有2台DataNode，那么第三个副本会全部堆在某一台机器上，无法体现“机架感知”和“副本分散”的策略。3台节点刚好可以形成一个最小的、逻辑完整的集群。

三台机器怎么分工？我建议这样规划：

主机名	IP	角色
node1	192.168.10.101	NameNode、ResourceManager、SecondaryNameNode
node2	192.168.10.102	DataNode、NodeManager
node3	192.168.10.103	DataNode、NodeManager

为什么不把SecondaryNameNode放到node2或node3？这块后面细说，先记住一个原则：主节点角色尽量不扎堆，但学习环境资源有限时，NameNode和ResourceManager挤在一起是能接受的妥协。

硬件配置方面，每台机器建议至少2核CPU、4GB内存、40GB磁盘。如果你是用虚拟机，VMware或VirtualBox都行，网络模式选“仅主机模式”或“NAT模式”都可以，但三台机器要在同一个网段、能互通。这里有个小技巧：虚拟机内存设成2GB也可以跑起来，但NameNode和ResourceManager的堆内存要相应调小，否则很容易OOM。

2. 基础环境配置：宁可慢一点，也要一次做对

2.1 节点通信与hosts映射

这一步看似简单，但至少三成的人在这里埋下了隐患。核心要求有两条：一是三台机器的主机名不能相同，二是hosts文件里必须把三个节点的主机名和IP的映射关系写全。

以CentOS 7.9为例，修改主机名的命令是：

hostnamectl set-hostname node1

三台机器分别执行，改成node1、node2、node3。然后编辑每台机器的/etc/hosts文件，写入如下内容：

192.168.10.101 node1 192.168.10.102 node2 192.168.10.103 node3

这里特别提醒：要把hosts里自带的127.0.0.1那一行中跟主机名相关的部分处理干净。很多人在启动HDFS时看到java.net.UnknownHostException就是hosts文件里残留了旧的映射导致的。我个人习惯是直接把127.0.0.1行只保留为127.0.0.1 localhost，不跟任何主机名绑定。

2.2 JDK安装与JAVA_HOME配置

JDK的安装方式有不少，但我推荐用tar包手动解压的方式，原因有两个：一是版本可控，二是能清楚知道JDK装在了哪里，后面配置Hadoop时不会搞错路径。

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

然后配置环境变量。这里要说明一下：环境变量配置在/etc/profile里是所有用户生效，配在~/.bashrc里是当前用户生效。如果你是用hadoop这个专用用户来跑集群（强烈建议，不要用root跑Hadoop），那就配在该用户的~/.bashrc里：

export JAVA_HOME=/opt/jdk8 export PATH=$PATH:$JAVA_HOME/bin

配置完执行source ~/.bashrc，然后用java -version验证。这一步的重点是：三台机器都要装JDK，且版本必须一致，路径最好也一致（都放/opt/jdk8），否则后面启动YARN时会遇到各种诡异问题。

2.3 SSH免密登录：不止是省事，更是Hadoop的正常运行前提

很多人以为SSH免密只是省得每次输密码，这个理解不够。Hadoop的守护进程在启动时，NameNode需要通过SSH连到各个DataNode去远程执行启动脚本。如果免密没配好，启动过程要么卡住，要么失败。

配置方法分两步。第一步，在node1上生成密钥对：

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

第二步，把公钥分发到三台机器（包括node1自己）：

ssh-copy-id node1 ssh-copy-id node2 ssh-copy-id node3

为什么node1也要给自己做免密？因为NameNode节点上也有DataNode进程吗？不对，node1不跑DataNode的话，理论上不需要免密到node1。但SecondaryNameNode和ResourceManager都在node1上，某些管理操作仍需本机回环连接，所以建议node1自身也配置免密，以防后续扩展时踩坑。

验证方式很简单：在node1上执行ssh node2和ssh node3，能直接登录就是成功。

2.4 时钟同步与防火墙处理

这两个点经常被忽略，但它们引发的故障极具迷惑性。

时钟同步：如果各节点时间差超过一定阈值，Kerberos认证（如果开了安全模式）和一些RPC调用会直接失败。即使没开安全模式，时间不一致也会导致日志时间线错乱，排查问题极其痛苦。学习环境最简单的做法是：用yum install -y ntpdate安装后，让三台机器都执行ntpdate ntp.aliyun.com手动同步一次。如果你有更严格的需求，可以搭NTP服务端做周期性同步，但学习阶段手动同步就够了。

防火墙：很多教程上来就说“直接systemctl stop firewalld”，这在学习环境没问题，但你要明白你在做什么。关闭防火墙只是为了让集群通信不被打扰，生产环境必须开防火墙并配置放行规则。Hadoop相关的端口包括但不限于：8020（HDFS RPC）、9870（NameNode Web UI）、8088（YARN Web UI）、8042（NodeManager）、9000（HDFS RPC，可选）。学习环境图省事就关掉firewalld和SELinux：

systemctl stop firewalld systemctl disable firewalld sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config setenforce 0

改完SELinux建议重启机器，因为setenforce 0是临时方案，重启后如果没改配置文件会重新启用。

3. Hadoop安装与配置文件逐项拆解

3.1 下载解压与目录约定

去Apache官网或镜像站下载hadoop-3.3.6.tar.gz，传到node1上，然后解压：

tar -zxvf hadoop-3.3.6.tar.gz -C /opt/ mv /opt/hadoop-3.3.6 /opt/hadoop

目录约定这块说说我的习惯。Hadoop默认的配置在$HADOOP_HOME/etc/hadoop下，运行时的临时数据默认在/tmp下。但是/tmp目录在系统重启时会被清理，所以必须把数据目录指向一个持久化的路径。我通常会在/opt/hadoop下建这些目录：

• /opt/hadoop/tmp：存放HDFS的元数据和DataNode的数据块
• /opt/hadoop/pid：存放守护进程的PID文件
• /opt/hadoop/logs：存放运行日志

配置环境变量时把HADOOP_HOME和HADOOP_PID_DIR都指过去。这里有个经验之谈：不要用/root/hadoop这类路径，也不要用带空格的路径，否则后续配置会踩很多莫名其妙的坑。

3.2 六个核心配置文件，逐个说透

Hadoop的配置虽然文件多，但核心就六个。我把每个文件的关键项及含义写清楚，这些都是你面试时能直接讲出“为什么”的东西。

第一个是hadoop-env.sh。这个文件主要设置JAVA_HOME和HADOOP_HOME的环境变量。在Hadoop 3.x中，你还需要关注HDFS和YARN的守护进程内存设置：

export JAVA_HOME=/opt/jdk8 export HADOOP_HOME=/opt/hadoop export HADOOP_PID_DIR=/opt/hadoop/pid export HDFS_NAMENODE_USER=root export HDFS_DATANODE_USER=root export HDFS_SECONDARYNAMENODE_USER=root export YARN_RESOURCEMANAGER_USER=root export YARN_NODEMANAGER_USER=root

最后四行是很多新手容易遗漏的。Hadoop 3.x默认启用了HDFS_NAMENODE_USER等用户检查，如果你用root启动却不在这个文件里显式声明允许的账号，就会报“Attempting to operate on hdfs namenode as root”错误。

第二个是core-site.xml。这个文件配置的是集群级别的核心属性，最重要的就是fs.defaultFS：

<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://node1:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/hadoop/tmp</value> </property> <property> <name>hadoop.http.staticuser.user</name> <value>root</value> </property> </configuration>

fs.defaultFS定义了NameNode的RPC通信地址，客户端和DataNode都会通过这个地址联系NameNode。hadoop.tmp.dir是所有临时数据的根目录，注意这个目录会被NameNode和DataNode共用，但它们的实际存储路径还要看hdfs-site.xml中的具体配置。

第三个是hdfs-site.xml。这个文件直接决定了HDFS的副本策略和主节点元数据存储位置：

<configuration> <property> <name>dfs.namenode.name.dir</name> <value>file:///opt/hadoop/tmp/dfs/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:///opt/hadoop/tmp/dfs/data</value> </property> <property> <name>dfs.replication</name> <value>3</value> </property> <property> <name>dfs.namenode.http-address</name> <value>node1:9870</value> </property> <property> <name>dfs.permissions.enabled</name> <value>false</value> </property> </configuration>

dfs.replication设为3，这是HDFS的默认副本数。因为我们刚好有2个DataNode，这里要提个醒：如果集群只有2个DataNode，而副本数设为3，数据写入时会提示“Not Enough Replicas”，因为第三个副本确实没地方放。所以要么加节点，要么把副本数临时调成2。不过我建议维持3，因为这样能让你直观看到副本不足的报错，理解副本机制的含义。

dfs.permissions.enabled设为false是为了避免权限问题打断学习节奏。生产环境必须开启，但学习阶段可以先关上，有些教程不告诉你这个，你拿着root上传文件都可能报Permission denied。

第四个是mapred-site.xml。这个文件决定MapReduce运行在什么框架上：

<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> <property> <name>mapreduce.application.classpath</name> <value>$HADOOP_HOME/share/hadoop/mapreduce/*:$HADOOP_HOME/share/hadoop/mapreduce/lib/*</value> </property> </configuration>

在Hadoop 3.x中，如果mapreduce.application.classpath配得不全，运行WordCount时会报“ClassNotFoundException: org.apache.hadoop.yarn.util.ConverterUtils”，这个坑我见过无数人踩。

第五个是yarn-site.xml。这个文件配置资源调度器相关参数：

<configuration> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> <property> <name>yarn.nodemanager.aux-services.mapreduce_shuffle.class</name> <value>org.apache.hadoop.mapred.ShuffleHandler</value> </property> <property> <name>yarn.resourcemanager.hostname</name> <value>node1</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_HOME,PATH,LANG,TZ</value> </property> </configuration>

yarn.nodemanager.aux-services是关键中的关键。MapReduce任务运行时的Shuffle阶段需要通过这个辅助服务来传输Map输出数据。如果你漏配，任务会在Reduce阶段卡在88%左右不动。

第六个是workers文件（在Hadoop 3.x中叫workers，在2.x中叫slaves）。这个文件列出所有DataNode和NodeManager的主机名：

node2 node3

注意：不要把node1写进去，因为node1只跑NameNode和ResourceManager。如果你把node1也写进去，它会变成一个既是主又是从的“四不像”，虽然没有致命错误，但不推荐。

3.3 配置分发：一键同步到所有节点

配置文件在node1上改完后，需要同步到node2和node3。最简单的方式是用scp命令：

scp -r /opt/hadoop node2:/opt/ scp -r /opt/hadoop node3:/opt/

这里要注意同步的是整个hadoop安装目录，因为里面包含了配置文件和依赖包。如果你的JDK路径在三台机器上一致，就不需要额外同步JDK。如果JDK路径不同，那就要去每台机器的hadoop-env.sh里单独修改JAVA_HOME。

顺便再说一句：环境变量也要同步。在node2和node3的~/.bashrc里添加和node1一样的Hadoop相关配置就行了。

4. 初始化与启动：最激动人心也最容易翻车的环节

4.1 格式化NameNode：一次性的操作，别手滑执行两遍

正式开始之前，先执行一次NameNode的格式化。这个操作会在元数据目录中生成初始的fsimage文件，同时会生成一个随机的clusterId。

hdfs namenode -format

看到输出中有一行“Storage directory ... has been successfully formatted”就是成功了。

重点提醒：这个命令只能执行一次。如果你在执行完、已经启动集群后，因为某些故障又执行了一遍，那么NameNode的clusterId会变化，而DataNode里存的是旧的clusterId，启动时DataNode会发现不匹配，拒绝注册。现象是NameNode一直处于SafeMode，DataNode的日志一直刷“Incompatible clusterIDs”。

如果你真的不小心格式化了两次，解决办法是：把/opt/hadoop/tmp目录下所有节点（包括DataNode）的清空，然后重新格式化。注意是所有节点的，不是只清NameNode一台。

4.2 启动HDFS和YARN：先看进程，再看日志

格式化完成后，在node1上执行：

start-dfs.sh start-yarn.sh

启动成功后，分别在每台机器上执行jps命令查看Java进程。正常情况下：

• node1：NameNode、SecondaryNameNode、ResourceManager
• node2：DataNode、NodeManager
• node3：DataNode、NodeManager

新手最容易犯的错是只站在node1上执行jps，然后觉得“怎么只有NameNode”。一定要去每台机器上看。

如果某个进程没有启动，先别急着重启，先去日志目录看日志：

tail -100 /opt/hadoop/logs/hadoop-xxx-namenode-node1.log

日志文件命名规则是hadoop-<用户名>-<角色>-<主机名>.log。看日志是排查问题的基本功，这比在网上盲搜问题描述高效得多。

4.3 Web UI验证：用浏览器直观确认集群状态

Hadoop启动后，可以通过Web界面验证集群状态：

• HDFS界面：http://node1:9870，这里能看到NameNode状态、DataNode列表、集群存储容量
• YARN界面：http://node1:8088，这里能看到ResourceManager的调度情况、已提交的应用程序列表

如果你是在虚拟机里装的Linux，Windows宿主机访问不到，那就先在Linux本机用curl http://node1:9870验证一下。我建议直接把hosts文件里的映射加到Windows的C:\Windows\System32\drivers\etc\hosts里，这样直接浏览器输入node1:9870就能访问，省去记IP的麻烦。

4.4 跑通第一个测试用例：WordCount不是孤例

集群启动只是第一步，跑通一个真正的MapReduce任务才算验证了整个链路。Hadoop自带的示例jar包就在/opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar里。

先创建测试目录并上传文件：

hdfs dfs -mkdir -p /test/input echo "hello world hello hadoop" | hdfs dfs -put - /test/input/test.txt

然后提交WordCount任务：

hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar wordcount /test/input /test/output

执行完后查看结果：

hdfs dfs -cat /test/output/part-r-00000

正常会输出：

hadoop 1 hello 2 world 1

第一次能完整跑通这个流程，你对Hadoop的认知会从“概念层面”落到“实操层面”。如果中途任务失败，去YARN的Web UI找到失败的Application，点进去查看日志，这是定位问题的最快途径。

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

5.1 DataNode启动后立刻消失

症状：start-dfs.sh后node1的NameNode正常，但node2和node3的DataNode一启动就退出。

排查思路：不要盯着终端输出看，直接看日志：

tail -100 /opt/hadoop/logs/hadoop-root-datanode-node2.log

最常见的原因是clusterId不一致，也就是前面说的——你格式化操作执行了两次以上。解决方法是清空所有节点的/opt/hadoop/tmp目录，然后只格式化一次，再启动。

另一个常见原因是dfs.datanode.data.dir指定的目录没有写权限，或者目录的属主不是启动用户。比如用root启动，但目录属主是hadoop用户，也会报权限错误。

5.2 ResourceManager能在node1启动，但NodeManager连不上

症状：node2和node3的NodeManager一直显示“Unhealthy”或者连接被拒。

排查思路：先确认node2和node3的yarn-site.xml里的ResourceManager地址是不是node1。有些人在复制配置时把yarn.resourcemanager.hostname也原封不动地写成了其他机器，导致NodeManager去连接一个不存在的ResourceManager。

另外注意yarn.nodemanager.env-whitelist里的配置项，如果该列表缺少必要的环境变量，NodeManager启动容器时会报“Invalid environment”错误。把你看到的那一行直接抄过去，基本就没问题了。

5.3 网络通信问题排查

症状：能够启动进程，但HDFS客户端连接超时，或DataNode发送心跳失败。

排查思路：先在node1上执行ping node2和ping node3，看基础网络是否通。然后检查防火墙是否关闭。最后检查hosts文件的映射是否一致——注意是所有节点都要有一致的映射，如果你只在node1上写了映射，node2上没写，那么node2解析不了node1，也会出问题。

另一个比较容易忽略的地方是：虚拟机的网络模式发生了漂移。比如你配置的时候用的是NAT模式，但克隆的时候变成了桥接模式，导致IP变了。这个坑在克隆虚拟机时特别常见，建议每次克隆完都检查三台机器的IP和hosts是否还对得上。

5.4 磁盘空间不足导致数据块写入失败

症状：往HDFS上传数据时提示“There are X missing blocks”，但集群看起来一切正常。

排查思路：很可能是DataNode磁盘满了。HDFS的副本策略会尽量平均分布数据，但如果某台机器的DataNode目录空间不足，它会尝试换一个目录或节点，而如果都没有空间，就会报missing blocks。用df -h检查各节点的磁盘使用率，清理掉日志文件或大文件即可。

还有一个隐藏因素：hadoop.tmp.dir默认的数据目录在/tmp下，系统重启后该目录被清理，但NameNode和DataNode的目录结构还在，会导致启动异常。把你core-site.xml里的hadoop.tmp.dir改到持久化目录，能彻底规避这个问题。

5.5 常见问题速查表

现象	可能原因	解决办法
NameNode启动失败，提示元数据目录不存在	未执行格式化或格式化失败	检查dfs.namenode.name.dir路径，执行hdfs namenode -format
DataNode启动失败，日志提示clusterId不匹配	格式化执行了多次	清空所有节点的tmp目录，重新格式化一次
MapReduce任务卡在Reduce 88%	yarn-site.xml中aux-services未配置	添加mapreduce_shuffle配置并重启YARN
上传文件报Permission denied	dfs.permissions.enabled为true	学习阶段改为false，或使用hdfs用户操作
NodeManager状态为Unhealthy	本地磁盘目录不可写或空间不足	检查/opt/hadoop/tmp目录权限，清理磁盘

5.6 经验之谈：日志才是最好的老师

这节放到最后，是因为它比任何一条具体故障都有价值。很多人在集群出问题时，第一反应是去搜索引擎复制报错信息，这没错，但你至少应该先看一眼日志文件的报错上下文。

我见过有人把同一个故障在网上搜了一下午，其实日志里就已经明明白白写了具体原因，比如“Permission denied”或者“No such file or directory”。Hadoop的日志做得相当详细，几乎每个组件都有独立的日志文件，遇到问题先做这两步：

1. 找到对应节点的/opt/hadoop/logs/目录下跟涉及角色相关的日志
2. 用tail -200查看报错后20~50行的完整堆栈

这两步能解决80%的问题。剩下20%的情况，再去搜索引擎搜报错关键字，你会发现自己搜得也更精准。

6. 启动验证与冷备要点：让集群生命周期更稳定

6.1 常用启停命令小结

集群的启停命令，关键在于执行位置和顺序。

启动HDFS：在NameNode所在节点（node1）上执行start-dfs.sh，它会自动通过workers文件启动所有DataNode。 启动YARN：同样在node1上执行start-yarn.sh，自动启动所有NodeManager。 停止集群：在node1上执行stop-dfs.sh、stop-yarn.sh。

有些版本的教程会让你在每台机器上单独执行命令，那太原始了。Hadoop自带的start/stop脚本就是设计来分布式管理守护进程的，前提就是SSH免密配置好。

另外，如果你修改了配置文件，不需要重启整个集群。HDFS的配置可以动态刷新：

hdfs dfsadmin -refreshNodes

YARN的配置动态加载：

yarn rmadmin -refreshQueues

但这不包括修改了端口、地址这类必须重启才生效的参数。学习阶段，改完配置直接重启集群是最保险的。

6.2 SecondaryNameNode的冷备价值

很多教程里SecondaryNameNode往往被一笔带过，但它在HDFS的元数据安全中扮演的角色值得单独说。它所做的“定期合并fsimage和edits log”操作，本质上是为NameNode减负，防止edits log无限增长。如果NameNode发生故障，SecondaryNameNode的检查点数据能用来加速恢复，但它不是热备，不能自动接管服务。

所以我的建议是：SecondaryNameNode可以放在node2或node3上，至少要与NameNode分开，这样才能起到“故障分散”的意义。但在我们前面这个三节点规划里，node2和node3跑着DataNode，如果你还把SecondaryNameNode放过去，会增加那台机器的内存压力。所以最务实的做法还是暂时放在node1——学习阶段的单点问题，等你理解了集群原理后再去优化。

6.3 后续扩展方向

搭建完成不等于结束。我强烈建议你在跑通WordCount之后，主动做这几件事：

1. 把副本数从2或3改一次，重新上传一个文件，观察每个块在不同DataNode上的分布变化
2. 手动kill掉一个DataNode进程，然后操作文件，观察HDFS的容错复制过程
3. 在YARN上提交一个自定义的MapReduce程序（比如简单的词频统计），体会编写和调度的完整链路

这三件事做完，你对Hadoop的理解才真正从“会搭”迭代到“会用”。

写在后面的话

搭集群这件事，第一次翻车很正常。我见过太多人在格式化、免密、防火墙这些环节反复折腾，这恰恰说明你在建立“系统化排查”的能力。什么技术文档都不如自己踩一遍坑学得快。等你把这一套流程跑到行云流水，你会发现很多大数据的“高级问题”，根子上还是这些基础概念没吃透。

如果再往后走，你可以在这个集群上装ZooKeeper、HBase、Spark、Flink，让这套环境陪伴你走完整条大数据学习路线。但无论后面加什么组件，HDFS和YARN这两个地基都不会变。把今天这块地基夯实了，后面盖什么楼都不慌。