企业官网建设流程全解析

简介：面向大数据基础课程学习者和实验新手，这份实验报告完整记录了Linux下Hadoop集群搭建的流程，包含CentOS安装、Java环境配置、SSH免密登录、主机名与IP设置、Hadoop安装与核心文件修改、分布式集群验证等环节。无论单机伪分布式还是多节点集群，均可按报告步骤逐步部署。报告在疑难小结中梳理了HDFS安全模式、NativeCodeLoader加载失败、SSH反向解析异常、8088端口无法访问等常见问题的解决命令，具有较强的排错参考价值。资源为1个doc文档，压缩包约120KB，以图文结合方式呈现操作步骤、配置参数与进程状态，既可直接用于课程实验报告，也可作为集群搭建与问题排查的速查参考手册。该资源目前已有4666人学习下载，适合正在做大数据基础实验或准备快速搭建Hadoop集群的读者参考使用。

1. 为什么说 Linux 环境下 Hadoop 集群的搭建与基本配置，最难的往往不是配置文件

做大数据实验最磨人的不是写 MapReduce，而是先把 Linux 环境下的 Hadoop 集群跑起来。你在单机上把伪分布式装得再顺，换到三台虚拟机就各种起不来；教材里一句话带过的格式化，够你折腾一晚上。这篇按最小三节点集群来拆 Linux 环境下 Hadoop 集群的搭建与基本配置：先定拓扑，再做 JDK、SSH 免密、时钟同步这类前置，然后逐份过配置文件，最后给出能自检的启动流程。适合正在做 Hadoop 课程设计、或者刚接触集群的运维新手照着复现，我会把踩过的坑提前标出来，尽量让第一遍就能跑通。

2. Linux 环境搭建前的三件套：JDK、SSH 免密、时钟同步，少一件后面都是玄学

2.1 节点规划：三台虚拟机怎么做，资源配置才不翻车

Hadoop 集群最少三台机器起步，再多也建议从三台开始练，因为两个 DataNode 就足以验证副本机制的完整链路。主节点运行 NameNode、ResourceManager 和 SecondaryNameNode，两个从节点运行 DataNode 与 NodeManager。课程实验阶段我用的是 NAT 网络的三台 CentOS 虚拟机，内存是最大瓶颈，单机低于 2G 后面 YARN 很容易出问题。

这里有个容易搞混的概念：伪分布式和真集群不一样。伪分布式是单机上多个 Java 进程模拟角色分工，它验证的是配置能读通；真集群验证的是主机名解析、端口互通、免密登录和时间同步，多了整整一层网络问题。所以我建议课程设计别只做伪分布式，至少按三台虚拟机来搭建，否则面试时问你“DataNode 起不来怎么查”会直接卡住。实验阶段我习惯直接用 root 用户操作，省去权限报错，但如果你要长期跑，给 Hadoop 单独建一个用户更规范。

2.2 JDK 安装：为什么必须装 devel，java -version 不能证明配置成功

Hadoop 3.x 要求 JDK 8 及以上，课程实验保守选 JDK 8。装的时候注意要装 devel 版本，而不是 jre 版本，因为 Hadoop 启动脚本会调用 javac 相关工具链，只装 jre 会在执行 mapreduce 示例时报错。RHEL 系发行版（CentOS、Rocky Linux、OpenEuler）都可以用 yum 直接装。

yum install -y java-1.8.0-openjdk-devel # 自动解析 JAVA_HOME 真实路径 export JAVA_HOME=$(readlink -f $(which javac) | sed 's:/bin/javac::') echo "export JAVA_HOME=$JAVA_HOME" >> /etc/profile.d/hadoop.sh echo 'export PATH=$PATH:$JAVA_HOME/bin' >> /etc/profile.d/hadoop.sh source /etc/profile.d/hadoop.sh java -version

这段命令里最关键的是第二行：readlink 会把 /usr/bin/javac 的符号链接一层层解开，最终得到真实安装路径，然后用 sed 去掉 /bin/javac 尾巴。很多教程让你手写 JAVA_HOME，一旦系统更新路径变了就翻车，这个做法能让三台机器都自动取到正确路径。最后 java -version 只能证明 JRE 可用，不能证明 JAVA_HOME 被正确读取；要验证环境变量可以用 echo $JAVA_HOME，输出为空说明前面某个环节没生效。

2.3 SSH 免密登录：四条命令和两个权限坑

集群启动时 master 要通过 ssh 到每台 slave 上拉起进程，免密登录没配好，启动脚本就会停在密码输入界面，这就是很多人卡住的第一道坎。配置命令不复杂，但权限问题会在第二天反噬你。

# 生成空密码密钥对 ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa # 把公钥分发到三台机器（含自己） for host in master slave1 slave2; do ssh-copy-id $host done # 验证：三次都不该再问密码 ssh master hostname ssh slave1 hostname ssh slave2 hostname

ssh-copy-id 会自动把公钥追加到目标机的 authorized_keys。两个权限坑要提前说：~/.ssh 目录必须 700，authorized_keys 文件必须 600，否则 sshd 会忽略这个文件。首次 ssh-copy-id 会询问是否确认主机指纹，实验环境可以直接加 -o StrictHostKeyChecking=no 跳过确认。Linux 常用命令里，ssh、scp、jps、grep 在集群实验里重复率最高，闭眼能敲是对这轮实验的基本要求。

2.4 时钟同步：不装 chrony，第二天 HDFS 就开始报错

三台虚拟机跑久了时间会漂移，HDFS 内部大量依赖时间戳进行租约判断和数据块校验，时间偏差超过几十秒就会出现心跳丢失、DataNode 被误判宕机。这类报错不会直接说“时间不同步”，只会显示成各种诡异的连接超时，排查起来非常耗时间。

yum install -y chrony systemctl enable --now chronyd chronyc sources

chronyc sources 输出里能看到时间源处于已同步状态。三台机器里至少 master 要能连到外部时间源，slave 如果没外网也可以让它们向 master 对齐，但课程内网环境一般都能联网，直接用默认配置即可。有的同学为了省事，在 cron 里写 ntpdate 定时同步，这也能跑，但 chrony 更稳，启动后不用管。时钟同步是典型的“装的时候觉得多余，出问题时想不起来”的配置项，建议在实验开始前就固化到步骤清单里。

3. 从零开始安装 Hadoop：目录规划、环境变量与四份核心配置

3.1 安装包解压与目录规划：路径三台统一，后面 scp 才省心

从 Hadoop 官网下载 tgz 安装包后，解压和目录规划直接影响后面排错效率。我的习惯是统一装到 /opt/hadoop，用软链管理版本号。三台机器路径完全一致，后面 scp 分发时就不用写两套路径。不要装在 /tmp 或用户主目录下，重启或误删都会让你重新折腾一遍。

tar -zxvf hadoop-3.x.tar.gz -C /opt/ ln -s /opt/hadoop-3.x /opt/hadoop chown -R hadoop:hadoop /opt/hadoop-3.x

把 3.x 替换成你实际下载的版本号。软链的好处是以后升级只需换链接指向。装好后记住三个关键目录：etc/hadoop 放配置，logs 放运行日志，data（你自定义的数据目录）放 HDFS 块数据。排错顺序永远是先看 logs 再看配置，而不是凭直觉乱猜。

3.2 环境变量与 hadoop-env.sh：JAVA_HOME 写死，别偷懒

环境变量配置分两层。第一层是 /etc/profile.d/hadoop.sh，给命令行交互用的；第二层是 hadoop-env.sh，给 Hadoop 启动脚本用的。很多新手只配了 profile，启动时 Hadoop 脚本找不到 JAVA_HOME，报错还看不懂，因为错误信息藏在日志深处。

# /etc/profile.d/hadoop.sh 内容 export HADOOP_HOME=/opt/hadoop export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop source /etc/profile.d/hadoop.sh hadoop version

接着编辑 $HADOOP_HOME/etc/hadoop/hadoop-env.sh，把 JAVA_HOME 写成绝对路径：

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk

注意：hadoop-env.sh 在执行时不加载 /etc/profile，所以不能用 $(which javac) 动态获取，必须写死路径。hadoop version 输出里会显示 Hadoop 版本和 Java 版本，如果 Java 一栏显示的是系统默认 JRE 路径，说明 hadoop-env.sh 没生效，回去检查注释是否被去掉。

3.3 四份核心配置文件：core-site、hdfs-site、yarn-site、mapred-site

四份 XML 文件决定集群行为，也是实验报告里占比最大的部分。配置原则是三台机器用同一份配置，区别只在于角色由主机名区分，而不是由配置文件区分。

core-site.xml 设置默认文件系统和临时目录：

<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://master:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/data/hadoop/tmp</value> </property> </configuration>

fs.defaultFS 决定所有 HDFS 路径的默认访问地址，写成 hdfs://master:9000 后，你执行 hdfs dfs -ls / 会自动连到这台机器。hadoop.tmp.dir 必须指向非 /tmp 路径，这是血泪教训：默认值在系统 /tmp 下，重启可能被清空，集群所有元数据直接蒸发。

hdfs-site.xml 设置副本数和元数据目录：

<configuration> <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/data/hadoop/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/data/hadoop/datanode</value> </property> </configuration>

副本数设 2 而不是 3，因为集群只有两个 DataNode，设 3 会导致所有文件长期处于副本不足状态，Web UI 一直告警但不报错，容易误导你以为是网络问题。name.dir 和 data.dir 手工指定后，格式化生成的元数据和块数据位置可控，后续清理也能有的放矢。

yarn-site.xml 设置资源调度参数：

<configuration> <property> <name>yarn.resourcemanager.hostname</name> <value>master</value> </property> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>2048</value> </property> </configuration>

aux-services 是 MapReduce 跑在 YARN 上的关键桥接配置，漏配的话作业提交后一直处于 ACCEPTED 状态，永远不进入 RUNNING。memory-mb 要根据机器实际内存调，2G 的机器配 2048 已经是上限，配高了 NodeManager 直接起不来。

mapred-site.xml 需要注意它默认不存在，模板文件叫 mapred-site.xml.template：

cp $HADOOP_HOME/etc/hadoop/mapred-site.xml.template $HADOOP_HOME/etc/hadoop/mapred-site.xml

<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> </configuration>

这个配置指定 MapReduce 作业跑在 YARN 上，而不是 local 模式。不配的话作业会在本地进程里跑，你根本看不出分布式效果。

3.4 workers 文件与节点分发：scp 同步的边界

Hadoop 3.x 用 workers 文件记录所有从节点主机名，2.x 时代叫 slaves。这里写主机名而不是 IP，前提是 /etc/hosts 三台机器都配置完整。写完后把整个 /opt/hadoop 目录同步到两台 slave，再同步环境变量文件，就可以开始第一次启动。

cat > $HADOOP_HOME/etc/hadoop/workers << 'EOF' master slave1 slave2 EOF for host in slave1 slave2; do scp -r /opt/hadoop root@$host:/opt/ scp /etc/profile.d/hadoop.sh root@$host:/etc/profile.d/ done

分发完成后在每台机器都跑一次 hadoop version，确认三台输出一致。这里有个容易被忽略的边界：workers 文件里写了 master 自己，意味着 master 也会启动 DataNode，这在三节点实验里是正常设计，也是副本数能设 2 的前提。如果你只想让 master 当纯粹的管理节点，workers 里就不写 master，但那样两个 DataNode 存两份副本依然成立，只是 master 机器资源利用率变低。

4. 格式化 NameNode 与首次启动：从一条命令查到 Web UI

4.1 格式化前最后一遍检查：四个命令，三十秒

格式化是不可逆操作，所以执行前我习惯把系统检查一遍，至少确认三件事：主机名解析正确、免密登录畅通、软件版本一致。这三十秒能省下后面一小时的排错时间。

cat /etc/hosts ssh master hostname && ssh slave1 hostname && ssh slave2 hostname hadoop version free -h

重点检查 /etc/hosts 里有没有把 master 解析到 127.0.0.1。如果写了 127.0.0.1 master，NameNode 会监听在回环地址，slave 根本连不上 9000 端口。这个坑在 Ubuntu 系统上尤其常见，因为默认 hosts 文件里写了 127.0.1.1 指向主机名。

4.2 hdfs namenode -format：一次性的黑匣子

格式化命令就一条，但它背后做的事值得花两分钟理解。它会在 dfs.namenode.name.dir 指定的目录下生成 current 目录，里面包含 fsimage 和 edits 等元数据文件，同时生成一个 clusterID。这个 clusterID 会被 NameNode 写入元数据，之后 DataNode 启动时会读取这个 ID 来确认自己属于哪个集群。

hdfs namenode -format

格式化只能成功一次。如果第二次执行，clusterID 会更新，而 DataNode 那边还留着旧的 clusterID，启动后 DataNode 报错并退出，Web UI 显示 Live Nodes 为 0。很多教程没说清楚这一点，导致新手来回格式化越弄越糟。格式化成功的标志是日志里出现 Storage directory /data/hadoop/namenode has been successfully formatted。

4.3 启动顺序：先 HDFS 后 YARN，再对照 jps 结果

启动集群推荐分开执行 start-dfs.sh 和 start-yarn.sh，不要用 start-all.sh。分开启动的好处是，任何一步失败都能从对应日志快速定位，start-all.sh 把所有进程混在一起，日志错乱反而难查。

$HADOOP_HOME/sbin/start-dfs.sh $HADOOP_HOME/sbin/start-yarn.sh

启动完成后在每台机器上执行 jps 对照进程。master 上应该有 NameNode、SecondaryNameNode、ResourceManager，slave 上应该有 DataNode、NodeManager。Jps 是个辅助进程，顺便认识一下，不用当回事。

# master 节点执行 jps，应看到： # NameNode # SecondaryNameNode # ResourceManager # slave 节点执行 jps，应看到： # DataNode # NodeManager

哪个进程不在，先去对应的 logs 目录看日志。比如 DataNode 没起来，就看 $HADOOP_HOME/logs/hadoop-root-datanode-主机名.log 的最后几十行。日志里通常直接写了失败原因，比瞎改配置有效得多。

4.4 Web UI 与基本配置验证：9870 和 8088 都要看一眼

进程都起来后，用浏览器打开 master 的 Web UI 验证。Hadoop 3.x 的 HDFS 管理页面在 9870 端口，YARN 页面在 8088 端口。如果你看到的是 50070，说明你用的是 2.x 版本，端口按你的实际版本来。课程实验报告里截图这两张页面是加分项，但别只截页面，要把 Live Nodes 的数字一起截进去。

# 命令行验证数据节点状态 hdfs dfsadmin -report

这个命令输出每个 DataNode 的存储容量和状态，重点看 Live DataNodes 数量是否为 2，Dead DataNodes 是否为 0。接着做一个最小粒度的读写验证：

hdfs dfs -mkdir -p /user/exp hdfs dfs -put /etc/hosts /user/exp/ hdfs dfs -cat /user/exp/hosts | head -5 hdfs fsck /user/exp/hosts -files -blocks -locations

fsck 是理解 HDFS 副本机制的钥匙。执行后能看到这个文件有几个 block，每个 block 分布在哪些机器上，副本数是否健康。如果显示 2 份副本都健康，说明你的基本配置已经完全生效，集群不只是“能启动”，而是真的在工作。

5. Hadoop 集群搭建避坑指南：五个翻车现场与排查顺序

5.1 DataNode 起不来，日志出现 Incompatible clusterIDs

现象：start-dfs.sh 执行成功，但 slave 机器上没有 DataNode 进程；Web UI 里 Live Nodes 显示 0；日志报 Incompatible clusterIDs。

原因：NameNode 被格式化过两次以上。第二次格式化生成了新的 clusterID，而 DataNode 数据目录里还保留第一次的 clusterID，两边对不上，DataNode 自动退出。

解决：在 master 上停掉 HDFS，然后把所有节点上的 dfs.datanode.data.dir 目录删掉，回到 master 重新格式化，再启动。注意：格式化会清空集群里所有文件，所以如果你想保留实验数据，先把 HDFS 里的文件导出到本地。我在课程设计阶段就吃过这个亏，写好的测试数据全没了，只能重跑。

5.2 启动集群时还要输密码，免密配置形同虚设

现象：start-dfs.sh 执行后终端提示输入 slave 的密码，脚本卡住不动。

原因：ssh-copy-id 分发公钥时用的用户，和你当前执行启动脚本的用户不一致。比如公钥分发给 hadoop 用户，现在却用 root 执行启动；或者 authorized_keys 权限是 644，sshd 出于安全考虑拒绝使用。

解决：先确认你执行启动脚本的用户，然后用对应用户重新执行一遍 ssh-copy-id。顺带检查权限：

chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys ssh master hostname

如果这几条命令全部免密通过，再执行启动就不会卡密码了。

5.3 NodeManager 启动后秒退，日志报内存不足

现象：slave 上执行 jps 能看到 NodeManager，过几秒再执行就没了；日志里出现 Error: Could not reserve enough space for object heap。

原因：yarn.nodemanager.resource.memory-mb 配得比虚拟机实际内存还大。比如你给 slave 分了 1G 内存，却把 memory-mb 配成 2048，NodeManager 想申请 2G 堆内存直接失败。

解决：用 free -h 看实际可用内存，memory-mb 设成实际内存的 60% 到 70%。1G 内存的机器建议配 1024 或更保守的 768；2G 内存配 2048 也勉强。实验环境还可以在 yarn-site.xml 里把 yarn.nodemanager.vmem-check-enabled 设为 false 关闭虚拟内存超限检查，但这只是止血，不是根解法。

5.4 master 上正常，slave 却连不上 9000 端口

现象：master 上执行 hdfs dfs -ls 一切正常，slave 上执行同样命令报 Connection refused；master 本机用 curl 访问 Web UI 正常，其他机器浏览器打不开页面。

原因：/etc/hosts 里把 master 的主机名映射到了 127.0.0.1 或 127.0.1.1。NameNode 启动时解析自己的主机名，得到回环地址，就只监听了本机回环接口，外部网络连不上。另一个可能性是防火墙没关。

解决：把 /etc/hosts 里 master 对应的行改成内网 IP。然后停掉集群重启。检查监听状态用这条命令：

ss -lntp | grep 9000

如果输出里的 IP 是 127.0.0.1，说明 hosts 解析有问题；如果是 192.168.x.x，说明监听正常。防火墙问题在 CentOS 7 上很常见，实验环境直接 systemctl stop firewalld 就行，生产环境再考虑按端口放行。

5.5 重启虚拟机后 HDFS 数据全部消失

现象：虚拟机重启后，hdfs dfs -ls 报错或显示目录不存在，所有上传的文件都没了。

原因：hadoop.tmp.dir 没改，还使用默认的 /tmp 目录。Linux 的 /tmp 会在系统重启后被清理，HDFS 的元数据和临时文件被一起清掉，集群相当于格式化前的状态。

解决：把第 3 章的 hadoop.tmp.dir、dfs.namenode.name.dir、dfs.datanode.data.dir 全部指到固定路径，比如 /data/hadoop 下。改完以后需要重新格式化一次，然后把数据重新上传。这个坑属于配置习惯问题，越早改越好，别非要等到重启后才后悔。

6. 配置落地后先跑 WordCount：三种验证方式与一个检查脚本的习惯

集群能起来只是第一步，基本配置有没有真正打通，跑一次 Hadoop 自带示例最直接。WordCount 是每个 Hadoop 实验绕不开的第一个作业，也是验证全链路的标准动作。

hdfs dfs -mkdir -p /user/exp/input hdfs dfs -put $HADOOP_HOME/etc/hadoop/core-site.xml /user/exp/input/ hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \ wordcount /user/exp/input /user/exp/output hdfs dfs -cat /user/exp/output/part-r-00000

hadoop-mapreduce-examples 的 jar 包会匹配你安装的实际版本号。wordcount 的输出目录不能提前存在，否则作业直接报错，这是 mapreduce 作业的一个常见约束。作业跑完以后，part-r-00000 是 reducer 输出的结果文件，能用 hdfs dfs -cat 打开说明 HDFS 读写、YARN 调度、MapReduce 计算三层都已贯通。如果作业卡在 ACCEPTED 状态，回头检查 yarn-site.xml 的 aux-services 是否配了 mapreduce_shuffle。

我现在的习惯是把一套检查命令固化成启动后的固定动作，每次集群起来都跑一遍再干活。这套命令不是每次都从头看一遍，而是用来把集群健康检查时间压缩到十分钟以内：

hdfs dfsadmin -report | grep -A2 'Live DataNode' hdfs fsck / -files -blocks yarn application -list

第一行确认节点存活，第二行确认文件系统没有损坏块，第三行确认 YARN 能接收新作业。三个输出都正常，再开始跑业务。如果你下一步想把集群接进 IDE 调试，比如用 Eclipse 提交作业，注意客户端机器的 core-site.xml 必须指向集群的 fs.defaultFS，不要只改本地 hosts 就以为连上了——当年我为了这个折腾半天，最后发现是客户端的配置文件压根没同步。Hadoop 集群搭建这个方向，值得你多花时间把底层配置吃透，因为后面调优、扩展、上 HA 都要基于这套基础。希望帮到你。

本文还有配套的精品资源，点击获取