简介：这是一份基于鲲鹏云平台的大数据实验报告，面向高校学生、云计算与大数据初学者，系统记录了在华为云ECS与OBS环境下从零搭建Hadoop集群的完整流程。报告为docx格式，压缩包内共1个文档文件，大小2.52MB，已有892人学习下载。实验内容涵盖华为云环境准备、OBS桶创建与AK/SK密钥获取、节点互信与SSH免密登录、Hadoop安装包分发、core-site.xml等核心配置文件的逐一修改，以及NameNode初始化和HDFS启动等关键环节。针对部署中频繁出现的Java home路径错误，报告专门记录了重新分发软件包、修正/etc/profile并同步各节点环境变量的排错过程，真实还原了云上集群调试的第一手经验。读者可借这份报告快速把握鲲鹏云大数据平台的搭建要点，也可作为课程实验、毕业设计或企业预研时的操作参考。
1. JAVA_HOME 连环报错：搭建 Hadoop 集群最折腾人的一个开头
“Error: JAVA_HOME is not set and could not be found.” 这句话我在这份鲲鹏云大数据实验报告里反复看到，每一轮几乎都跟着一句“执行失败，更改 javahome 的目录”。从解压 Hadoop、向 /etc/profile 写入环境变量，到 NameNode 初始化、启动 HDFS、执行 hdfs 命令，一连串操作全部被同一个原因卡住。java -version 明明能打印版本号，OpenJDK 也确实装好了，可 Hadoop 的脚本就是找不到 JDK，这种黑匣子一样的表现最让人抓狂。如果你也在搭自己的大数据实验环境，也被这种环境变量改来改去依然报错的情况折磨，下面这套复盘值得看完：JAVA_HOME 是怎么让整条链路连环翻车的，节点互信和配置分发里还藏着哪些坑，以及下一次如何快速定位。
2. 环境准备阶段的三个隐性坑：ECS 连通、OBS 鉴权与 AK/SK 保管
在正式碰 Hadoop 之前，这套实验花了不少篇幅准备云环境：购买弹性云服务器 ECS、开通对象存储服务 OBS、创建并行文件系统、下载 credentials.csv 拿到 AK/SK。这一步看起来都是控制台点选，但恰恰是后面所有报错的“前哨”。我见过不少人在 Hadoop 配置里折腾了半天，最后发现是 OBS 的 endpoint 区域不匹配，或者 AK/SK 里混进了换行符。环境没准备好，后面每一条报错都会让你误判成 Hadoop 的问题。
2.1 ECS 购买后 SSH 连不上：安全组规则比你想的更严格
现象是购买完成后，本地终端 ssh root@公网IP 直接超时，ping 也不通。第一次操作云环境的人通常会怀疑是密码错了、镜像坏了，实际上绝大多数情况是安全组没放行 ICMP 和 22 端口。云厂商默认安全组往往只放行部分端口，或者创建 ECS 时选了“不放行任何端口”的模板，公网流量根本进不来。
我一般会先在控制台用 VNC 登录进去，确认系统本身是好的，再回头查网络：
# 本机依次执行，确认哪一层不通 ping -c 3 <ECS公网IP> nc -zv <ECS公网IP> 22 ssh root@<ECS公网IP>参数说明：-c 3 表示只发三个 ICMP 包，避免一直 ping 下去；nc -zv 用来检测 22 端口是否开放，-z 是扫描模式，-v 输出详细信息。如果 ping 通而 nc 不通，基本可以断定是安全组入方向规则漏了 22；如果两者都不通，还要检查弹性公网 IP 是否已经绑定到实例上。
这个坑在实验里不太起眼，但它是后面所有 ssh 操作的前提。节点之间要配置互信、分发安装包，第一步就是三台 ECS 能互相连通。实验记录里后续每台节点都要执行 vim /etc/hosts 和 ssh 公钥复制，如果安全组把内网端口也挡了，免密登录会表现得“时好时坏”，非常像玄学。
2.2 OBS 报 403 AccessDenied：桶名、Endpoint 与 AK/SK 三项要同时匹配
实验在 core-site.xml 里要写入 OBS 的认证信息，包括访问密钥、私有密钥和 endpoint。它明确区分了两种地址：IPv4 地址适用于普通 IPv4 网络，双栈地址适用于 IPv6 双栈环境。很多人在这里翻车，是把双栈地址填进了纯 IPv4 的集群，结果 Hadoop 访问 OBS 时连接超时或直接 403。
报错 403 的排查顺序，我建议是：先确认 AK/SK 没复制错，再确认桶名只填桶名而不是整个 URL，最后确认 endpoint 和桶所在区域一致。实验里的桶是在 cn-north-4 区域创建的，core-site.xml 里却配了别的区域 endpoint，就会走错机房，鉴权自然失败。
下面的配置是实验里核心站点文件的 OBS 部分，参数我按通用写法给出：
<property> <name>fs.obs.access.key</name> <value>你的AK</value> </property> <property> <name>fs.obs.secret.key</name> <value>你的SK</value> </property> <property> <name>fs.obs.endpoint</name> <value>obs.cn-north-4.example.com</value> </property> <property> <name>fs.obs.bucket</name> <value>并行文件系统名称</value> </property>说明：endpoint 的值不要带 https:// 前缀，Hadoop 的 OBS 插件会自动拼协议；IPv4 环境不要填 dualstack 地址。桶名那一项，如果有人图省事把控制台里的“桶访问域名”整段搬进来，也会因为多出了区域后缀而报错。改完这些配置，记得要 scp 到所有节点，只改 node-0001 是没有意义的。
2.3 credentials.csv 里的 AK/SK：只下载一次，泄露等于裸奔
实验里有个关键动作：操作完成后得到文件 credentials.csv，打开就能拿到 AK/SK。这个文件云厂商只会让你下载一次，之后控制台不再提供完整密钥，只能重置。很多人把 csv 放在下载目录里，过几个月清理文件时发现备份没了，或者截图发出去，等于把云账户的钥匙交了出去。
我处理密钥的习惯是三步：第一时间移出下载目录、收紧文件权限、用环境变量注入而不是写死在配置里。
mkdir -p ~/.credentials mv ~/Downloads/credentials.csv ~/.credentials/obs-key.csv chmod 600 ~/.credentials/obs-key.csv export OBS_ACCESS_KEY_ID=$(awk -F',' 'NR==2{print $2}' ~/.credentials/obs-key.csv) export OBS_SECRET_ACCESS_KEY=$(awk -F',' 'NR==2{print $3}' ~/.credentials/obs-key.csv)说明：csv 第一行是表头 User Name,Access Key Id,Secret Access Key，第二行才是真实值，所以 awk 用 NR==2 取第二行，-F',' 按逗号分列后取第 2、3 列。chmod 600 保证只有 root 能读。这样做的另一个好处是，Hadoop 的 core-site.xml 里不需要明文出现密钥，后续把配置文件打包分发时，不用担心密钥被一起带出去。
注意：密钥一旦泄露，删除文件没有用，必须到控制台重置 SK，旧密钥会立即作废。
3. 同一个 JAVA_HOME 错误，为什么让 namenode 初始化、HDFS 启动、hdfs 命令连环翻车
这一章是整份实验记录里最值得复盘的部分。回顾原文，几乎每个关键节点都会出现同一个短语：更改 javahome 的目录。第一次是配置环境变量后执行报错；第二次是分发 hadoop 包之后；第三次是初始化 namenode；第四次是启动 HDFS、执行 hdfs 命令。同一个错，表面上是“这次失败了，改一下再试”，实际上背后有一个共同的根因链。
3.1 现象复盘：java -version 正常，Hadoop 却说找不到 JAVA_HOME
先看现象。执行 java -version 时，OpenJDK 正常输出版本号；执行 hadoop version 时，却报出类似下面的错误：
Error: JAVA_HOME is not set and could not be found.或者在 hadoop-env.sh 里配了路径但配错时，报：
Error: JAVA_HOME is not defined correctly. We cannot execute /usr/lib/jvm/java-1.8.0/bin/java这种割裂感是新手最容易误判的地方。bash 能执行 java，是因为 PATH 环境变量里有 /usr/bin，而 /usr/bin/java 是指向真实 JDK 的软链接；Hadoop 的启动脚本不读 PATH，只读 $JAVA_HOME，JAVA_HOME 一旦为空或指向不存在的目录，脚本就直接退出。所以 java -version 正常，恰恰证明不了 JAVA_HOME 是对的。
实验的报错轨迹也说明了这一点：先改 /etc/profile 后忘了 source，当前 shell 里 JAVA_HOME 还是旧的，namenode 初始化失败；重新 source 之后 hdfs 命令仍然失败，是因为 hadoop-env.sh 里的 JAVA_HOME 写死成了一个不存在的目录。脚本优先级问题，我放在下一节讲。
3.2 根因定位：aarch64 架构下 OpenJDK 的真实目录与脚本查找顺序
用系统包管理器装 openjdk 后，真实目录形如 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64。注意最后一段：aarch64。这套实验的节点是鲲鹏架构的 ARM 云主机，JDK 也是 ARM 版，路径里会带体系结构标识。常见的错误配置是照抄别人的路径，比如把 x86_64 或干脆把 /usr/lib/jvm/java-1.8.0 写进去。
问题在于 /usr/lib/jvm/java-1.8.0 在部分系统上是一个软链接，指向某个默认版本。Hadoop 的脚本拿到软链接路径后，会再去解析 jre/lib 目录，一旦解析结果和真实 JDK 结构不一致，就报 “JAVA_HOME is not defined correctly”。所以实验里反复“更改 javahome 的目录”，本质是把路径从“看起来对”改成“实测存在”。
Hadoop 脚本的查找顺序值得说清楚：它先看 hadoop-env.sh 里的 JAVA_HOME，再看系统环境变量 JAVA_HOME，最后尝试用 which java 兜底。与我们直觉相反，最后一步兜底用的也是软链接路径，如果 /usr/bin/java 本身是指向 /etc/alternatives/java 的再软链接，整条链很容易断。解决方向上，我会推荐一个“消解软链接”的做法，而不是去猜真实目录。
3.3 解决动作：锁定真实目录、建软链接固定入口、全节点统一
第一步先在节点上找到 JDK 真实安装目录：
ls -d /usr/lib/jvm/java-1.8.0-openjdk-*这一步会列出该节点上实际存在的 OpenJDK 目录，拿到的路径就是唯一的可信答案。第二步，把 JAVA_HOME 写入 /etc/profile，并顺手做一个固定软链接：
ln -sfn /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64 /usr/lib/jvm/java-8 export JAVA_HOME=/usr/lib/jvm/java-8 export PATH=$JAVA_HOME/bin:$PATH说明：ln -sfn 的 -s 表示软链接，-f 表示覆盖已有链接，-n 表示目标已存在时不递归。以后 JDK 小版本升级，只需要把源头路径换成新目录，三台机器的 /etc/profile 不用动，这是我在多节点环境里比较推荐的做法。
第三步也是最容易被忽略的：source /etc/profile 只对当前 shell 生效，重新登录的会话没问题，但当前终端里的旧值还在。实验里“上图执行失败，更改 javahome 的目录”反复出现，一半是路径问题，一半是改了没 source。检查命令要一连串执行：
source /etc/profile echo $JAVA_HOME ls -d $JAVA_HOME $JAVA_HOME/bin/java -version三条输出都能对上，才能认为这个节点的 Java 环境真正修好。然后才是把 /etc/profile 同步到 node-0002、node-0003。如果同步完不 source，子节点依旧报错，这就是实验里说的“分发 0002 由于 javahome 错误，重新分发”的真实原因。
4. 节点互信与配置分发：集群一半的“玄学报错”来自这里
三台 ECS 都在同一套实验流程里重复执行了 vim /etc/hosts、复制 ssh 公钥、配置免密登录、创建目录、解压包、改 profile。这些动作单独看都很简单，但放到集群层面，“每台机器都做了”和“每台机器都做对了”是两回事。Hadoop 的报错经常是跨节点的，最典型的是 namenode 起来了，datanode 却一直掉线。
4.1 SSH 免密登录失败：authorized_keys 权限与 yes/no 确认
实验里在复制公钥后写了“执行后选 yes 无密码跳转”。这个 yes 是第一次 ssh 时的主机指纹确认，很多人第一次看到 “Are you sure you want to continue connecting (yes/no)?” 会不知所措。选 yes 之后，指纹会写入 ~/.ssh/known_hosts，下次不再询问。
但免密登录失败最常见的原因不是 known_hosts，而是权限。sshd 对 .ssh 目录和 authorized_keys 文件的权限非常敏感：目录超过 700、文件超过 600，它会直接忽略这个公钥文件，表现就是仍然提示输入密码。手动 cat 追加公钥时，如果公钥被折行或者复制时丢了末尾的注释，也会静默失败。
我一般这样收敛操作：
# 在 node-0001 生成密钥，-N "" 表示空口令 ssh-keygen -t rsa -b 4096 -N "" -f /root/.ssh/id_rsa # 用 ssh-copy-id 分发到两台子节点 ssh-copy-id root@node-0002 ssh-copy-id root@node-0003 # 统一修正权限 chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys # 验证跳转 ssh node-0002 hostname说明：ssh-copy-id 会自动把公钥追加到对方的 authorized_keys 并修正权限，比自己 cat 追加稳妥。参数 -b 4096 是密钥长度，-N "" 跳过 passphrase，集群场景必须为空口令，否则每次 ssh 都要输密码。排错时如果仍然失败，加 ssh -vvv 看输出，重点看 “Authentication refused” 之前有没有权限告警。
4.2 配置分发不完整：node-0002 的 JAVA_HOME 是怎么“带病上岗”的
实验里出现了一段很有代表性的记录：“因为 javahome 错误，重新分发”“分发 0002 由于 javahome 错误，重新分发”。这说明分发动作本身做了，但分发的“内容”不完整。常见情况是把解压好的 hadoop 目录用 tar 或 scp 发过去了，但 /etc/profile 里新加的 JAVA_HOME 没跟着过去；或者 profile 发过去了，子节点没有执行 source。
另一个隐蔽问题：只分发了解压目录，没分发配置文件。Hadoop 的 etc/hadoop 下的 core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml、slaves 是集群行为的全部来源，node-0001 改完，子节点必须拿到同一份。我的建议是把配置文件和 profile 分开分发，并且每条命令后面都要跟验证：
# 统一 profile 后分发 scp /etc/profile root@node-0002:/etc/profile scp /etc/profile root@node-0003:/etc/profile # 分发 hadoop 配置目录 scp -r /home/modules/hadoop-2.8.3/etc/hadoop root@node-0002:/home/modules/hadoop-2.8.3/etc/ scp -r /home/modules/hadoop-2.8.3/etc/hadoop root@node-0003:/home/modules/hadoop-2.8.3/etc/ # 子节点立即生效并验证 ssh node-0002 "source /etc/profile && hadoop version" ssh node-0003 "source /etc/profile && hadoop version"说明：scp -r 会递归复制整个 etc/hadoop 目录，覆盖子节点上的同名文件。验证命令写成一条 ssh 远程执行，可以立刻暴露“profile 没生效”或“配置文件版本不一致”的问题，不用再登录进去手动敲。这个习惯帮我排掉了大量“为什么我改了没用”的疑案。
4.3 /etc/hosts 不一致与 slaves 文件：DataNode 掉线的隐蔽原因
HDFS 启动后，最典型的故障是：jps 能看到 node-0001 上 namenode 进程，但 node-0002、node-0003 的 datanode 起来几秒就退，去 logs 里翻，十有八九是 UnknownHostException 或者注册失败。
根因通常是 /etc/hosts 没有全局统一。实验里三台节点都执行了 vim /etc/hosts，如果只把本机 IP 映射写进自己那台，互相解析不了主机名，datanode 就无法向 namenode 注册。slaves 文件同样有讲究：它应该写子节点的主机名，而不是写 IP 或 localhost。写成 localhost 的后果是，集群只会在本机启动一个 datanode，另外两台永远是个“幽灵节点”。
这里给出一个统一 hosts 的写法，IP 部分用内网地址做示例，实际地址以你自己的环境为准：
# 三台节点写入完全相同的 hosts 内容 cat >> /etc/hosts <<EOF 192.168.1.11 node-0001 192.168.1.12 node-0002 192.168.1.13 node-0003 EOF# slaves 文件只写主机名，不写 IP，不写 localhost cat > /home/modules/hadoop-2.8.3/etc/hadoop/slaves <<EOF node-0002 node-0003 EOF说明：cat 追加 hosts 时，注意不要重复追加导致旧映射残留；最稳妥的做法是先用 sed 删除旧记录再写入。集群节点间通信用内网 IP，比公网 IP 稳定，安全组也更容易收敛。改完 hosts 后，每台机器都执行 hostname 和相互 ping 一遍，确认解析无误再启动 HDFS。
5. 避坑记录：Hadoop 集群搭建中反复出现的 5 个配置错误
这一章把上面几章里容易反复踩的位置单独拎出来，每条都是“现象 → 原因 → 解决”的固定结构，方便对照自己的报错现场。这些都是我在多套集群上实际遇到过的，不是从文档里抄来的理论。
5.1 改了 JAVA_HOME 还在报错：当前 shell 没 source
现象：node-0001 上修改了 /etc/profile，重新执行 hadoop version 依旧报 JAVA_HOME 找不到。
原因：/etc/profile 只在登录 shell 初始化时读取，当前终端早就启动完了，不会自动感知文件变化。
解决：每次改完必须 source /etc/profile，而且验证要在同一个 shell 里连续执行 echo $JAVA_HOME 和 $JAVA_HOME/bin/java -version。多节点操作时，用 ssh node-0002 "source /etc/profile && hadoop version" 这种远程命令验证，避免“以为生效了”。
5.2 endpoint 填了双栈地址，IPv4 网络一直连接超时
现象：core-site.xml 配置了 obs.dualstack 开头的地址，集群访问 OBS 时长时间卡住，最后超时。
原因：双栈地址面向 IPv4/IPv6 双栈网络，纯 IPv4 环境解析或握手异常。
解决：确认自己的网络和 VPC 是否开了 IPv6。没开就老实用 IPv4 地址；开了 IPv6 才考虑 dualstack。填 endpoint 时不带协议头，桶名不要带域名后缀。验证方式：在节点上 curl 一下 endpoint，能通再改配置，别让 Hadoop 替你背锅。
5.3 密钥泄露：从 csv 到日志，AK/SK 最容易在没有防备时暴露
现象：有同事把 credentials.csv 放在共享目录，或者把 export 命令写进 .bash_history 后日志被拖走，结果 OBS 桶被恶意读写。
原因：AK/SK 等同于云账户密码，csv 文件权限过宽，任何能登录这台机器的人都能读走。
解决：csv 下载后立刻 mv 到 ~/.credentials 并 chmod 600，export 语句用 read 从文件读取，避免留在 history 里。密钥泄露后不要只删文件，要到控制台重置 SK，旧 SK 作废。
5.4 分发只发解压目录，配置文件和 profile 没跟上
现象：node-0002 上 hadoop 命令能跑，但访问的 core-site.xml 还是默认配置，连不上 node-0001 的 namenode。
原因：分发时只 tar 或 scp 了 hadoop 主目录，etc/hadoop 下的修改后配置被覆盖或根本没发。
解决：把 etc/hadoop 整个目录单独分发，再把 /etc/profile 也分发并 source。分发完立刻跑一条远程 hadoop version 和 hdfs dfs -ls 验证，别急着启动全部服务。
5.5 在 ARM 节点下载了 x86_64 的 JDK 或 Hadoop 包
现象：解压后执行 java -version 报 Exec format error，或者 Hadoop 脚本启动到一半进程消失。
原因：鲲鹏节点是 aarch64 架构，下载了 x86_64 架构的 OpenJDK 或二进制包，内核直接拒绝执行。
解决：下载前确认包名里带 aarch64。实验里的 JDK 路径 java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64 就是 ARM 版。下载后用 file /路径/java 看 ELF 信息，出现 “aarch64” 才是正确架构。
6. 快速定位这类故障的三板斧：日志、diff、一键校验
三台节点的 Hadoop 集群，故障定位最忌讳逐台登录、逐条命令试。我的做法是固定三件事：先看日志缩小范围，再 diff 配置找差异，最后用一条循环命令把三台机器的关键环境一次性打出来。这份鲲鹏云大数据实验报告的资源，完整保留了这条链路每一步的操作和修正记录，放在手边对照能省很多时间。
先看日志。HDFS 和 YARN 的日志都在 hadoop 安装目录的 logs 子目录下，namenode 日志文件名形如 hadoop-root-namenode-node-0001.log，datanode 对应 hadoop-root-datanode-node-0002.log。遇到进程起来又退，直接执行：
grep -E "ERROR|Exception" /home/modules/hadoop-2.8.3/logs/*.log | tail -20看到 UnknownHostException 就去查 hosts；看到 AccessDenied 就去查 OBS 的 AK/SK 和 endpoint；看到 JAVA_HOME 相关直接去查 profile。报错信息会自己指路。
再 diff 配置。三台机器配置漂移是集群故障的最大来源，把子节点的 profile 拉回来和 node-0001 对比：
scp root@node-0002:/etc/profile /tmp/profile-node-0002 diff /etc/profile /tmp/profile-node-0002diff 无输出说明两边一致，有输出就看差异在哪一行。这个动作比登录三台机器肉眼检查快得多，也适合对 etc/hadoop 目录整体做差异对比。
最后是一键校验环境。我习惯把下面这条循环存成一个脚本，每次启动集群前跑一遍：
for node in node-0001 node-0002 node-0003; do echo "==== $node ====" ssh $node 'echo JAVA_HOME=$JAVA_HOME; ls -d $JAVA_HOME; $JAVA_HOME/bin/java -version 2>&1 | head -1' done如果三台输出的 JAVA_HOME 路径完全一致，java -version 都能打印版本，就可以放心初始化或启动服务。输出不一致的节点，直接对照第 3 章的处理流程单独修。
从那次连续翻车之后，我每搭一套集群都会强制走一遍“同 profile、同配置目录、同架构”的预检流程，再没有任何一个晚上耗在环境变量上。希望这次复盘能帮你把同样的坑一次填平，希望帮到你。
本文还有配套的精品资源，点击获取
