简介：这份华为云大数据实验报告面向高校大数据课程学习者与云计算入门实践者，围绕在华为云上部署和管理大数据平台展开，涉及弹性云服务器、OBS对象存储、Hadoop与Spark集群搭建及交互式查询等关键环节。文档按云主机实现大数据、云服务实现大数据、BigData Pro综合实验、大数据交互式查询四个模块组织，记录了购买ECS与OBS、配置访问密钥、安装OpenJDK、关闭防火墙、节点间SSH免密通信、验证集群与OBS互联、配置Spark环境以及编写查询语句分析数据等实操要点。压缩包内为1个docx文档，约4.36MB，目录完整、步骤连贯，便于按实验顺序查阅与复现。目前已有2541人学习，适合课程实验撰写、动手复现与对错核查时参考。

1. 需求先立住：云主机大数据实验报告为什么要拆成四段交付

如果你正在找云主机大数据实验报告的完整拆法，最容易忽略的不是某条安装命令，而是四段实验之间的交付边界。云主机大数据实验报告、云服务实现大数据、Hadoop 集群、Spark 集群、大数据交互式查询，这些词看起来像四个独立作业，实际共用一套资源拓扑和一条数据流。很多方案一上来就买机器、装 OpenJDK，最后卡在节点互信和对象存储互联，截图一堆却讲不清谁在算、谁在存、谁在查。这套拆法把实验一、实验二、综合实验和交互式查询压到同一条链路里：云主机提供算力，对象存储提供数据底座，Hadoop 与 Spark 负责批处理，查询引擎负责结果验证。适合正在交大数据课程设计、实验报告或毕设初稿的人，也适合要把云上大数据方案落到验收表的从业者。

2. 总体架构设计：四类实验、六个模块与一条数据流

这套方案先定拓扑，再谈安装。四台云主机按 node1 到 node4 编号，node1 承担 NameNode 与 ResourceManager 入口，node2 到 node4 承担 DataNode 与 NodeManager；对象存储桶作为原始数据、中间结果和交换区；Spark 复用 YARN 资源；交互式查询通过 Spark SQL 或同类引擎完成。这样拆的好处是，实验一、实验二、综合实验和查询实验都能落在同一张拓扑图上，答辩时不用反复换图。

2.1 实验拓扑与资源清单：四台云主机加一个对象存储桶

资源清单不需要堆得很豪华，但角色必须清楚。课程实验规模通常按“管理节点 1 台、工作节点 3 台”起步，单节点内存和磁盘按样本数据量留出 2 倍余量；如果样本只有几十 MB，四台小规格云主机也够跑通 WordCount 和 Spark 提交。对象存储桶单独规划，不要和系统盘混在一起讲，否则读者分不清哪部分是计算、哪部分是存储。

主机名规划要先于安装。node1 到 node4 必须能在每台机器上互相解析，否则后面 SSH 互信、Hadoop 启动、Spark 提交都会出现“命令没错但就是连不上”的玄学问题。我一般会先写一份节点清单，把管理节点、工作节点、对象存储桶名、实验目录一次性定死，后续所有截图和命令都围绕这份清单走。

提示：实验环境可以临时关闭防火墙，生产环境不要照搬，应按端口最小放行，尤其是 SSH 和对象存储端点。

目录也要统一。Hadoop、Spark、日志、样本数据分别落到固定路径，后面查日志和写实验报告时不会出现“昨天放在 /root，今天放在 /home”的混乱。下面这段只做目录初始化，不涉及具体版本，命令里的路径可以按自己的云主机规划替换。

# 统一实验目录，避免 Hadoop、Spark、日志和样本数据散落在不同用户目录 sudo mkdir -p /opt/bigdata/{hadoop,spark,logs,data} sudo chown -R "$USER":"$USER" /opt/bigdata # 查看目录归属，确认后续普通用户可写 ls -ld /opt/bigdata /opt/bigdata/*

这里的hadoop、spark、logs、data是四类固定目录：前者放解压后的组件，logs放运行日志，data放本地样本和临时文件。chown把归属改到当前实验用户，避免后面启动脚本因为权限不足写不进日志。路径不是重点，重点是从第一天起就统一，别等到答辩前才到处找日志。

2.2 四类实验的交付边界：谁负责算、谁负责存、谁负责查

四类实验最容易写成流水账：实验一贴购买截图，实验二贴桶截图，综合实验贴集群截图，查询实验贴一条 SQL 结果。读者看完不知道每一段到底交付了什么。更稳妥的写法是给每类实验定一个交付边界，每段只留一条主证据，其他截图放附录。

实验一的核心不是“买了多少台机器”，而是“集群能不能跑”。node1 到 node4 完成主机名、SSH 互信、OpenJDK、Hadoop 配置后，跑一次 WordCount，输出目录里出现part-r-00000，这段才算交付。实验二的核心不是“创建了一个桶”，而是“计算节点能访问对象存储”，上传一个小文件、列出桶内对象、再下载回来校验，三条操作串起来才有说服力。

综合实验把 Hadoop 和 Spark 接起来。Spark 提交到 YARN 时，要能说清楚 Driver 在哪、Executor 从哪来、输入输出路径是什么。交互式查询则落在“能建表、能过滤、能解释结果”上，SQL 不是贴得越长越好，而是要让读者看到分区字段、过滤条件和结果数量之间的关系。四段实验共用一套数据流，交付边界清楚，报告自然不散。

2.3 数据流与网络边界：从本地文件到 HDFS 再到查询结果

数据流建议画成一条线：本地样本先进入对象存储桶或 HDFS，MapReduce 做词频统计，Spark 做二次处理，交互式查询把结果表化，最后用一条聚合 SQL 验证数量。这样写的好处是，每个实验都能回答“数据从哪来、到哪去、谁消费”。对象存储桶负责长期存放和交换，HDFS 负责计算过程中的临时数据，查询引擎负责结果呈现，三者不要混为一谈。

网络边界要单独说明。管理网走 SSH，数据网走 Hadoop RPC 和 YARN 调度，公网只用于实验期间登录。安全组不要图省事全开，至少把 SSH 来源限制在实验网络，Hadoop Web 端口只对需要截图的地址开放。端口表不用背，但报告里要写清楚“按实际配置文件确认”，常见端口包括 SSH 22、NameNode RPC 8020、NameNode Web 9870 或 50070、YARN Web 8088，具体以安装版本和配置文件为准。

数据流和网络边界讲清楚后，后面章节的安装命令才有落点。否则读者只看到一堆ssh、scp、hadoop jar，不知道这些命令在整条链路里占什么位置。我的习惯是先把这张拓扑和数据流写进报告前半部分，后面每完成一个实验，就回到图上标一次状态，最后答辩时图是活的，不是装饰。

3. 云主机侧落地：从 OpenJDK 初始化到 Hadoop 集群 WordCount

云主机侧的落地顺序我一般按“系统初始化、SSH 互信、Hadoop 配置、WordCount 验证、对象存储互联”走。顺序反了很容易翻车：先装 Hadoop 再改主机名，配置里全是旧地址；先配对象存储再验 SSH，凭证和网络问题混在一起，排查成本翻倍。下面按这条顺序拆。

3.1 节点初始化：OpenJDK、主机名与防火墙策略

每台云主机先确认主机名和解析。node1 到 node4 的/etc/hosts要一致，IP 用实验环境实际地址，报告里可以脱敏成文档保留地址。下面这段是示例，192.0.2.x不是实际地址，替换成自己的内网地址即可。

# 在每台节点写入统一的主机名映射，IP 按实验环境替换 cat >> /etc/hosts <<'EOF' 192.0.2.11 node1 192.0.2.12 node2 192.0.2.13 node3 192.0.2.14 node4 EOF # 验证解析顺序，确保 ping 到的是内网地址 getent hosts node1 node2 node3 node4

getent hosts比直接ping更适合写进报告，因为它只验证解析，不受 ICMP 策略影响。四台机器的主机名映射必须完全一致，否则 node1 认为 node2 是 192.0.2.12，node2 却把自己解析成别的地址，SSH 和 Hadoop 都会出现“有时通有时不通”的怪现象。

OpenJDK 安装按系统包管理器走，包名以镜像源为准。下面只表达安装动作，不绑定具体版本号。

# 安装 OpenJDK 开发包，包名按云主机镜像源替换 sudo yum install -y java-*-openjdk-devel # 确认 java 与 javac 都能被当前用户调用 java -version javac -version

java -version和javac -version要同时通过。只装 JRE 时java能跑，但 Hadoop 编译或 Spark 提交可能找不到javac。安装完成后把JAVA_HOME写进实验环境变量，后面 Hadoop 启动脚本会用到。路径用readlink -f "$(which java)"反推，不要凭记忆写。

防火墙在实验环境可以临时关闭，但报告里要注明“仅隔离实验环境”。生产环境按端口放行，SSH、Hadoop RPC、YARN Web、对象存储端点分别授权。

# 仅实验环境临时关闭防火墙；生产环境改为按端口最小放行 sudo systemctl stop firewalld sudo systemctl disable firewalld sudo setenforce 0 || true

这段命令不是鼓励关防护，而是避免实验阶段被本机策略拦住。写报告时要把“为什么关、关了影响什么、生产怎么替代”写进去，否则答辩时容易被问住。节点初始化完成后，四台机器应该能互相解析、Java 可用、目录统一，再进入互信配置。

3.2 SSH 互信：公钥汇总与无密码跳转验证

SSH 互信是后面所有远程操作的前提。每台节点生成自己的密钥，把公钥汇总后分发到所有节点的authorized_keys。不要只在一台机器上生成再复制私钥，那样实验报告里说不清权限边界，也不利于排查。

# 每台节点执行：生成密钥并初始化 authorized_keys ssh-keygen -t rsa -b 4096 -N '' -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys # 收集四台公钥后，统一分发到每台节点 cat node1.pub node2.pub node3.pub node4.pub > all_authorized_keys for h in node1 node2 node3 node4; do scp all_authorized_keys "$h":~/.ssh/authorized_keys ssh "$h" 'chmod 600 ~/.ssh/authorized_keys' done

ssh-keygen的-N ''表示空口令，只适合实验环境；-f指定密钥路径。chmod 700和600是 SSH 的硬要求，权限过宽会导致公钥被忽略，现象就是“明明复制了公钥还要输密码”。分发完成后逐台验证：

# 从 node1 跳到 node2~node4，第一次需要确认主机指纹 for h in node2 node3 node4; do ssh "$h" hostname done

输出应该是 node2、node3、node4。如果某台仍然要密码，先看~/.ssh/authorized_keys权限，再用ssh -vvv看公钥有没有被服务端接受。互信验证通过后，Hadoop 启动脚本才能在不同节点上拉起进程。

3.3 Hadoop 配置：core-site.xml 与 WordCount 验证

Hadoop 配置先改core-site.xml，把默认文件系统指向 node1 的 NameNode RPC 地址。端口 8020 是常见配置，按实际core-site.xml和hdfs-site.xml调整。

# 在 node1 写入默认文件系统地址，node2~node4 保持同一份配置 export HADOOP_HOME=/opt/bigdata/hadoop cat > "$HADOOP_HOME/etc/hadoop/core-site.xml" <<'EOF' <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://node1:8020</value> </property> </configuration> EOF

fs.defaultFS决定客户端默认访问哪个文件系统，hdfs://node1:8020里的 node1 必须能被所有节点解析，8020 是 NameNode RPC 端口。配置改完后同步到 node2 到 node4，不要只改一台。接着格式化 NameNode 并启动：

# 首次启动前格式化 NameNode；已有数据不要重复执行 hdfs namenode -format start-dfs.sh start-yarn.sh jps

hdfs namenode -format只做一次，重复执行会清掉元数据。start-dfs.sh拉起 HDFS，start-yarn.sh拉起 YARN，jps用来确认 NameNode、DataNode、ResourceManager、NodeManager 是否出现。node1 上应该看到 NameNode 和 ResourceManager，工作节点上应该看到 DataNode 和 NodeManager。少进程先看日志，不要急着重装。

WordCount 验证用 Hadoop 自带样例。先把样本上传到 HDFS，再提交任务，最后看输出目录。

# 上传样本并运行 WordCount，输出目录不能已存在 hdfs dfs -mkdir -p /input/wordcount hdfs dfs -put ./sample.txt /input/wordcount/ hadoop jar "$HADOOP_HOME"/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \ wordcount /input/wordcount /output/wordcount hdfs dfs -cat /output/wordcount/part-r-00000 | head

/input/wordcount是输入目录，/output/wordcount是输出目录，输出目录必须不存在，否则任务会拒绝执行。part-r-00000是 Reduce 输出文件，里面是按词频统计的结果。报告里不要只截一张“任务成功”，要把输入文件、输出目录、计数结果放在一起，读者才能判断这条链路真的通了。

3.4 对象存储互联：凭证注入与读写测试

对象存储互联是实验二和综合实验的衔接点。凭证不要写进脚本，也不要直接截图放进报告。通常的做法是从受控文件读取，导出为环境变量，后续命令只引用变量。

# 凭证从受控文件读取，不在命令行明文出现 export OBJECT_ENDPOINT="https://<对象存储端点>" export OBJECT_BUCKET="<实验桶名>" export OBJECT_ACCESS_KEY="$(awk -F, 'NR==2{print $2}' credentials.csv)" export OBJECT_SECRET_KEY="$(awk -F, 'NR==2{print $3}' credentials.csv)" test -n "$OBJECT_ENDPOINT" && test -n "$OBJECT_ACCESS_KEY" && echo "凭证环境已就绪"

OBJECT_ENDPOINT是对象存储服务端点，OBJECT_BUCKET是实验桶名，awk从凭证文件第二行取 Access Key 和 Secret Key。这个代码块只验证环境变量是否就绪，不连接服务。真正的互联测试用云平台提供的对象存储客户端完成三条动作：上传一个小文件、列出桶内对象、下载回本地并校验文件大小或摘要。三条都通过，才在报告里写“对象存储互联成功”。

注意：凭证文件不要提交到代码仓库，实验报告里的截图要做脱敏，Access Key 和 Secret Key 不能出现完整值。

对象存储互联通过后，云主机侧的交付就完整了：四台节点能互信，Hadoop 能跑 WordCount，计算节点能访问对象存储。后面 Spark 和交互式查询都建立在这条链路上，不要跳过这一步直接上 Spark，否则出问题时分不清是资源调度还是存储访问。

4. 云服务侧落地：对象存储、Spark 集群与交互式查询串接

云服务侧的重点不是多买几个服务，而是把“存、算、查”串起来。对象存储桶负责数据底座，Spark 复用 Hadoop 的 YARN 资源，交互式查询把结果表化。三段之间用同一份样本数据贯穿，报告才不会写成服务说明书。

4.1 对象存储桶与并行文件系统：桶策略、目录规划与凭证脱敏

对象存储桶先定目录，再谈上传。建议至少分四层：raw放原始样本，staging放中间结果，output放任务输出，logs放日志归档。并行文件系统适合需要高吞吐读写的场景，普通对象存储桶适合归档和交换。实验报告里要写清楚哪类数据放哪里，不要把所有文件丢在桶根目录。

桶策略设为私有读写，实验结束回收凭证。凭证脱敏有三个动作：不写进代码、不贴完整截图、不在命令行参数里明文出现。下面这段只做目录变量准备，不包含真实密钥。

# 桶内目录用变量管理，后续上传和下载只改变量 export RAW_PATH="raw/$(date +%Y%m%d)" export OUTPUT_PATH="output/wordcount" # 打印路径，确认没有把凭证带进输出 echo "$RAW_PATH" "$OUTPUT_PATH"

RAW_PATH按日期分目录，避免多次实验互相覆盖；OUTPUT_PATH固定到任务名，方便回查。路径变量化以后，报告里的命令更干净，也不会因为手工拼路径导致上传到错误目录。对象存储桶和并行文件系统的选择要看数据访问模式：频繁读写、需要挂载式访问时用并行文件系统；一次性上传、长期归档用普通桶。

4.2 Spark 集群协同：提交参数与资源队列

Spark 集群搭建完成后，不要单独再造一套资源管理，直接提交到 YARN。spark-submit的关键参数是 master、deploy-mode、class、输入输出路径。下面是一个提交模板，类名和路径按实际作业替换。

# Spark 提交到 YARN，资源队列和 executor 数量按集群规模调整 spark-submit \ --master yarn \ --deploy-mode cluster \ --class <主类名> \ --num-executors 2 \ --executor-memory 1g \ ./demo.jar \ --input /input/wordcount \ --output /output/spark-wordcount

--master yarn表示资源交给 YARN 调度，--deploy-mode cluster表示 Driver 在集群里运行，--num-executors和--executor-memory控制资源占用。实验环境资源有限时，executor 不要开太多，否则 YARN 会一直等容器。提交后去 YARN 页面看应用状态，再看输出目录是否生成。报告里要写清楚“提交命令、应用 ID、输出路径”三件事，不要只贴一张运行成功的截图。

Spark 和 Hadoop 协同的关键是路径一致。Hadoop 的 WordCount 输出可以作为 Spark 的输入，Spark 的输出也可以作为交互式查询的外部表路径。这样四段实验就是一条链，而不是四个孤岛。

4.3 交互式查询：外部表、分区过滤与结果校验

交互式查询用外部表指向数据路径，按分区过滤，最后做聚合验证。下面的表结构是示例，字段按实际样本替换。

-- 交互式查询：外部表指向数据路径，分区字段用于过滤 CREATE EXTERNAL TABLE IF NOT EXISTS user_events ( user_id STRING, event_name STRING, event_time TIMESTAMP ) PARTITIONED BY (dt STRING) STORED AS PARQUET LOCATION '<数据根路径>'; SELECT event_name, COUNT(*) AS cnt FROM user_events WHERE dt = '<日期分区>' GROUP BY event_name ORDER BY cnt DESC LIMIT 10;

EXTERNAL TABLE表示表只管理元数据，不移动原始文件；PARTITIONED BY (dt STRING)让查询按日期裁剪；LOCATION指向对象存储桶或 HDFS 路径；WHERE dt = '<日期分区>'是分区过滤，避免全量扫描。查询结果要和源数据总量对得上：先查总行数，再查分组行数，最后抽样看明细。如果总数对不上，先查分区路径有没有多余文件，再查字段分隔符和空值处理。

交互式查询的验收标准不是“SQL 能跑”，而是“结果能解释”。比如分组计数之和等于过滤后的总行数，抽样明细和原始文件一致，分区过滤前后数量变化符合预期。把这三条写进报告，比贴十条复杂 SQL 更有说服力。至此，对象存储、Spark 集群和查询链路串接完成，下一章集中处理最容易翻车的排查点。

5. 避坑与排查：五类高频翻车点从现象查到根因

实验报告写到最后，拼的不是谁命令多，而是谁能在出问题时快速定位。下面五类问题在云主机大数据实验里出现频率很高，每一条都按“现象、原因、解决”写，报告里可以直接改成排查记录。

5.1 节点互信失败：公钥没落盘、权限过宽与主机名漂移

现象是ssh node2仍然提示输入密码，或者第一次能跳、重启后又要密码。原因通常有三个：公钥没有写进目标节点的authorized_keys，.ssh目录权限过宽，主机名解析到了旧地址。先看权限，再用ssh -vvv看服务端是否接受公钥。

# 互信排查：看权限、看公钥、看解析 ls -ld ~/.ssh ~/.ssh/authorized_keys ssh -vvv node2 true getent hosts node2

ls -ld确认.ssh是 700、authorized_keys是 600；ssh -vvv会打印公钥尝试过程；getent hosts确认 node2 解析到当前内网地址。权限不对就改权限，公钥没落盘就重新分发，主机名漂移就统一/etc/hosts。这类问题不要靠重启解决，重启只会让现象暂时变化。

5.2 对象存储互联失败：端点、桶名与凭证三件套

现象是上传报 403、连接超时，或者列出桶时提示桶不存在。原因多半是端点写错、桶名拼错、凭证没有权限，或者节点时间偏差过大。先确认环境变量不为空，再确认端点能解析，最后用最小文件做一次上传测试。

# 对象存储排查：先确认变量和解析，再测试最小文件 test -n "$OBJECT_ENDPOINT" && echo "endpoint ok" test -n "$OBJECT_BUCKET" && echo "bucket ok" getent hosts <对象存储端点域名> date -u

test -n只检查变量是否为空，getent hosts检查端点解析，date -u检查 UTC 时间是否偏差过大。凭证权限要最小化，只给实验桶读写，不要给整个账号的管理权限。报告里写“对象存储互联失败”时，把端点、桶名、权限范围写清楚，但不要写完整密钥。

5.3 集群资源不足：YARN 队列、内存与容器数

现象是 Spark 提交后一直卡在 ACCEPTED，或者 YARN 提示容器分配失败。原因通常是 executor 内存超过队列上限、节点可用内存不足，或者虚拟内存检查过严。先看应用状态，再看节点资源。

# 查看 YARN 应用和节点资源，定位是队列等待还是容器失败 <p> <a href="https://download.csdn.net/download/qq_43624193/78575837" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>