简介：实验报告以华为云鲲鹏云环境为依托，完整记录在ECS与OBS上搭建Hadoop集群的全过程，面向高校大数据课程、云计算实训及刚接触分布式平台的初学者。内容从购买弹性云服务器和对象存储服务入手，详细说明AK/SK认证密钥获取、多节点互信配置、Hadoop与OpenJDK安装、目录结构创建，以及core-site、hdfs-site、yarn-site、mapred-site和slaves等核心文件的参数设置；同时记录了Java环境修正、NameNode初始化、HDFS启动等关键操作，并附有分步执行命令与排错记录。资源为单个docx文档，大小约2.52MB，图文步骤清晰，既可作为实验报告模板，也能直接用于集群部署时对照参考。已有892人学习浏览，适合需要在大数据实验或鲲鹏云环境中快速复现Hadoop集群搭建流程的读者。
1. 先认清这实验的难点不在 Hadoop，而在 ARM 和 OBS
翻车率最高的地方，几乎都集中在「架构」和「存储」这两件事上。这份实验文档记录的是在华为云鲲鹏 ECS 上搭建三节点 Hadoop 集群，并把 OBS 接进来当存储后端的全过程。你要是拿 x86 的服务器照着做，很多步骤根本走不通——JDK 得换 aarch64 版本，Hadoop 的 native 库对不上，连 OBS 还得额外挂适配 jar 包。所以这篇笔记我把整条链路拆开：环境怎么买、三台机器怎么配互信、五个配置文件每个字段干什么，以及我在复现时反复踩的 JAVA_HOME 和 Endpoint 的坑。适合正在做云上大数据实验、或者想在鲲鹏环境里从零起一套可用集群的人照着抄。
2. 华为云环境准备：ECS、OBS 与 AK/SK 的安全落地
2.1 ECS 购买：规格、镜像和端口这块别图省事
实验里需要三台机器。第一台叫 node-0001，是主节点，负责 NameNode 和 ResourceManager；另外两台做 DataNode。我复现时用的规格是 4 核 8G，系统盘 40G，数据盘另挂一块 50G 给 Hadoop 用。你要是预算紧张，三台都买 2 核 4G 也能把这套流程跑完，但之后跑 wordcount 会很慢，DataNode 的内存也容易告急，容器会被 YARN 直接杀掉。
镜像这里要重点说：鲲鹏是 ARM 架构，镜像市场里能选 CentOS 7 的 aarch64 版和 openEuler。实验用的镜像名我没细究，但有一个硬性要求——系统里的 OpenJDK 必须是 aarch64 版本。这一点直接决定了你后面会不会在java -version上卡住一下午。很多教程写着「装 JDK 就行」，但 x86 的 JDK 在鲲鹏上装完，Hadoop 启动脚本根本认不出发到哪个目录去，这是 ARM 环境和 x86 最大的分水岭。
端口方面，安全组除了默认的 22，还要放通下面几个：
| 端口 | 用途 | 建议来源 |
|---|---|---|
| 9000 | HDFS NameNode RPC | 集群内网 |
| 50070 | HDFS Web UI | 你的办公网 IP |
| 8088 | YARN ResourceManager Web UI | 你的办公网 IP |
| 50010 | DataNode 数据传输端口 | 集群内网 |
集群内网互通是重点。三台 ECS 最好位于同一个 VPC、同一安全组，私网 IP 能互相 ping 通。不要拿公网 IP 去填hdfs-site.xml，内网速度不是一个量级，而且公网 IP 一旦变更，整个集群会直接找不到节点，只能重新分发配置。
2.2 OBS 并行文件系统：别买成普通桶
OBS 在控制台里其实有两种形态，一种是普通对象存储桶，一种是并行文件系统。实验里用的是「并行文件系统」，不是普通的 OBS 桶。创建入口在「对象存储服务 OBS」页面里，选择创建并行文件系统，填好桶名就行。如果你在实验中发现hadoop fs -ls obs://桶名一直报错，先回头看一眼是不是买错了类型。
创建完成后会得到一个桶名，也就是后面路径里obs://那一段。访问地址要看 ECS 的网络栈：只有 IPv4 就用 IPv4 地址，ECS 开了 IPv6 就要用 dualstack 双栈地址。我自己的环境是纯 IPv4，所以 Endpoint 只填了 IPv4 那个。这里有个容易忽略的细节：如果 ECS 开了 IPv6 但你没配双栈地址，Hadoop 客户端解析 Endpoint 时拿到的是 IPv6 地址，而集群网络里 IPv6 路由没通，请求就会卡在连接超时上。
credentials.csv是创建完 AK/SK 后自动下载的一个文件，里面有两行关键内容：
| 字段 | 含义 |
|---|---|
| User Name | IAM 用户名 |
| Access Key Id | AK，用来标识身份 |
| Secret Access Key | SK，等同于密码 |
提示：
credentials.csv只会在创建 AK/SK 时下载一次，之后控制台不再提供。第一时间备份到安全目录，再做其他操作。
这个文件经常被忽略的一点是：它只在创建时下载一次，点掉之后再也拿不到，必须立刻把它放到安全的地方。我一般会放到一个只读权限的目录，后续配置core-site.xml时手动填进去，而不是把文件留在系统下载目录里，避免被其他登录会话看到。
2.3 AK/SK 落地：直接写配置文件是我最推荐的方式
拿到 AK/SK 之后有两种用法。一种是写进core-site.xml的fs.obs.access.key和fs.obs.secret.key；另一种是通过 OBS 提供的凭据文件，在配置文件里指定读取路径。我的习惯是直接写 XML，原因是三四台节点的集群，环境变量方式很容易出现某台机器漏配的情况，排查起来特别痛苦。直接写进配置，分发一次就全齐了。
不过要提醒：如果你做的是生产集群，AK/SK 明文写在 XML 里不是好主意，应该用华为云的元数据服务或者专门的密钥管理方案。实验环境里明文写问题不大，但core-site.xml的权限必须改成 600：
chmod 600 /home/modules/hadoop-2.8.3/etc/hadoop/core-site.xml这里给出第 3 章会用到的最小 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.myhuaweicloud.com</value> </property>AK 和 SK 对外等价于账号密码，一次泄露就可能导致 OBS 里的数据被读走。把它写进配置文件后立刻 chmod 600，这是我在一次实验里得到血泪教训后才养成的习惯。还有一点：为什么fs.defaultFS不直接设成obs://你的桶？因为 NameNode 格式化时会尝试访问默认文件系统，而格式化阶段 OBS 客户端的依赖 jar 可能还没完全就绪，很容易出现「初始化失败」的假象。先用 HDFS 做默认文件系统，把 OBS 当成扩展存储，等集群起来再用hadoop fs -ls obs://验证访问，这个顺序更稳。
3. 三节点 Hadoop 部署：从 hosts 到五个配置文件的完整拆解
3.1 节点规划与 /etc/hosts
三台节点的主机名分别是 node-0001、node-0002、node-0003，其中 node-0001 是主节点。按常见部署策略，NameNode 和 ResourceManager 只装在 node-0001 上，DataNode 和 NodeManager 装在所有节点上。这个角色分配决定了后面启动脚本的行为——主节点负责调度，从节点负责干活。
规划好后，第一件事是在每台机器上确认主机名：
hostnamectl set-hostname node-0001改完主机名只是第一步。第二步是让三台机器通过主机名互相解析，这一步必须在三台机器上都执行，不要在主机上改完就以为万事大吉：
cat >> /etc/hosts <<'EOF' 192.168.0.101 node-0001 192.168.0.102 node-0002 192.168.0.103 node-0003 EOF上面的 192.168.x.x 要替换成你自己的 ECS 私网 IP，千万别照抄。判断是否生效，可以在任意节点执行ping node-0002，能通说明 hosts 没问题。我见过有人在配置阶段直接填公网 IP 写 hosts，结果集群起来后节点间通信全走外网，不但慢，而且公网 IP 一旦发生迁移，整个集群都要重新改。域名解析尽量用内网 IP，私网通信是集群存活的基础。
3.2 SSH 免密：先想清楚谁要登录谁
Hadoop 的启动脚本是主节点通过 SSH 到各个节点拉起守护进程的，所以免密的方向是 node-0001 能免密登录 node-0002 和 node-0003。实验文档里的做法更彻底——三台节点都生成密钥并相互交换，做成完全互信。这样做的优点是以后从任意节点都能拉起服务，代价是多执行几行命令。我复现时只做了单向，够用就行。
第一步，在所有节点上生成密钥：
ssh-keygen -t rsa -P '' -f /root/.ssh/id_rsa-P ''表示生成的密钥没有 passphrase，这样集群启动脚本才能无人工干预地连续跑完。生产环境这么干当然不推荐，但实验集群图的就是省事。
第二步，把公钥内容追加到目标机器的authorized_keys里：
ssh root@node-0002 "mkdir -p /root/.ssh && chmod 700 /root/.ssh" cat /root/.ssh/id_rsa.pub | ssh root@node-0002 "cat >> /root/.ssh/authorized_keys"第三步，验证免密是否生效：
ssh node-0002 hostname如果输出的主机名是 node-0002，说明免密已经通了。这里有个小坑值得提：首次执行 ssh 登录时，系统会要求确认 host key，要手动输 yes。Hadoop 启动脚本不会帮你输 yes，所以我总会先手动ssh node-0002一次，把 yes 按掉，后面启动集群时才不会被卡住。
3.3 目录结构：先建对目录，再谈配置
实验里创建了两个目录：/home/modules/data/buf和/home/nm/localdir。前者是 HDFS 数据块的缓冲目录，后者是 YARN 的本地工作目录。这两个目录在每台节点上都要建，不能只在主节点建完就算数，因为 Hadoop 集群会把配置和目录路径广播到所有节点，某台机器缺目录，对应的 DataNode 或 NodeManager 启动时会直接报错。
mkdir -p /home/modules/data/buf mkdir -p /home/nm/localdir我习惯把这两条命令和 JDK 安装写成一个provision.sh脚本，一次性在所有节点跑完，避免漏节点。JDK 安装这里要特别标注：鲲鹏节点上必须安装 aarch64 的 OpenJDK。实验里对应的是java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64。检查是否正确：
java -version输出里出现 aarch64，说明架构对上了。此时JAVA_HOME应该指向/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64，这个路径在配置/etc/profile时是关键。
3.4 五个配置文件逐个拆
Hadoop 解压位置是/home/modules/，解压后目录是/home/modules/hadoop-2.8.3：
cd /root cp hadoop-2.8.3.tar.gz /home/modules/ cd /home/modules tar -zxvf hadoop-2.8.3.tar.gz解压完成后，把 OBS 的适配 jar 包和它的依赖（hadoop-huaweicloud、okhttp、okio 等）放到$HADOOP_HOME/share/hadoop/common/lib/下。这一步要在启动之前完成，放错位置最常见的报错是ClassNotFoundException: com.huaweicloud.fs.obs.OBSFileSystem。
接下来改动集中在etc/hadoop/目录下。第一个是core-site.xml，它定义了集群的默认文件系统和 OBS 的认证信息：
<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://node-0001:9000</value> </property> <property> <name>fs.obs.impl</name> <value>com.huaweicloud.fs.obs.OBSFileSystem</value> </property> <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.myhuaweicloud.com</value> </property> </configuration>这里要解释参数之间的依赖：fs.defaultFS决定了hdfs dfs -ls /看到的根目录，我把它指到 node-0001 的 9000 端口，意味着集群的核心存储还是 HDFS；fs.obs.impl指定 OBS 实现类，依赖前面放的 jar 包；fs.obs.endpoint必须和你购买 OBS 的 region 一致，华北四是cn-north-4，你在其他 region 就得换。很多人卡在这个坑上，第 4 章会展开说。
第二个是hdfs-site.xml，配置 HDFS 的副本数和元数据目录：
<configuration> <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/home/modules/data/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/home/modules/data/buf</value> </property> </configuration>dfs.replication是三节点集群的副本数，设成 2 既容错又不会拖慢写入。dfs.namenode.name.dir是元数据存储目录，要在 node-0001 上先建好；dfs.datanode.data.dir对应前面建好的/home/modules/data/buf。节点上数据目录不一致，DataNode 会拒绝启动，这也是为什么目录必须统一预建。
第三个是yarn-site.xml，配置资源调度框架：
<configuration> <property> <name>yarn.resourcemanager.hostname</name> <value>node-0001</value> </property> <property> <name>yarn.nodemanager.local-dirs</name> <value>/home/nm/localdir</value> </property> </configuration>yarn.resourcemanager.hostname告诉 NodeManager 去哪里找 ResourceManager，这里必须是主机名而不是 IP，依赖/etc/hosts的解析。yarn.nodemanager.local-dirs是本地工作目录，指向 3.3 建的目录。本地目录空间不足时，任务会以诡异的「container exit」形式失败，所以生产环境建议给这个目录挂独立数据盘。
第四个是mapred-site.xml，默认文件不存在，需要改模板名：
cp /home/modules/hadoop-2.8.3/etc/hadoop/mapred-site.xml.template \ /home/modules/hadoop-2.8.3/etc/hadoop/mapred-site.xml内容只有一个关键配置：
<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> </configuration>第五个是slaves文件，定义哪些节点是 DataNode 和 NodeManager：
node-0001 node-0002 node-0003要不要把 node-0001 也写进 slaves，取决于你的资源规划。三节点小集群写进去可以充分利用资源；如果你希望主节点专职管理，只写后两个节点就够了。这是个取舍问题，没有标准答案。
3.5 环境变量与分发：改完配置必须三台机器一起动
配置只写在一台机器上没有意义。Hadoop 集群要求所有节点配置一致，所以这些配置文件和 JDK 环境变量必须分发到每一台机器。环境变量的写法，我推荐在/etc/profile末尾追加三行：
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64 export HADOOP_HOME=/home/modules/hadoop-2.8.3 export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbinJAVA_HOME的路径必须严格对应系统里实际安装的 aarch64 JDK 版本。实验里第一次配置指错了，后续命令全部失败，只能重新修改再分发，这正好是第 4 章要展开的坑。
分发用 scp 就够。我的习惯是把整个/home/modules目录打包后分发，保证两边内容完全一致：
cd /home tar -czf hadoop_env.tar.gz modules scp hadoop_env.tar.gz node-0002:/home/ scp hadoop_env.tar.gz node-0003:/home/每台节点上解压并刷新环境变量：
cd /home tar -xzf hadoop_env.tar.gz source /etc/profilesource /etc/profile这一步不能省。很多人在分发后直接敲 hadoop 命令，报「command not found」，其实不是分发失败，而是环境变量没刷新。在每台节点执行which hadoop，能输出路径就说明环境变量已生效。
4. 避坑：JAVA_HOME、分发遗漏与 Endpoint 不对齐的四个翻车现场
这份实验文档里最有价值的，不是那些顺利的步骤，而是作者在 JAVA_HOME 上反复翻车的痕迹。原文里多次出现「执行失败，更改 javahome 的目录」，几乎每走几步就要回头改一次。我自己复现时也踩了一样的坑，整理成四条，每一条都能直接对着改。
4.1 现象：namenode 初始化和启动反复失败
具体表现是：在主节点执行hdfs namenode -format或start-dfs.sh时，报Error: JAVA_HOME is not set and could not be found，或者 Java 版本不匹配的提示。
原因：系统里往往装了不止一个 JDK。默认的java -version可能指向了一个 x86 或旧版本的 JDK，而 Hadoop 启动脚本先从JAVA_HOME找 Java，找到错误路径就启动失败。鲲鹏环境需要java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64，但系统默认路径可能指向一个通用 JDK，版本对不上。
解决：先看清系统里装了哪些 JDK：
update-alternatives --list java然后在/etc/profile里写死JAVA_HOME，不依赖系统的默认路径。顺便检查$HADOOP_HOME/etc/hadoop/hadoop-env.sh里有没有写死 JAVA_HOME，有些版本会覆盖/etc/profile的配置。我的经验是：两处都写成同一个绝对路径，然后验证java -version输出里出现 aarch64，再继续往下走。
4.2 现象：只有主节点能执行命令，子节点全报 command not found
分发之后，在 node-0002 上敲hadoop，提示命令找不到。
原因：/home/modules目录虽然分发过去了，但/etc/profile里的环境变量没有在子节点生效。scp 分发的是文件和目录，不是 shell 的运行时状态。
解决：在每个节点单独执行：
source /etc/profile java -version which hadoop每次 SSH 登录都会读取/etc/profile，理论上 source 一次就够了，但我建议每台节点都执行一遍确认。如果 source 之后还是找不到，检查/etc/profile里的HADOOP_HOME是否和实际解压位置一致。
4.3 现象：AK/SK 正确但hadoop fs -ls obs://一直连接超时
core-site.xml里 AK/SK 填得没错，命令却报连接超时或 503。
原因：fs.obs.endpoint和 OBS 桶实际所在的 region 不一致。桶在华东，配置里写华北四，请求自然到不了正确的数据中心。
解决：登录 OBS 控制台，在桶的基本信息里确认所在区域，只改fs.obs.endpoint一个值。判断标准是：桶列表页显示的「所属区域」和 Endpoint 前缀的 region 代号必须一致，比如华北-北京四对应cn-north-4。如果 ECS 开了 IPv6，还要确认用的是 dualstack 双栈地址，否则 IPv6 环境下请求会异常。
4.4 现象：改完配置重新分发后，旧进程还在用老配置
第一次配置出错后，改了配置文件再重启，发现集群行为还是老样子，像配置没生效。
原因：之前启动过的 NameNode 和 DataNode 进程没被完整杀掉，新配置只对下次拉起的进程生效。另外，NameNode 格式化过之后，不清理dfs.namenode.name.dir下的旧元数据，第二次格式化会提示目录已存在。
解决：每次修改核心配置后，做一次冷重启：
stop-dfs.sh stop-yarn.sh jps确认进程全部消失。如果 jps 里还有残留，用kill -9清理。格式化之前，再清掉旧数据目录：
rm -rf /home/modules/data/name/*然后才执行hdfs namenode -format。顺序很重要：先清旧数据、再格式化，否则会看到「已经格式化过」的警告，但进程起不来。
这四条几乎覆盖了实验文档里所有「执行失败，更改 javahome 的目录」背后的原因。遇到问题不要急着怀疑配置文件，按「JAVA_HOME → hosts → Endpoint → 进程残留」的顺序排查，往往几分钟内能找到根因。
5. 启动验证与 OBS 读写：把集群变成能跑任务的状态
5.1 初始化与启动的正确顺序
配置就绪后，启动顺序有讲究。第一步是初始化 NameNode，第二步才是启动 HDFS。初始化时有一个实用验证方法：执行hdfs namenode -format时，输出最后出现SHUTDOWN_MSG说明成功；如果出现 Exception，先别继续启动，按第 4 章的排查顺序走一遍。
hdfs namenode -format start-dfs.sh jps在 node-0001 上执行jps，看到NameNode、SecondaryNameNode、ResourceManager说明主节点正常。再到 node-0002 和 node-0003 上jps，看到DataNode和NodeManager就算通过。jps 的输出是最直接的进程级验证，比翻日志更高效。
HDFS 起来后，再用 Web 界面确认：访问http://127.0.0.1:50070看 HDFS 状态，访问http://127.0.0.1:8088看 YARN 集群。这两个界面能显示当前活跃节点数量，是判断集群是否真正健康的关键。
5.2 OBS 读写验证：跑通一个 wordcount 才叫完成
很多人在集群起来后就以为大功告成，但实验的目标是让 OBS 能正常当存储用。一条命令就能验证：
hadoop fs -ls obs://你的桶名/能列出桶里的对象文件，说明 OBS 对接成功。再往 OBS 传一个本地文件试试：
echo "hello hadoop on kunpeng" > /tmp/test.txt hadoop fs -put /tmp/test.txt obs://你的桶名/test.txt hadoop fs -cat obs://你的桶名/test.txt如果-cat能输出内容，说明数据已经正常写入 OBS。最后建议跑一次最经典的 wordcount，走完整个 MapReduce 流程，确认 YARN 也能正常分配任务。测试数据不需要额外准备，把上一步传好的test.txt当输入就行。
从这个流程往后，集群就是能正常跑任务的状态了。从那以后我每次搭这套环境，都强制走一遍「三查三验」：查 JAVA_HOME、查 Endpoint、查分发完整性；验 jps 进程、验 OBS 读写、验 wordcount。三查三验全部通过，我才会认为集群是真的起来了，而不是「暂时能跑」。这套习惯帮我省掉了无数小时的反复重启，希望也能帮到你。完整实验文档里有每一步操作对应的截图和配置文件模板，需要的话可以下载下来对照着改，比只看笔记更稳。
本文还有配套的精品资源，点击获取
