简介：这份《鲲鹏云大数据实验docx》是一份面向云计算与大数据初学者的实操型实验报告，完整记录了在华为云鲲鹏环境中搭建Hadoop集群的全过程。文档从购买弹性云服务器ECS、创建OBS并行文件系统并获取AK/SK开始，逐步展开Node0001、Node0002、Node0003三个节点的配置，涵盖/etc/hosts节点互信、SSH免密登录、目录结构创建、core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml及slaves文件编写，并针对Java_home配置错误导致的启动失败给出了重新分发、修正环境变量、初始化NameNode和启动HDFS的完整排错过程。资源为单份docx文档，压缩包大小约2.52MB，步骤与命令记录具体，便于按序复现；关键操作均标明节点与执行位置，适合边读边对照。目前已有892人学习下载。读者可从中获得一套可借鉴的云上大数据集群部署思路，也能避开环境配置中的典型坑点，对掌握华为云OBS与Hadoop的集成尤为实用。

1. 鲲鹏云大数据实验：从买ECS到启动HDFS的完整链路

《鲲鹏云大数据实验docx》这份实验文档，记录的不是什么高深算法，而是把一套三节点Hadoop集群从零跑起来的全过程：购买华为云ECS、创建OBS并行文件系统、获取AK/SK、配置节点互信、改五个XML配置文件、初始化NameNode、启动HDFS。最值钱的部分藏在文档里反复出现的“javahome错误”里——我第一次照着复现时，光是这个变量就折腾了一个下午，最后发现ARM架构的JDK路径和x86完全不是一个套路。这份文档适合正要做鲲鹏云大数据实验的学生，也适合要在国产化ARM环境里部署Hadoop的从业者，照着跑一遍，能省掉大量试错成本。

2. 准备华为云环境：ECS规格与OBS并行文件系统的选择

2.1 为什么实验要先买ECS和OBS

实验文档的完整链路是“云资源准备 → 集群搭建 → 配置 → 启动”，第一步就是准备华为云环境。三节点Hadoop集群需要三台ECS，分别承担不同角色：node-0001作为主节点跑NameNode和ResourceManager，node-0002和node-0003作为从节点跑DataNode和NodeManager。这里有个容易被忽略的点：Hadoop集群节点之间要互相通信，如果三台ECS不在同一个VPC内网里，后面配置/etc/hosts时填公网IP会非常别扭。我一般会在购买时就选同一个区域、同一个VPC，让三台机器有内网互通能力。

OBS在实验中的作用不是“备份数据”，而是作为Hadoop的底层存储对接目标。通过core-site.xml里配置的AK/SK和endpoint，HDFS可以把数据直接写到OBS并行文件系统上，相当于用云对象存储替代了本地三副本数据盘。实验文档里特意选了“并行文件系统”而不是普通对象桶，是因为并行文件系统对Hadoop这种需要随机读写的场景支持更好，Hadoop的OBS插件对接并行文件系统时稳定性也更高。

2.2 购买ECS与镜像选型

实验文档里三个节点的IP都在华为云上，操作系统环境从后续JDK包名里的“oe1”后缀可以判断大概率是openEuler系镜像。鲲鹏CPU是ARM架构，所以镜像一定要选带arm64标识的，JDK也必须用aarch64版本，这一点在实验文档的javahome错误里反复出现，后面我会专门展开。

购买ECS时我的建议是三台相同规格，2核4GB起步，系统盘40GB够用。实验场景选按需计费就行，做完实验及时释放，避免持续扣费。安全组至少要放通22端口（SSH）、8020端口（NameNode RPC）、50070端口（NameNode Web UI）、8088端口（YARN Web UI），不放通的话后面浏览器访问管理界面会直接超时。材料里记录的124.70.110.126这类地址是弹性公网IP，实际配置时我建议把三个节点的内网IP先记下来，后面/etc/hosts里用的是内网通信地址。

2.3 创建OBS并行文件系统与获取AK/SK

进入华为云控制台，搜索OBS服务，创建并行文件系统。区域要和后续ECS保持一致，实验文档用的是华北-北京四（cn-north-4），这个区域代码后面配置endpoint时直接用到。创建完成后进入桶，能看到OBS提供的访问地址，实验文档里记了两个：

两者的区别在于双栈地址额外支持IPv6协议栈，实验环境用第一条就够了。接着在控制台的“我的凭证”里下载credentials.csv，打开后是三列：User Name、Access Key Id、Secret Access Key。这个Access Key Id和Secret Access Key就是后面core-site.xml里要填的AK/SK，属于最高级别的敏感凭据，千万不要复制实验文档里贴出来的示例值直接用，必须用自己的。

3. 三节点互信与JDK环境：集群通信的底层基础

3.1 /etc/hosts：让三个节点互相叫得上名字

Hadoop集群启动时，主节点要通过主机名去找从节点，所以/etc/hosts是第一步。三个节点上都要执行vim /etc/hosts，把三台机器的内网IP和主机名写进去，格式如下：

# /etc/hosts 追加内容 10.0.0.11 node-0001 10.0.0.12 node-0002 10.0.0.13 node-0003

这里有个经验：hosts里一定要用内网IP，不要用公网IP。材料里记录的124.70.110.126等地址是绑定的弹性公网IP，如果写进hosts，节点之间通信会绕公网，不但慢，而且安全组策略稍微严一点就直接不通。主机名node-0001、node-0002、node-0003要和后面slaves文件里的名字完全一致，大小写都不能差，否则HDFS启动时会报“无法解析主机名”。

3.2 SSH免密登录：三步打通节点互信

集群里NameNode要远程启动DataNode进程，所以主节点到所有从节点必须免密登录。实验文档里的做法是“生成密钥 → 分发公钥 → 首次连接选yes”，对应到命令就是：

# 在 node-0001 上生成 RSA 密钥对 ssh-keygen -t rsa -P "" # 查看公钥内容并复制 cat /root/.ssh/id_rsa.pub # 在 node-0002、node-0003 上执行，追加到 authorized_keys echo "ssh-rsa 公钥内容 root@node-0001" >> ~/.ssh/authorized_keys # 回 node-0001 验证免密 ssh node-0002 date ssh node-0003 date

生成密钥时加-P ""参数是为了不设置口令，这样SSH登录时不需要额外输入密码；公钥追加到authorized_keys之后，SSH服务端会比对客户端私钥签名，匹配就放行。最后一步验证能看到日期输出就说明免密通了。实验文档里那句“执行后选yes”指的是首次SSH连接时确认目标主机指纹，在自动化脚本场景下可以用-o StrictHostKeyChecking=no跳过，但手工操作时选yes确认一次更稳妥。

3.3 OpenJDK安装与JAVA_HOME完整路径

实验材料里出现的JDK路径是java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64，注意结尾的aarch64——这就是ARM架构的标志。x86服务器上常见的路径是java-1.8.0-openjdk-1.8.0.xxx.x86_64，到鲲鹏上就变成aarch64版本。安装完成后，Java的安装目录在/usr/lib/jvm下，但具体子目录名会因为发行版不同有差异，所以必须先ls看一下实际目录名。

JAVA_HOME的正确配置方式是写全路径而不是软链路径，示例代码如下：

# 在每个节点上确认实际 JDK 目录名 ls /usr/lib/jvm/ # 编辑 /etc/profile 追加以下内容 export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64 export PATH=$JAVA_HOME/bin:$PATH # 立即生效并验证 source /etc/profile java -version

不要写成export JAVA_HOME=/usr/lib/jvm/java-1.8.0这种软链路径，因为不同发行版里软链的解析行为不统一，Hadoop的启动脚本在部分系统上会解析成无效目录。实验文档里反复出现的javahome错误，根源就是把路径写成了通用目录。改完/etc/profile后每个节点都必须执行source，这个问题后面第5章还会重点展开。

4. Hadoop配置与OBS对接：五个配置文件的关键参数

4.1 安装目录与数据目录规划

Hadoop安装包在实验文档里是hadoop-2.8.3.tar.gz，解压到/home/modules下。在解压之前，先创建两个关键目录：

mkdir -p /home/modules/data/buf mkdir -p /home/nm/localdir cd /home/modules tar -zxvf hadoop-2.8.3.tar.gz

这两个目录不是随便建的。/home/modules/data/buf是NameNode的元数据目录，后面hdfs-site.xml里的dfs.namenode.name.dir会引用它；/home/nm/localdir是NodeManager处理MapReduce中间结果的本地目录，yarn-site.xml里的yarn.nodemanager.local-dirs会引用它。先把目录建好，再改配置，逻辑上顺一些。注意三台节点都要建这两个目录，不能只建在主节点，否则从节点NodeManager启动时会因为本地目录不存在而报错。

4.2 core-site.xml：AK、SK、Endpoint一个都不能错

core-site.xml的配置核心是把Hadoop的默认文件系统指向HDFS，同时把OBS的认证信息和endpoint写进去。实验文档里明确提到“将ak，sk，endpoint更改”，代码示例如下：

<configuration> <!-- 默认文件系统指向 HDFS，8020 是 NameNode RPC 端口 --> <property> <name>fs.defaultFS</name> <value>hdfs://node-0001:8020</value> </property> <!-- OBS 访问密钥，替换为 credentials.csv 里的真实内容 --> <property> <name>fs.obs.access.key</name> <value>你的AccessKeyId</value> </property> <property> <name>fs.obs.secret.key</name> <value>你的SecretAccessKey</value> </property> <!-- OBS endpoint，区域必须和创建桶时一致 --> <property> <name>fs.obs.endpoint</name> <value>obs.cn-north-4.myhuaweicloud.com</value> </property> </configuration>

三个参数里最容易错的是endpoint。很多人在创建OBS桶时选了别的区域，配置里却填了cn-north-4，结果就是HDFS启动后访问OBS一直报连接失败。endpoint的区域代码要和OBS桶所在区域完全一致，不存在“多填几个地址试试”的说法。AK/SK粘贴时要注意别带首尾空格，从credentials.csv直接复制出来的人最容易踩这个坑。

4.3 hdfs-site.xml、yarn-site.xml、mapred-site.xml与slaves

剩下的三个配置文件作用不同，但改法一致，都在$HADOOP_HOME/etc/hadoop/目录下。先看整体文件清单：

hdfs-site.xml里，dfs.namenode.name.dir指向/home/modules/data/buf，dfs.datanode.data.dir指向/home/modules/data/dn（需要先mkdir），副本数dfs.replication在实验环境设为2就够，三节点里挂掉一台数据还在。yarn-site.xml的yarn.resourcemanager.hostname必须是主节点node-0001，yarn.nodemanager.local-dirs指向/home/nm/localdir。mapred-site.xml在Hadoop 2.x里必须设置mapreduce.framework.name为yarn，否则默认走local模式，作业逻辑全跑在单机上。slaves文件每行一个主机名，写入node-0001、node-0002、node-0003，注意这个文件决定的是DataNode和NodeManager进程的启动范围，主节点也可以作为DataNode参与存储。

4.4 环境变量与三节点分发

所有配置文件改完后，还要配置HADOOP_HOME环境变量，同样写在/etc/profile里：

export HADOOP_HOME=/home/modules/hadoop-2.8.3 export PATH=$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$PATH source /etc/profile hadoop version

这里有个特别重要的经验：配置文件不是只改主节点，而是要分发到所有节点。实验文档里因为javahome错误重新分发了两轮，这个流程对应到操作就是：

# 在 node-0001 上执行，分发 hadoop 目录到两个从节点 scp -r /home/modules/hadoop-2.8.3 node-0002:/home/modules/ scp -r /home/modules/hadoop-2.8.3 node-0003:/home/modules/ # 分发 /etc/profile scp /etc/profile node-0002:/etc/profile scp /etc/profile node-0003:/etc/profile # 在每个从节点上执行 source /etc/profile

为什么必须重新分发？因为Hadoop启动脚本在每台机器上是独立执行hadoop-env.sh的，主节点的JAVA_HOME改对了，从节点没同步，start-dfs.sh在SSH到从节点后还是会用错误的JAVA_HOME起进程，表现就是主节点进程全起来了，从节点一个都没有。实验文档里把这个问题完整暴露了出来，这是它比其他精简教程值钱的地方。

提示：core-site.xml里AK/SK不要使用任何现成文档里的示例值，credentials.csv下载后自己保管好，配置完可以顺手把文件移到安全位置。

5. 避坑排查：五个让集群反复重建的错误

5.1 JAVA_HOME路径检测失败：环境变量改了却还在报错

现象：java -version能正常输出版本，但执行hadoop version或者hdfs namenode -format时报错“找不到JAVA_HOME”或“JAVA_HOME is not set correctly”。

原因：这类报错绝大多数是/etc/profile改了但没有source，或者只source了主节点，从节点没执行。我在复现时就是改完主节点直接格式化，结果从节点环境变量全是旧值。另外有些人的JAVA_HOME写的是软链路径，启动脚本解析到空目录，现象和没设置完全一样。

解决：三个节点都执行source /etc/profile，然后逐个执行echo $JAVA_HOME确认有输出。最稳妥的做法是把JAVA_HOME写死成完整路径，并且在hadoop-env.sh里也显式加上一行export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64，这样即使有人改了系统profile，Hadoop也能找到JDK。

5.2 NameNode初始化反复失败：格式化之前先自查JDK

现象：执行hdfs namenode -format走到一半失败，或者格式化显示成功但紧接着启动HDFS时NameNode进程立刻退出。

原因：实验文档里“因为javahome的错误导致这里出错了”就是指这一环。格式化操作本身依赖JAVA_HOME去加载NameNode类，路径错误时格式化产物不完全，后续启动自然起不来。还有一种情况是第一次格式化用的是错误JDK，改完后又直接重新格式化，残留目录里的旧元数据和新配置冲突。

解决：改完JAVA_HOME后，先删除NameNode数据目录再重新创建：rm -rf /home/modules/data/buf && mkdir -p /home/modules/data/buf，然后重新执行格式化。格式化只做一次，重复格式化会清掉元数据，导致之前的HDFS目录结构全部丢失。

5.3 SSH免密配置好了仍要密码

现象：在node-0001上执行ssh node-0002后仍然提示输入root密码，SSH互信完全没生效。

原因：最常见的是.ssh目录权限不对。SSH对密钥文件权限非常敏感，.ssh目录如果被其他用户可写，sshd会直接拒绝用公钥认证；另一个常见原因是公钥没追加进authorized_keys，或者authorized_keys的属主不是当前用户。

解决：在node-0002和node-0003上执行chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys，确认authorized_keys的所有者是root。还可以用ssh -v node-0002看调试输出，里面会明确提示是permission问题还是key不匹配。

5.4 OBS访问失败：endpoint区域和桶不一致

现象：HDFS启动成功，但执行hdfs dfs命令访问OBS路径时报连接超时或不可达错误。

原因：core-site.xml里fs.obs.endpoint配的区域和OBS桶实际所在区域不一致。比如桶创建在华东，endpoint却写了cn-north-4，OBS服务端会直接拒绝连接。

解决：登录OBS控制台进入对应桶，在“概览”页面能看到桶的区域信息，把fs.obs.endpoint改成实际区域代码。同时检查AK/SK粘贴时有没有带上多余空格，从CSV直接复制到XML时最常见的问题就是换行符和空格混进去，导致认证失败。

5.5 改完配置后集群节点不齐

现象：执行start-dfs.sh后，jps看到主节点进程齐全，但从节点空荡荡，或者启动一段时间后从节点进程自动退出。

原因：只改了主节点的配置并重启服务，从节点的hadoop包和hosts文件还是旧版本。实验文档里明确记录了“由于javahome错误重新分发”——分发的不只是hadoop包，还有/etc/profile和/etc/hosts。

解决：把核心配置打包统一分发：scp /etc/hosts、scp /etc/profile、scp -r hadoop目录全部覆盖到从节点，然后每个节点重新source。分发完再检查一遍hosts里有没有残留的旧公网IP，如果有，改成内网IP后重启网络服务或重启ECS，否则节点间通信还是走的错误地址。

6. 启动HDFS并验证：把实验文档变成自己的部署清单

所有配置分发完毕，终于到了验证环节。启动顺序有讲究，先格式化NameNode，再启动HDFS，最后启动YARN：

# 第一次部署才需要格式化，之后再启动不要执行 hdfs namenode -format # 启动 HDFS 和 YARN start-dfs.sh start-yarn.sh # 验证进程 jps # node-0001 应看到 NameNode、ResourceManager、DataNode # node-0002/node-0003 应看到 DataNode、NodeManager # 验证数据节点在线状态 hdfs dfsadmin -report # 验证 OBS 对接 hdfs dfs -ls obs://你的桶名/

jps是所有验证里最直观的，主节点少了NameNode看日志，从节点少了DataNode大概率是配置文件没分发到位。hdfs dfsadmin -report能显示每个DataNode的容量和状态。最后一条命令直接验证OBS对接是否成功——能列出桶里的目录，说明AK/SK和endpoint都对了。

我自己的习惯是把实验文档整理成一个核验清单，每次装集群前强制走一遍：首先在三个节点上都执行echo $JAVA_HOME确认有值，然后grep "fs.obs.endpoint" core-site.xml确认区域正确，接着for node in node-0001 node-0002 node-0003; do ssh $node hostname; done验证免密链路。这套动作看起来笨，但能挡掉九成以上的启动失败。另外，实验文档里的公网IP一定要全部替换成自己实验环境的VPC内网IP，我第一次偷懒没全换，结果hosts里残留一个旧地址，集群里一台节点怎么都连不上，折腾了半天才发现是IP没替换干净。从那以后我每次装集群都强制走一遍配置核验，再也没翻过车。这份实验文档把完整过程记录下来，对照学习能省不少时间，希望帮到你。

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