简介实验报告以华为云鲲鹏云环境为依托完整记录在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还要放通下面几个端口用途建议来源9000HDFS NameNode RPC集群内网50070HDFS Web UI你的办公网 IP8088YARN ResourceManager Web UI你的办公网 IP50010DataNode 数据传输端口集群内网集群内网互通是重点。三台 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 NameIAM 用户名Access Key IdAK用来标识身份Secret Access KeySK等同于密码提示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的权限必须改成 600chmod 600 /home/modules/hadoop-2.8.3/etc/hadoop/core-site.xml这里给出第 3 章会用到的最小 OBS 参数清单先有个印象property namefs.obs.access.key/name value你的AK/value /property property namefs.obs.secret.key/name value你的SK/value /property property namefs.obs.endpoint/name valueobs.cn-north-4.myhuaweicloud.com/value /propertyAK 和 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 rootnode-0002 mkdir -p /root/.ssh chmod 700 /root/.ssh cat /root/.ssh/id_rsa.pub | ssh rootnode-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.3cd /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 namefs.defaultFS/name valuehdfs://node-0001:9000/value /property property namefs.obs.impl/name valuecom.huaweicloud.fs.obs.OBSFileSystem/value /property property namefs.obs.access.key/name value你的AK/value /property property namefs.obs.secret.key/name value你的SK/value /property property namefs.obs.endpoint/name valueobs.cn-north-4.myhuaweicloud.com/value /property /configuration这里要解释参数之间的依赖fs.defaultFS决定了hdfs dfs -ls /看到的根目录我把它指到 node-0001 的 9000 端口意味着集群的核心存储还是 HDFSfs.obs.impl指定 OBS 实现类依赖前面放的 jar 包fs.obs.endpoint必须和你购买 OBS 的 region 一致华北四是cn-north-4你在其他 region 就得换。很多人卡在这个坑上第 4 章会展开说。第二个是hdfs-site.xml配置 HDFS 的副本数和元数据目录configuration property namedfs.replication/name value2/value /property property namedfs.namenode.name.dir/name value/home/modules/data/name/value /property property namedfs.datanode.data.dir/name value/home/modules/data/buf/value /property /configurationdfs.replication是三节点集群的副本数设成 2 既容错又不会拖慢写入。dfs.namenode.name.dir是元数据存储目录要在 node-0001 上先建好dfs.datanode.data.dir对应前面建好的/home/modules/data/buf。节点上数据目录不一致DataNode 会拒绝启动这也是为什么目录必须统一预建。第三个是yarn-site.xml配置资源调度框架configuration property nameyarn.resourcemanager.hostname/name valuenode-0001/value /property property nameyarn.nodemanager.local-dirs/name value/home/nm/localdir/value /property /configurationyarn.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 namemapreduce.framework.name/name valueyarn/value /property /configuration第五个是slaves文件定义哪些节点是 DataNode 和 NodeManagernode-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版本对不上。解决先看清系统里装了哪些 JDKupdate-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。三查三验全部通过我才会认为集群是真的起来了而不是「暂时能跑」。这套习惯帮我省掉了无数小时的反复重启希望也能帮到你。完整实验文档里有每一步操作对应的截图和配置文件模板需要的话可以下载下来对照着改比只看笔记更稳。本文还有配套的精品资源点击获取