鲲鹏云ARM架构Hadoop集群部署实验全流程拆解

简介：《鲲鹏云大数据实验docx》是一份面向云计算与大数据初学者的实验报告，完整记录了在华为云鲲鹏环境下从零搭建Hadoop集群的全过程。报告从购买弹性云服务器与对象存储服务开始，介绍如何获取AK/SK认证密钥，并逐步完成OpenJDK安装、节点互信配置、无密码登录设置、Hadoop安装包解压及core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml等核心配置文件的修改，同时调整环境变量、初始化NameNode并启动HDFS服务。整个过程中涉及多个节点的协同操作，作者以Node0001、Node0002、Node0003为主线，逐一演示了主机解析、SSH公钥分发、Hadoop包同步与配置生效的步骤。资源为单个Word文档，体积2.52MB，系统呈现了完整的部署时序，特别记录了Java Home目录错误导致的初始化失败与重新分发配置的排错过程，有助于规避同类问题。已有891人学习，适合希望实践华为云大数据部署的开发者、运维人员及相关课程学生作为操作蓝本。

1. 翻遍“鲲鹏云 大数据 实验报告”之后，我决定把这份实验完整拆给你

做大数据实验最怕的不是 MapReduce 不会写，而是集群压根起不来。搜“鲲鹏云 大数据 实验报告”能搜到不少资源，但多数只给结论不给过程；这份实验报告不一样，它把三台 ARM 架构云主机从购买 ECS、创建 OBS 并行文件系统、配 AK/SK，到 Hadoop 2.8.3 集群部署、SSH 互信、环境变量修复、NameNode 初始化全流程都记录下来了，连 JAVA_HOME 配错之后怎么返工都写在里面。适合两类人：一是课程实验要交报告的学生，能照着步骤复现；二是想在 ARM 云环境里跑起 Hadoop 的开发者，这份文档能帮你少踩一半环境坑。

2. 先把实验台支起来：ECS、OBS 与 AK/SK 的完整获取链路

2.1 资源规划与购买口径

实验报告第一步就是准备云环境，但它没有解释为什么需要两台以上的机器。这里我先给出规划逻辑：Hadoop 分布式集群至少需要一个控制节点和一个计算节点，这份实验用的是三节点，node-0001 承担 NameNode 和 ResourceManager 的角色，node-0002、node-0003 作为 DataNode 和 NodeManager。三台都跑同一个 Linux 发行版镜像，架构必须选 ARM 生态对应的版本，后面装 OpenJDK 时才不会出现“找不到 aarch64 构建”的问题。

在控制台购买弹性云服务器（ECS）时，有几个参数是需要和实验报告对齐的：

购买时我的习惯是按需购买，实验做完就释放，避免包周期费用浪费。三台机器的购买顺序无所谓，但购买完成后一定要记下每台机器的内网 IP 和弹性公网 IP。原报告里 node-0001、node-0002、node-0003 都手工记了一串 IP，这批 IP 在后面配 hosts 时会使用。

2.2 创建并行文件系统与下载 credentials.csv

对象存储服务（OBS）在这个实验里扮演两个角色：一是存放实验数据和中间产物，二是配合 Hadoop 的 OBS 客户端做远端存储。报告里要求在 OBS 服务下创建并行文件系统，这个细节值得展开说。普通对象存储桶的语义是“对象”，并行文件系统的语义更接近“文件系统”，支持目录层级、随机写和并发读写，Hadoop 把它挂进来之后不需要引入额外的网关组件。

创建过程本身不复杂：在控制台找到对象存储服务入口，点“创建并行文件系统”，区域选择和 ECS 相同，桶名全局唯一，权限先选“私有”即可，后面需要通过 AK/SK 访问。创建完成后，在控制台的“访问密钥”管理里新建密钥，系统会下载一个 credentials.csv 文件，里面有一个用户名、Access Key Id 和 Secret Access Key 三列。AK/SK 就是后续访问 OBS 与 Hadoop 配置里的门户钥匙，它相当于一组长期有效的身份凭证。

这里有个很容易被忽略的安全习惯：这个 CSV 文件要直接放进实验目录，但绝不能跟着代码一起上传到公开仓库。我在做模拟项目X时见过有同学把 credentials.csv 直接提交到 GitLab 仓库，结果第二天就收到云厂商的密钥泄漏告警。AK/SK 一旦暴露，别人就能用你的密钥读写整个桶，轻则扣费，重则数据被删。正确做法是把这个文件加入 .gitignore，并只在实验机本地使用。

2.3 区域与 Endpoint 的一处隐藏前提

报告后面在 core-site.xml 配置里出现了一串 Endpoint 地址，形如 obs.region-code-1.myhuaweicloud-example.com 这类格式。很多照着做的人会直接复制这串地址，结果集群一直初始化失败，原因就是自己的 OBS 桶不在同一个区域。Endpoint 和 OBS 桶、ECS 必须全部同区域，否则内网访问走不通，公网访问虽然能通但速度慢很多，而且可能产生额外的流量费用。

我在复现这份实验时，把区域统一选成了同一个可用区，并在创建桶时核对了一遍“桶所在区域”与控制台上的区域标识一致。这一个动作节省了后面排查 Hadoop 连接 OBS 超时的两小时。如果你是第一次操作，建议在创建完桶后先在控制台上传一个小文件，再从 ECS 上用命令行工具访问一次，确认网络链路通了，再继续搭 Hadoop。

3. 节点通信：/etc/hosts、SSH 互信与 JDK 环境搭建的完整过程

3.1 主机名规划与 /etc/hosts 配置

Hadoop 集群里几乎所有的配置项都写节点主机名，而不是直接写 IP。原因在于集群内通信要频繁切换节点，写 IP 虽然也能跑，但后续扩展节点、替换机器时，每台机器的配置都要跟着改一遍，维护成本非常高。用主机名则只需要统一改一下所有节点的 hosts 文件，就能完成映射切换。

步骤上，每台节点都要编辑 /etc/hosts，加入三行映射。假设三台机器的内网 IP 分别是 10.0.1.11、10.0.1.12、10.0.1.13，配置内容如下：

# /etc/hosts 示例（三台节点内容一致） 10.0.1.11 node-0001 10.0.1.12 node-0002 10.0.1.13 node-0003

这段配置的作用是把主机名解析固定到内网 IP 上，避免依赖 DNS。注意每台机器都要写同样的三行，不要只写自己，也不要漏掉 localhost 那一行。配置完成后，在三台节点上分别执行ping node-0001、ping node-0002、ping node-0003，能通才继续下一步。

3.2 配置节点互信：两种方式都行，推荐你走 ssh-copy-id

节点互信的目的是让 node-0001 可以无密码跳转到另外两个节点，这样 Hadoop 在启动集群时才能通过 SSH 在各节点拉起守护进程。原实验报告用的是手工复制公钥的方式，也就是各节点生成密钥后，把/root/.ssh/id_rsa.pub的内容追加到目标节点的authorized_keys文件里。这个过程本身没有问题，但手工做容易出错，尤其是三台节点来回复制时，容易覆盖掉已有内容。

我这里给出一套更省事的做法，用ssh-copy-id一条命令完成公钥分发。先在 node-0001 上生成密钥：

# 在 node-0001 上生成 RSA 密钥对，一路回车即可 ssh-keygen -t rsa -b 4096

生成的公钥在/root/.ssh/id_rsa.pub，私钥在/root/.ssh/id_rsa。接下来把它分别复制到 node-0002 和 node-0003：

# 从 node-0001 把公钥安装到 node-0002，首次会提示输密码 ssh-copy-id root@node-0002 # 再安装到 node-0003 ssh-copy-id root@node-0003

ssh-copy-id做的事就是把公钥追加到对方机器的~/.ssh/authorized_keys，同时自动处理好目录权限。如果你的系统没有这个命令，也可以手工追加，等价操作是把本机公钥内容通过 SSH 管道写入对方文件：

# 等价的手工方式：将本地公钥追加到远端 authorized_keys cat /root/.ssh/id_rsa.pub | ssh root@node-0002 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

这里解释一下为什么 ansible 和目录权限这么重要：SSH 服务对 authorized_keys 的权限很敏感，如果该文件或父目录权限过宽，服务器会直接忽略这个密钥文件，表现就是互信配置了但依然要输密码。所以不管用哪种方式，配置完都要检查权限。互信完成后，在 node-0001 上执行ssh node-0002，能直接进入对方的 shell 就说明成功了。

3.3 JDK 安装与 JAVA_HOME 的真实目录

Hadoop 本身是用 Java 写的，所以每台节点都必须有 JDK。这份实验报告刻意选了 OpenJDK 1.8 的一个 ARM 构建版本，因为 Hadoop 2.8.3 官方对 JDK 8 的兼容性最好，而对 JDK 11 的支持还不成熟。下载时注意包名里的 aarch64 标识，这代表它是 ARM 64 位构建，x86_64 的包在这个环境里跑不起来。

拿到安装包后解压到统一目录，我按实验报告的路径习惯放在/home/modules下：

# 在每台节点上解压 JDK 到统一目录，注意版本串按实际下载为准 tar -zxvf openjdk-1.8.0.242-b08-1.5.ea9.aarch64.tar.gz -C /home/modules/ # 查看解压后的目录名 ls /home/modules/

解压后马上要做的一件事，是用readlink或ls确认 JDK 的真实目录名。这一步看似多余，实际上是原报告踩坑的根源：报告里写 JAVA_HOME 指向了错误的目录层级，导致 Hadoop 启动时找不到 java 可执行文件。

确认目录后，把环境变量写入/etc/profile。注意这里的路径要写到 JDK 的根目录，不要带/bin：

# 在 /etc/profile 末尾追加以下内容（每台节点都要做） export JAVA_HOME=/home/modules/jdk1.8.0_242 export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

追加之后执行source /etc/profile，再运行java -version验证。如果输出里出现OpenJDK 64-Bit Server VM和1.8.0_242字样，说明 JDK 装好了。这里容易出错的一点是只在一台节点上改了环境变量，其他节点没有同步，启动 HDFS 时就会看到某些节点报“找不到 JAVA_HOME”。这个问题后面第 4 章会专门展开排查。

创建 Hadoop 运行所需的目录结构也是这一阶段要做的事：

# 在 node-0001 上创建数据缓冲区和本地目录 mkdir -p /home/modules/data/buf mkdir -p /home/nm/localdir # 另外两个节点也要创建 mkdir -p /home/nm/localdir

data/buf用来存放临时数据和 OBS 缓冲文件，localdir是 nodemanager 的本地工作目录。YARN 的 NodeManager 会把容器中间结果写进这个目录，如果不存在，启动时会产生“目录无法创建”的报错。原报告能顺利启动 HDFS，和这一步的目录准备关系很大。

4. 从 core-site 到 NameNode 启动：Hadoop 配置要点与常见问题排查

4.1 六处核心配置：core-site.xml 与 OBS 参数

Hadoop 集群能不能起来，一半看环境，另一半看配置文件。原报告里涉及六个文件：core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml、slaves，以及/etc/profile环境变量。每个文件负责一个层次，先用表格理清职责，再逐个给关键参数。

core-site.xml 是这个实验里最特殊的配置文件，因为它不仅要写 HDFS 的默认文件系统地址，还要把 OBS 的 AK/SK 和 Endpoint 写进去，让 Hadoop 能通过 OBS 协议访问对象存储。我这里用占位符代替真实的 AK/SK，你配置时需要替换成自己的 credentials.csv 里的值：

<!-- core-site.xml 关键配置段 --> <configuration> <!-- 默认文件系统指向 HDFS 集群入口 --> <property> <name>fs.defaultFS</name> <value>hdfs://node-0001:8020</value> </property> <!-- 临时目录 --> <property> <name>hadoop.tmp.dir</name> <value>/home/modules/data/buf</value> </property> <!-- OBS 访问密钥，替换为 credentials.csv 中的值 --> <property> <name>fs.obs.access.key</name> <value>YOUR_ACCESS_KEY_ID</value> </property> <property> <name>fs.obs.secret.key</name> <value>YOUR_SECRET_ACCESS_KEY</value> </property> <!-- OBS Endpoint，区域必须与桶一致 --> <property> <name>fs.obs.endpoint</name> <value>obs.region-code-1.myhuaweicloud-example.com</value> </property> <!-- 缓冲区大小，默认 4MB，大文件可调大 --> <property> <name>io.file.buffer.size</name> <value>4096</value> </property> </configuration>

这段配置里前两个属性决定 Hadoop 的文件系统入口和临时目录位置。fs.defaultFS写的是hdfs://node-0001:8020，意味着默认的文件操作都会走 HDFS；hadoop.tmp.dir指向之前创建的数据缓冲区。后面三个带fs.obs.前缀的属性是让 Hadoop 认识 OBS 存储的钥匙，ak、sk、endpoint 一个都不能少。这里的fs.obs.endpoint不需要加桶名前缀，只写到区域 Endpoint 域名即可。需要特别提醒的是：不同厂商的 OBS 兼容实现用的属性前缀可能不同，如果这里有出入，可以看配套的 jar 包文档确认，但整体思路是一致的——把 AK、SK、Endpoint 三样填对。

hdfs-site.xml 里主要控制 NameNode 元数据和副本策略，给一份最简配置：

<!-- hdfs-site.xml 关键配置段 --> <configuration> <!-- 指定元数据存放目录 --> <property> <name>dfs.namenode.name.dir</name> <value>/home/modules/data/buf/name</value> </property> <!-- 指定数据块存放目录 --> <property> <name>dfs.datanode.data.dir</name> <value>/home/modules/data/buf/data</value> </property> <!-- 副本数：三节点集群设 2 或 3 --> <property> <name>dfs.replication</name> <value>2</value> </property> </configuration>

dfs.replication的值建议设成 2。三节点集群设 3 意味着每个数据块存三份，虽然安全但浪费存储；设 2 在保证数据不丢的前提下更经济。如果你是做课程实验，2 完全够用。

yarn-site.xml 和 mapred-site.xml 的配置相对固定：

<!-- yarn-site.xml 关键配置段 --> <configuration> <!-- ResourceManager 所在节点 --> <property> <name>yarn.resourcemanager.hostname</name> <value>node-0001</value> </property> <!-- NodeManager 辅助服务 --> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> </configuration>

mapred-site.xml 本身在 Hadoop 2.8.3 里没有默认文件，需要从模板复制一份再改。关键属性只有一行，指定 MapReduce 跑在 YARN 上：

<!-- mapred-site.xml 关键配置段 --> <configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> </configuration>

最后是 slaves 文件，它是 Hadoop 2.x 里声明工作节点名单的地方。改成内容只有两个节点名：

node-0002 node-0003

注意 slaves 文件不要写 node-0001。如果写了，node-0001 会同时跑 DataNode，虽然也能工作，但会让 NameNode 节点的负载偏高，生产环境一般不这么干。官方在 Hadoop 3.x 里已经把 slaves 改名成了 workers，在 2.8.3 里就叫 slaves，按原报告沿用这个名字即可。

4.2 JAVA_HOME 失效的连锁反应：现象、原因与解决

原报告里反复出现同一句话：“因为 javahome 的错误导致这里出错了，更改之后执行”。这句话让很多照着做的人一头雾水，因为报告没说清楚到底哪里错了。我复现时把这几处错误完整走了一遍，归纳成两条最典型的。

第一个典型错误是java -version能执行成功，但 Hadoop 启动时报“JAVA_HOME is not set”。现象是 start-dfs.sh 或 start-yarn.sh 执行后，终端直接报错退出。原因在于 Hadoop 脚本会从两个地方读 JAVA_HOME：一是系统环境变量，二是etc/hadoop/hadoop-env.sh文件里的显式配置。如果你只改了/etc/profile，但 Hadoop 的hadoop-env.sh里写死了另一个路径，脚本会优先采用文件里那个失效值。

解决方法是打开$HADOOP_HOME/etc/hadoop/hadoop-env.sh，找到 JAVA_HOME 那一行，把它改成和/etc/profile一致：

# hadoop-env.sh 中指定 JAVA_HOME 为实际 JDK 目录 export JAVA_HOME=/home/modules/jdk1.8.0_242

改完之后在各节点执行hadoop version，能正常输出版本号才继续。这个文件在三台节点上都要同步，否则还是会有节点失败。

第二个典型错误是 JAVA_HOME 路径里多写了/bin。比如写成export JAVA_HOME=/home/modules/jdk1.8.0_242/bin，Hadoop 的启动脚本拼出来的是$JAVA_HOME/bin/java，最终成了/home/modules/jdk1.8.0_242/bin/bin/java，系统当然找不到可执行文件。判断方法很简单：执行echo $JAVA_HOME，如果输出结尾是/bin，就少写了一层；正确路径应该直接指向 jdk 根目录。这个问题在每台节点上都要逐一确认，很容易被漏掉，原报告里就是因为这个返工了好几次。

4.3 配置分发不一致与 NameNode 初始化恢复

三节点集群最怕“一台配置改好了，另外两台没同步”。我在某图像处理Demo的集群环境里见过最典型的问题：core-site.xml 只在 node-0001 改了，node-0002、node-0003 还是默认配置。启动时 node-0001 能当上 NameNode，但两个 DataNode 注册不上，一直报“org.apache.hadoop.ipc.RemoteException”。

解决思路是把整个配置目录打包分发到各节点，避免手工逐台改。常见做法是写一个小脚本，在 node-0001 上执行：

# 将 Hadoop 配置目录分发到 node-0002 和 node-0003 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/ # 同步 /etc/profile 到其他节点 scp /etc/profile root@node-0002:/etc/profile scp /etc/profile root@node-0003:/etc/profile # 其他节点重新加载环境变量 ssh root@node-0002 "source /etc/profile && echo JAVA_HOME=$JAVA_HOME" ssh root@node-0003 "source /etc/profile && echo JAVA_HOME=$JAVA_HOME"

scp -r会把整个配置目录覆盖过去，包括你改好的 core-site.xml、hdfs-site.xml 等文件。执行完后一定要在目标节点上用hadoop version或echo $JAVA_HOME验证一遍，确认环境变量真的生效了。有人改了/etc/profile后不source就急着启动，开了一个新会话又发现变量没生效，其实是因为/etc/profile只在登录会话时加载，当前会话需要用source手动激活一次。

NameNode 初始化是另一个高频失败点。格式化的命令是：

# 在 node-0001 上执行格式化，仅首次运行前需要 hadoop namenode -format

如果格式化之后启动失败，排查思路要看dfs.namenode.name.dir指向的目录里有没有残留的元数据。常见情况是第一次格式化中途报错中断，文件系统里已经生成了半截元数据，第二次格式化时 Hadoop 检测到目录非空，直接拒绝执行。解决方法是先清空 name 目录再重新格式化：

# 备份旧元数据并清理后再格式化 mv /home/modules/data/buf/name /home/modules/data/buf/name.bak mkdir -p /home/modules/data/buf/name hadoop namenode -format

格式化并不是可以随意反复执行的操作。NameNode 一旦格式化，会生成一个新的集群 ID，原来所有 DataNode 记录的集群 ID 就和它不匹配了。如果三台节点都跑过旧集群，格式化后要么把各节点 DataNode 数据目录也清掉，要么后面 DataNode 会因集群 ID 不匹配而拒绝加入。如果你只是配置改错了，不要急着重新格式化，先修配置再启动；格式化只做一次。

数据目录权限问题也不能忽视。有的环境里/home/modules/data/buf是 root 创建的，但 Hadoop 进程以其他用户身份运行，启动时 DataNode 写不了数据目录。遇到这种报错，把目录属主改成运行用户，或者直接chown -R到当前用户，就能绕过去。原报告里能一次启动成功，是因为目录都是同一用户全程创建的。

5. 用 jps 和一条命令验证集群状态，再继续跑 WordCount

启动 HDFS 和 YARN 之后，很多人以为看到“启动成功”四个字就结束了，其实那只是进程被拉起来了，集群未必在正常工作。我最常用的验证方式是先看进程，再看 DataNode 上线数量，最后实际读写一个文件。

启动命令在 node-0001 上执行：

# 启动 HDFS 与 YARN start-dfs.sh start-yarn.sh

启动完成后，在 node-0001 上执行jps，应该能看到四个进程：NameNode、SecondaryNameNode、ResourceManager、Jps。在 node-0002 和 node-0003 上执行jps，应该看到 DataNode、NodeManager、Jps。如果某台节点缺少 DataNode 进程，去对应节点看日志，路径在$HADOOP_HOME/logs下。

进程齐全只代表服务起来了，数据节点是否都注册上了还要看 HDFS 自己的报告。执行下面这条命令：

# 查看 DataNode 是否全部在线 hdfs dfsadmin -report

输出里如果显示 2 个 Live datanode，说明两个工作节点都成功加入集群。如果只有 1 个，先去那台掉线节点查网络和防火墙，再看/etc/hosts里的映射是否和 node-0001 一致。这个检查比jps更严格，因为它是 HDFS 层面的健康状态。

集群健康之后，下一步应该验证 OBS 集成是否真的可用。用hadoop fs命令直接列出对象存储桶的内容：

# 列出 OBS 桶下的文件，bucket-name 替换为你的桶名 hadoop fs -ls obs://bucket-name/

这条命令能跑通，说明 core-site.xml 里的 AK、SK、Endpoint 三个参数都写对了，OBS 与 Hadoop 的链路是通的。如果报权限错误，优先检查 AK/SK 是否复制了正确的值；如果报连接超时，八成是 Endpoint 区域和桶不一致。我在复现时遇到过一次超时，最后发现是桶建在另一个区域，Endpoint 却沿用了实验报告里的默认值，换成同区域的 Endpoint 后立即恢复。

以上都通过后，可以跑一个最经典的 WordCount 作业来验证计算链路。使用 Hadoop 自带示例包：

# 在 HDFS 里创建测试目录并放一个文本文件 hadoop fs -mkdir /test echo "hello world hello hadoop" | hadoop fs -put - /test/input.txt # 运行 WordCount 示例 hadoop jar /home/modules/hadoop-2.8.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.8.3.jar wordcount /test/input.txt /test/output # 查看统计结果 hadoop fs -cat /test/output/part-r-00000

看到输出里每个单词及其出现次数，就说明从环境准备到集群搭建再到作业提交的整条链路都是通的。这也是我给模拟项目X做验收时固定的最后一步——没有跑通一个真实作业，前面的所有启动成功都不算数。从那以后，我每次搭完 Hadoop 集群都会强制走一遍“jps 查进程 → dfsadmin 查节点 → OBS 访问 → WordCount 跑作业”的验证流程，整套下来不到十分钟，却能过滤掉大部分隐藏问题。这份实验报告的价值不在于它是标准答案，而在于它把返工过程也记录下来了，你照着复现时，能少走好几轮弯路。希望帮到你。

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