简介《鲲鹏云大数据实验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时有几个参数是需要和实验报告对齐的配置项推荐值说明架构ARM鲲鹏系列整份实验的包都是按 ARM 架构准备的规格2 vCPU / 8 GB 起Hadoop 三节点至少这个规格才跑得动系统盘40 GB装系统和 Hadoop 足够数据盘100 GB放 HDFS 数据块和临时目录镜像厂商 ARM 生态对应的 Linux 发行版不要选 x86 镜像否则所有包全部重来网络同一私有网络、同一子网方便内网互通和后面的 /etc/hosts 直接对应购买时我的习惯是按需购买实验做完就释放避免包周期费用浪费。三台机器的购买顺序无所谓但购买完成后一定要记下每台机器的内网 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 rootnode-0002 # 再安装到 node-0003 ssh-copy-id rootnode-0003ssh-copy-id做的事就是把公钥追加到对方机器的~/.ssh/authorized_keys同时自动处理好目录权限。如果你的系统没有这个命令也可以手工追加等价操作是把本机公钥内容通过 SSH 管道写入对方文件# 等价的手工方式将本地公钥追加到远端 authorized_keys cat /root/.ssh/id_rsa.pub | ssh rootnode-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/localdirdata/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.xmletc/hadoop默认文件系统、OBS 接入、临时目录hdfs-site.xmletc/hadoopNameNode 元数据目录、副本数yarn-site.xmletc/hadoopResourceManager 地址、NodeManager 资源mapred-site.xmletc/hadoopMapReduce 运行框架slavesetc/hadoop声明哪些节点是 DataNode/etc/profile系统JAVA_HOME 与 PATHcore-site.xml 是这个实验里最特殊的配置文件因为它不仅要写 HDFS 的默认文件系统地址还要把 OBS 的 AK/SK 和 Endpoint 写进去让 Hadoop 能通过 OBS 协议访问对象存储。我这里用占位符代替真实的 AK/SK你配置时需要替换成自己的 credentials.csv 里的值!-- core-site.xml 关键配置段 -- configuration !-- 默认文件系统指向 HDFS 集群入口 -- property namefs.defaultFS/name valuehdfs://node-0001:8020/value /property !-- 临时目录 -- property namehadoop.tmp.dir/name value/home/modules/data/buf/value /property !-- OBS 访问密钥替换为 credentials.csv 中的值 -- property namefs.obs.access.key/name valueYOUR_ACCESS_KEY_ID/value /property property namefs.obs.secret.key/name valueYOUR_SECRET_ACCESS_KEY/value /property !-- OBS Endpoint区域必须与桶一致 -- property namefs.obs.endpoint/name valueobs.region-code-1.myhuaweicloud-example.com/value /property !-- 缓冲区大小默认 4MB大文件可调大 -- property nameio.file.buffer.size/name value4096/value /property /configuration这段配置里前两个属性决定 Hadoop 的文件系统入口和临时目录位置。fs.defaultFS写的是hdfs://node-0001:8020意味着默认的文件操作都会走 HDFShadoop.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 namedfs.namenode.name.dir/name value/home/modules/data/buf/name/value /property !-- 指定数据块存放目录 -- property namedfs.datanode.data.dir/name value/home/modules/data/buf/data/value /property !-- 副本数三节点集群设 2 或 3 -- property namedfs.replication/name value2/value /property /configurationdfs.replication的值建议设成 2。三节点集群设 3 意味着每个数据块存三份虽然安全但浪费存储设 2 在保证数据不丢的前提下更经济。如果你是做课程实验2 完全够用。yarn-site.xml 和 mapred-site.xml 的配置相对固定!-- yarn-site.xml 关键配置段 -- configuration !-- ResourceManager 所在节点 -- property nameyarn.resourcemanager.hostname/name valuenode-0001/value /property !-- NodeManager 辅助服务 -- property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property /configurationmapred-site.xml 本身在 Hadoop 2.8.3 里没有默认文件需要从模板复制一份再改。关键属性只有一行指定 MapReduce 跑在 YARN 上!-- mapred-site.xml 关键配置段 -- configuration property namemapreduce.framework.name/name valueyarn/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/binHadoop 的启动脚本拼出来的是$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 rootnode-0002:/home/modules/hadoop-2.8.3/etc/ scp -r /home/modules/hadoop-2.8.3/etc/hadoop rootnode-0003:/home/modules/hadoop-2.8.3/etc/ # 同步 /etc/profile 到其他节点 scp /etc/profile rootnode-0002:/etc/profile scp /etc/profile rootnode-0003:/etc/profile # 其他节点重新加载环境变量 ssh rootnode-0002 source /etc/profile echo JAVA_HOME$JAVA_HOME ssh rootnode-0003 source /etc/profile echo JAVA_HOME$JAVA_HOMEscp -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 跑作业”的验证流程整套下来不到十分钟却能过滤掉大部分隐藏问题。这份实验报告的价值不在于它是标准答案而在于它把返工过程也记录下来了你照着复现时能少走好几轮弯路。希望帮到你。本文还有配套的精品资源点击获取