简介：这份鲲鹏云大数据实验docx面向高校学生与云计算初学者，聚焦在华为云环境中搭建Hadoop集群的完整实践。内容从购买ECS与OBS、获取AK/SK认证密钥讲起，逐步覆盖节点互信配置、SSH无密码登录、目录结构创建、core-site.xml等核心配置文件编写，以及NameNode初始化与HDFS服务启动，并记录了Java家目录出错后重新分发Hadoop包的排错过程。资源包内含1个docx文件，大小约2.52MB，以图文步骤形式呈现实验全流程。目前已有891人学习下载，适合需要掌握云环境下大数据基础设施部署与管理的读者参考，可帮助理解OBS作为数据源的接入方式、集群节点一致性维护及服务启动常见问题的解决思路，对课程实验与项目实践均有较高参考价值。
1. 鲲鹏云大数据实验docx：从一份实验文档到能跑通的集群
很多人第一次接触鲲鹏云大数据实验，拿到手的往往就是一份 docx——里面写着实验目的、步骤截图、命令片段，看起来什么都有，真照着敲却处处卡壳。这份文档本身不是问题，问题在于它通常只记录了「成功路径」，没记录环境差异、参数含义和失败回退。鲲鹏云底层是 ARM 架构，大数据组件在 aarch64 上的编译、依赖、内存行为跟 x86 有明显区别，直接照搬网上 x86 的教程，翻车概率极高。这篇笔记面向两类人：一是手里有实验 docx、需要在鲲鹏云上把 Hadoop/Spark/Hive 集群真正跑起来的学生和初级工程师；二是想把实验文档沉淀成可复现流程、避免每次重装都重新踩坑的开发者。我会把「文档里写了什么」和「实际要补什么」拆开讲，给出可抄的命令、参数和排查思路。
2. 先看懂 docx 里的实验拓扑：鲲鹏云上到底要搭什么
2.1 从文档目录反推集群角色
一份典型的大数据实验 docx，目录大致是：环境准备、JDK 安装、Hadoop 部署、Spark 部署、Hive 部署、实验验证。它不会明说的是：这几台机器各自承担什么角色。鲲鹏云实验常见的是三节点起步，角色划分如下。
| 节点 | 主机名示例 | 角色 | 常驻进程 |
|---|---|---|---|
| node1 | master | NameNode / ResourceManager / Hive Metastore | NameNode、RM、DataNode、NodeManager |
| node2 | slave1 | DataNode / NodeManager / Worker | DataNode、NodeManager |
| node3 | slave2 | DataNode / NodeManager / Worker | DataNode、NodeManager |
看文档时先确认三件事：节点数量、每台机器的 CPU 架构（uname -m返回aarch64还是x86_64）、内存大小。鲲鹏云实验环境常见单节点 4C8G 或 8C16G，内存直接决定你后面 YARN 容器能开多大。文档里如果只写「修改配置文件」，你要自己补上「改哪个文件的哪一行、改成什么值」。
2.2 确认架构与系统版本，别急着装
动手前先跑三条命令，把环境底数摸清。这一步文档通常不写，但它是后面所有编译和依赖问题的根源。
uname -m # 确认 CPU 架构，鲲鹏应为 aarch64 cat /etc/os-release # 确认发行版，常见 openEuler / CentOS / Ubuntu free -h # 确认内存，决定 YARN 容器上限 java -version # 确认是否已装 JDK，没装则后续统一装逻辑说明：uname -m决定你下载的安装包必须是 aarch64 版本，x86 的 tar 包在鲲鹏上根本跑不起来。/etc/os-release决定包管理命令用yum还是apt。free -h的数字要记下来，后面配yarn.nodemanager.resource.memory-mb时直接用。参数上，如果内存是 8G，YARN 可用内存一般给到 6G 左右，留 2G 给系统和其他进程，这是血泪经验，给满会频繁触发 OOM。
2.3 主机名与 hosts 映射：最容易被跳过的一步
文档里常写「配置主机名映射」，但不说为什么。Hadoop 各组件之间靠主机名通信，如果 hosts 没配好，会出现 NameNode 起来了但 DataNode 连不上、Spark 找不到 master 这类玄学问题。
# 在每台机器上执行，主机名按实际改 hostnamectl set-hostname node1 # 编辑 /etc/hosts，三台机器内容保持一致 cat >> /etc/hosts <<'EOF' 192.168.1.101 node1 192.168.1.102 node2 192.168.1.103 node3 EOF # 验证互通 ping -c 2 node2逻辑说明：hostnamectl改的是运行时主机名，重启后仍生效。/etc/hosts必须三台一致，否则跨节点解析会失败。ping验证的是网络层，如果 ping 不通先查安全组和网卡，别往下走。参数上，IP 换成你鲲鹏云实例的实际内网地址，不要用公网 IP 做集群内通信。
3. 按 docx 步骤落地：JDK、Hadoop、Spark 的鲲鹏适配
3.1 JDK 选型与安装：aarch64 版本别下错
大数据组件对 JDK 版本敏感。Hadoop 3.x 推荐 JDK 8，Spark 3.x 也以 JDK 8 为主。鲲鹏云上要下 aarch64 的 JDK 包，常见做法是用 OpenJDK 或毕昇 JDK。
# 以 openEuler 为例，直接用包管理安装 sudo yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel # 验证 java -version javac -version # 配置环境变量 echo 'export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk' >> ~/.bashrc echo 'export PATH=$JAVA_HOME/bin:$PATH' >> ~/.bashrc source ~/.bashrc逻辑说明：-devel包必须装，否则没有javac，后面编译会报错。JAVA_HOME路径用readlink -f $(which java)反推确认，不同发行版路径不同。参数上，如果实验 docx 指定了某个 JDK 版本，以文档为准；文档没写就选 JDK 8，兼容性最好。
3.2 Hadoop 部署：配置文件逐项对照
Hadoop 部署的核心是改五个文件：core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml、workers。文档里通常只贴了片段，这里给一份鲲鹏云三节点可用的最小配置。
<!-- core-site.xml --> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://node1:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/hadoop/data/tmp</value> </property> </configuration><!-- hdfs-site.xml --> <configuration> <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/opt/hadoop/data/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/opt/hadoop/data/data</value> </property> </configuration>逻辑说明：fs.defaultFS指向 node1 的 9000 端口，所有节点一致。hadoop.tmp.dir是临时目录，必须提前mkdir -p并授权，否则启动报权限错误。dfs.replication三节点设 2 即可，设 3 会让写入等待第三个副本，实验环境没必要。参数上，目录路径按你实际磁盘规划改，别放在根分区，容易写满。
<!-- yarn-site.xml --> <configuration> <property> <name>yarn.resourcemanager.hostname</name> <value>node1</value> </property> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>6144</value> </property> <property> <name>yarn.nodemanager.resource.cpu-vcores</name> <value>4</value> </property> </configuration>逻辑说明：resourcemanager.hostname指定 RM 所在节点。memory-mb按 2.2 节记下的内存来算，8G 机器给 6144，16G 给 12288。cpu-vcores按实际核数减 1 到 2，留出系统开销。这两个值给大了会拖垮节点，给小了任务排队，是调优里最常动的参数。
3.3 格式化与启动：顺序错了就得重来
配置改完，启动顺序是：格式化 NameNode → 启动 HDFS → 启动 YARN。顺序错了或者重复格式化，会导致 clusterID 不一致，DataNode 起不来。
# 只在 node1 执行，且只执行一次 hdfs namenode -format # 启动 HDFS start-dfs.sh # 启动 YARN start-yarn.sh # 验证进程 jps逻辑说明：-format只能执行一次，重复执行会清空元数据，如果已经启动过又格式化，需要把所有节点的data目录清掉重来。jps在 node1 应看到 NameNode、ResourceManager、DataNode、NodeManager，在 node2/node3 应看到 DataNode、NodeManager。如果某进程缺失，去对应节点的日志目录logs/下看.log文件，报错信息通常直接指出问题。
3.4 Spark 部署：on YARN 模式的关键参数
Spark 在鲲鹏云上一般跑 on YARN 模式，不单独起 Standalone 集群。装完解压后，重点是spark-env.sh和提交参数。
# spark-env.sh 关键项 export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_CONF_DIR=/opt/hadoop/etc/hadoop export YARN_CONF_DIR=/opt/hadoop/etc/hadoop# 提交一个测试任务 spark-submit \ --master yarn \ --deploy-mode client \ --executor-memory 2g \ --executor-cores 2 \ --num-executors 2 \ --class org.apache.spark.examples.SparkPi \ $SPARK_HOME/examples/jars/spark-examples_2.12-3.3.0.jar 10逻辑说明：HADOOP_CONF_DIR和YARN_CONF_DIR必须指向 Hadoop 配置目录，否则 Spark 找不到 YARN。executor-memory乘num-executors不能超过 YARN 可用总内存，否则任务卡在 ACCEPTED。deploy-mode client适合调试，cluster适合生产。参数上，num-executors按节点数乘每节点容器数来估，三节点 8G 内存大概能开 2 到 3 个。
4. 避坑与排查：docx 不会写的五类翻车现场
4.1 DataNode 启动后立刻消失
现象：jps里 DataNode 一闪而过，或者根本没出现。原因：多次namenode -format导致 clusterID 不一致，或者data目录权限不对。解决：停掉所有进程，删除所有节点的dfs.datanode.data.dir目录内容，重新格式化一次，确保只格式化一次，并chown给运行用户。
4.2 YARN 任务一直卡在 ACCEPTED
现象：spark-submit后任务状态长期 ACCEPTED，不进入 RUNNING。原因：请求的容器内存超过yarn.nodemanager.resource.memory-mb，或者yarn.scheduler.maximum-allocation-mb没调大。解决：把executor-memory降到单节点可用内存以下，同时在yarn-site.xml里把maximum-allocation-mb设为和resource-memory-mb一致，重启 YARN。
4.3 Hive 启动报 metastore 连接失败
现象：hive命令进去后执行 SQL 报无法连接 metastore。原因：MySQL 驱动没放、hive-site.xml里连接串写错、或者 MySQL 没启动。解决：确认mysql-connector-javajar 包在$HIVE_HOME/lib下，检查javax.jdo.option.ConnectionURL的主机名和端口，systemctl status mysqld看数据库状态。
4.4 鲲鹏上编译报 illegal instruction
现象：运行某个组件时报非法指令。原因：用了 x86 的二进制包，或者依赖里有 x86 的 native 库。解决：uname -m确认架构，重新下载 aarch64 版本；如果是 Maven 依赖，检查是否有linux-x86_64的 classifier，换成linux-aarch64。
4.5 磁盘写满导致 NameNode 进入安全模式
现象：HDFS 无法写入，NameNode 处于 safe mode。原因：hadoop.tmp.dir或数据目录所在分区写满。解决：df -h定位满的分区，清理日志和临时文件，或者把数据目录迁到大盘；然后hdfs dfsadmin -safemode leave退出安全模式。
5. 把 docx 变成可复现脚本：一个验证清单和自动化习惯
实验做完，docx 还是那份 docx，下次换台机器又要重来。我的习惯是把整个流程沉淀成一个setup.sh加一份verify.sh。setup.sh负责装 JDK、解压组件、分发配置；verify.sh负责逐项检查，输出一张通过/失败的表。
#!/bin/bash # verify.sh 核心检查项 check() { local name=$1; shift if "$@" >/dev/null 2>&1; then echo "[PASS] $name" else echo "[FAIL] $name" fi } check "架构为aarch64" test "$(uname -m)" = "aarch64" check "JDK可用" java -version check "NameNode进程" jps | grep -q NameNode check "DataNode进程" jps | grep -q DataNode check "YARN RM进程" jps | grep -q ResourceManager check "HDFS可写" hdfs dfs -mkdir -p /test && hdfs dfs -rm -r /test逻辑说明：check函数把命令的成功失败转成可读输出，方便一眼看出哪一步断了。hdfs dfs -mkdir加-rm是一次真实写入验证，比只看进程更可靠。参数上，jps的 grep 匹配进程名，如果你改了进程名要同步改。这个脚本我一般放在实验环境根目录，每次重启后先跑一遍，比翻 docx 快得多。
再补一个提交任务时的参数对照表，方便按机器规格直接查。
| 单节点内存 | resource-memory-mb | executor-memory | num-executors |
|---|---|---|---|
| 8G | 6144 | 2g | 2 |
| 16G | 12288 | 4g | 3 |
| 32G | 24576 | 8g | 4 |
最后说个我自己的教训：早期做鲲鹏实验，我总想一次把所有组件装完再验证，结果一出错就不知道是哪一层的问题。后来改成装完 JDK 验一次、装完 Hadoop 验一次、装完 Spark 再验一次，每次只引入一个变量，排查成本直接降下来。这份 docx 的价值不在于它写了多少，而在于你愿不愿意在它之外补上环境确认、参数推导和验证脚本这三块。希望帮到你。
本文还有配套的精品资源，点击获取
