企业官网建设流程全解析

简介：这份华为云大数据实验报告面向高校大数据、云计算相关课程的学习者与实验者，围绕在华为云上部署和管理大数据平台的关键技术展开，帮助读者打通从云主机到云服务、再到一站式大数据方案的实践路径。压缩包内共1个docx文档，约4.36MB，以图文实验记录形式呈现，内容涵盖Hadoop集群搭建、OBS对象存储配置、节点间SSH通信、Spark集群部署及交互式查询等环节。报告按实验一云主机实现大数据、实验二云服务实现大数据、综合实验一BigData Pro、综合实验四大数据交互式查询四个模块组织，目录层级清晰，便于按实验顺序对照操作与复盘。目前已有2490人学习下载，适合需要完成课程实验、理解云上大数据处理流程或准备相关实践考核的读者参考，可据此掌握集群搭建、服务配置与查询分析的基本技能。

1. 云上大数据实验的全景地图：从 ECS 到交互式查询

很多人第一次接触云上大数据实验，会把它当成一堆互不相干的命令：买机器、传密钥、改 hosts、跑 wordcount，做完就忘。真正梳理下来会发现，这四个实验其实是一条完整的链路——先用弹性云服务器 ECS 把 Hadoop 集群立起来，再用对象存储 OBS 把存储从计算里剥出去，接着用 BigData Pro 把 Hadoop 与 Spark 两套集群拼成一套可协同的环境，最后用交互式查询把前面攒下的数据真正查出来。这条链路对应的是「计算资源 → 存储资源 → 集群协同 → 数据消费」四层，任何一层没打通，后面的实验都会卡住。这份实验报告的价值就在于它把四层都走了一遍，适合正在系统学云上大数据部署、或者准备实验考核的人拿来当复习地图，重点不在背命令，而在搞清楚每一步为什么必须这么做。

2. 云主机与集群底座：ECS、OBS 与 Hadoop 的搭建要点

2.1 弹性云服务器与对象存储的准备工作

整个实验的起点是资源准备，这一步看起来最没技术含量，却决定了后面所有节点能不能互相看见。实验里先购买弹性云服务器 ECS，再购买对象存储服务 OBS，并且专门创建了一个并行文件系统。这里有个容易被忽略的细节：OBS 不是普通桶，并行文件系统才是给大数据场景用的，它允许 Hadoop 通过特定接口把对象存储当成文件系统挂载，从而把存储和计算解耦。报告里给出的访问域名是obs.cn-north-4.myhuaweicloud.com，双栈地址是obs.dualstack.cn-north-4.myhuaweicloud.com，这两个地址在配置 Hadoop 连接 OBS 时必须对得上，写错一个字母就是连接超时。

访问凭证来自操作完成后下载的credentials.csv，里面包含 User Name、Access Key Id、Secret Access Key 三列。报告里出现的形如"roy_yuki",S8RSFKYBTOSPA9YX92XB,...的记录就是这套凭证的样例格式。复习时要记住：AK/SK 是成对使用的，Access Key Id 相当于用户名，Secret Access Key 相当于密码，任何一端泄露都等于把桶交出去。实验里还出现了「新增 User Name、Access Key Id、Secret Access Key」的操作，说明凭证是可以按用户维度管理的，这在多节点共享存储时很关键——不要让所有节点共用一个高权限密钥。

提示：凭证文件下载后只出现一次，Secret Access Key 无法再次查看，实验过程中要第一时间保存到本地，不要留在节点上明文存放。

节点规划上，报告用了 node1 到 node4 四台机器，并在/etc/hosts里写入了固定映射，形如：

# /etc/hosts 片段，四台节点统一写入，保证主机名可解析 192.168.0.10 ecs-ca89-0001 ecs-ca89-0001 192.168.0.53 ecs-ca89-0002 ecs-ca89-0002 192.168.0.169 ecs-ca89-0003 ecs-ca89-0003 192.168.0.77 ecs-ca89-0004 ecs-ca89-0004

这段配置的作用是让集群内部用主机名互相访问，而不是记 IP。参数说明：第一列是内网地址，第二、三列是主机名与别名，四台机器必须写成完全一致的内容，否则会出现「node1 能 ping 通 node2、node2 却解析不了 node1」的单向故障。很多实验卡在启动 DataNode 时只起来一半，根因就是 hosts 没对齐。

2.2 节点互信与基础环境配置

Hadoop 集群启动时，主节点需要免密登录到所有从节点去拉起进程，所以 SSH 互信是硬门槛。报告的做法是每个节点执行cat /root/.ssh/id_rsa.pub拿到公钥，再把四台节点的公钥汇总到同一个文件里，分别写入各节点的authorized_keys。公钥内容形如ssh-rsaAAAAB3NzaC1yc2E...root@ecs-ca89-0001，注意这里公钥和注释之间没有空格是排版问题，实际写入时要保证ssh-rsa与密钥体之间有空格，否则认证直接失败。

汇总完成后，在 node1 到 node4 上分别执行ssh node1、ssh node2等命令，第一次会提示确认指纹，输入 yes 后应当无需密码直接进入。报告里明确写了「确保能够无密码跳转到目的节点」，这一步是后面所有远程分发和启动脚本的前提。复习时可以把互信检查做成一个固定动作：

# 在任意节点上批量验证互信，全部返回主机名才算通过 for n in node1 node2 node3 node4; do ssh -o BatchMode=yes $n hostname done

BatchMode=yes的作用是禁止交互式输入密码，一旦互信没配好会立刻报错而不是卡住等输入，适合用来做批量自检。基础环境还包括安装 OpenJDK 和关闭防火墙，报告里把这两步放在集群搭建之前，顺序不能反——JDK 没装好，Hadoop 的启动脚本会直接报找不到 java；防火墙没关，节点间的 RPC 端口会被拦，表现为进程起来了但互相连不上。

2.3 Hadoop 集群搭建与 wordcount 验证

环境就绪后进入正式搭建。报告在 node1 上在线下载安装包，配置完成后启动集群，最后用 hadoop wordcount 做端到端验证。wordcount 之所以成为标准验证用例，是因为它同时压到了 HDFS 读写和 MapReduce 调度两条链路：输入文件要先上传到 HDFS，Map 阶段分片读取，Reduce 阶段汇总输出，任何一环配置错误都会在作业日志里暴露出来。实验里还专门做了「测试与 OBS 互联」，也就是让 Hadoop 直接读写 OBS 上的数据，这一步是把存储层从本地磁盘换成对象存储的关键验证。

复习这个模块时，建议把「集群能起来」和「集群能算」分开看。能起来看的是进程和端口，能算看的是作业是否成功。报告里 wordcount 成功实现，说明 NameNode、DataNode、ResourceManager、NodeManager 都正常，且 OBS 的连接配置也生效了。最容易翻车的地方是 OBS 的 endpoint 和 AK/SK 写错，报错往往是一长串连接异常，看不出根因，所以要养成先单独验证 OBS 连通性、再跑作业的习惯。

3. 云服务化的大数据：BigData Pro 与 Spark 集群协同

3.1 BigData Pro 的定位与 ECS、OBS 的衔接

综合实验一引入的 BigData Pro 是一站式大数据解决方案，它的意义在于把前面手工搭的那套东西产品化。报告里的顺序是先准备云环境、购买 ECS、购买 OBS，再搭建 Hadoop 集群、搭建 Spark 集群。这个顺序说明 BigData Pro 并不是替代手工搭建，而是在同样的资源底座上把 Hadoop 和 Spark 两套计算框架组织到一起。复习时要理解三者的分工：ECS 提供算力，OBS 提供持久化存储，BigData Pro 负责把集群管理和框架集成包起来，让使用者不用每台机器手动装一遍。

这里有个容易混淆的点：实验一里 OBS 是用来给 Hadoop 做外部存储的，到了 BigData Pro 里 OBS 依然是存储底座，但角色更明确——它是集群之外独立存在的一层，计算节点可以随时增减，数据不动。这种存算分离的思路是云上大数据和传统本地集群最大的差别，也是复习时最该抓住的主线。报告里 1.2 购买 ECS、1.3 购买 OBS、1.3.1 选取对象存储服务 OBS、创建并行文件系统、创建完成进入桶，这一串步骤本质上就是在把存储层先固定下来。

3.2 Spark 集群搭建与 Hadoop 的协同关系

Spark 集群搭建排在 Hadoop 集群之后，这个顺序不是随意的。Spark 本身可以独立运行，但在大数据实验场景里，它通常依赖 Hadoop 的 HDFS 或 OBS 作为数据源，同时复用 YARN 做资源调度。报告里把 Spark 集群搭建放在「测试与 OBS 互联」之后，说明此时存储链路已经验证通过，Spark 接进来就能直接读数据。复习时要能说清楚两者的关系：Hadoop 提供存储和批处理底座，Spark 提供更快的内存计算，二者共享同一份数据，而不是各存一份。

配置 Spark 时最常改的是spark-env.sh里的环境变量，典型写法如下：

# spark-env.sh 关键项，指向已装好的 JDK 与 Hadoop 配置 export JAVA_HOME=/usr/lib/jvm/java-openjdk export HADOOP_CONF_DIR=/usr/local/hadoop/etc/hadoop export SPARK_MASTER_HOST=node1 export SPARK_WORKER_MEMORY=2g

参数说明：JAVA_HOME必须和 Hadoop 用的是同一个 JDK，版本不一致会出现类加载冲突；HADOOP_CONF_DIR让 Spark 复用 Hadoop 的 core-site 和 hdfs-site 配置，从而直接识别 OBS 的访问参数；SPARK_MASTER_HOST指定主节点，写主机名而不是 IP 更稳；SPARK_WORKER_MEMORY按实际机器内存调，设太大在实验环境里容易把节点压垮。这几项配错，表现是 Spark 能启动但提交作业时报找不到文件系统或连接被拒。

3.3 云服务化带来的复习重点变化

把实验一和综合实验一放在一起看，会发现复习重点从「怎么装」转向了「怎么连」。手工搭 Hadoop 时关注的是配置文件路径、进程是否起来；到了 BigData Pro 阶段，关注的是 ECS、OBS、Hadoop、Spark 四者之间的凭证、地址、端口是否对齐。报告里反复出现的 endpoint、AK/SK、hosts 映射，本质上都是连接信息。复习时建议把每个组件的「输入连接信息」和「输出连接信息」列成一张表，比死记命令有效得多。

注意：云服务化之后，很多配置项由平台托管，但底层仍然是同一套 Hadoop 与 Spark，实验报告里手工搭建的步骤不能跳过，否则遇到连接类报错时无从排查。

4. 交互式查询：把数据真正用起来的一步

4.1 交互式查询在整条链路中的位置

综合实验四是大数据交互式查询，报告提到可能使用 Spark SQL 或 Flink SQL 这类工具，对大规模数据做快速分析和探索，内容包括创建数据表、编写 SQL 查询、运行复杂分析任务并实时查看结果。放在整条链路里看，这一步是数据消费层——前面三章解决的是「数据存得下、算得动」，这一章解决的是「查得快、看得懂」。复习时要把交互式查询和批处理区分开：wordcount 是提交作业等结果，交互式查询是低延迟地反复试探数据，对响应时间敏感。

从技术栈看，交互式查询依赖前面搭好的 Spark 集群和 OBS 上的数据。表通常建在 OBS 路径之上，查询时由 Spark SQL 解析成执行计划，再分发到集群执行。报告里没有给出具体 SQL，但复习时可以按「建表 → 导入 → 查询 → 验证」四步来准备，建表时要指定存储路径和格式，导入时确认数据确实落在 OBS 上，查询时先用简单聚合验证连通，再上复杂分析。

4.2 查询实验的复习抓手

交互式查询最容易出问题的地方不在 SQL 语法，而在元数据和权限。表建在 OBS 上时，Spark 需要能读到对应路径，AK/SK 或委托权限没配好，查询会报权限拒绝而不是语法错误。另一个抓手是数据格式，报告没有展开，但复习时要清楚：文本格式易读但慢，列式格式适合分析型查询，实验环境里通常先用简单格式跑通，再考虑优化。把这两点抓住，交互式查询这一章就不会只剩「跑过一条 SQL」的印象。

5. 易错点排查：四个实验里最容易翻车的地方

5.1 凭证与地址类错误

易漏点一：AK/SK 与 endpoint 不匹配。为什么漏——凭证是从credentials.csv里抄的，地址是从桶页面看的，两处来源不同，抄错一位很难肉眼发现。怎么补——把 endpoint、AK、SK 三项写进一个临时配置文件，先用最简单的命令验证连通，再往 Hadoop 或 Spark 里填。

易漏点二：hosts 映射四台机器不一致。为什么漏——每台机器单独编辑，容易漏行或写错别名。怎么补——在一台机器上写好完整内容，用 scp 分发到其余节点，分发后逐台cat确认。

5.2 互信与防火墙类错误

易漏点三：公钥汇总时格式被破坏。为什么漏——复制粘贴时换行或空格丢失，ssh-rsa和密钥体粘在一起。怎么补——用ssh-keygen -l -f校验每个公钥文件，格式不对会直接报错，比等到登录失败再查快得多。

易漏点四：防火墙关了但安全组没放行。为什么漏——实验报告强调关闭节点内防火墙，容易以为网络全通。怎么补——云上还有一层安全组规则，节点间 RPC 端口要在安全组里放行，排查时先看安全组再看系统防火墙。

5.3 集群协同类错误

易漏点五：Spark 与 Hadoop 的 JDK 版本不一致。为什么漏——两套环境分开安装，各自用了不同的 OpenJDK。怎么补——统一JAVA_HOME，在 Spark 提交作业前先echo $JAVA_HOME和 Hadoop 节点对比，不一致就改spark-env.sh。

6. 复习清单：按链路自检而不是按命令背

复习这份实验报告，最有效的方式不是把命令从头敲一遍，而是按「资源 → 存储 → 集群 → 查询」四条链路做自检。下面这张表可以直接当查漏补缺的清单用，每一行对应一个必须能独立说清楚的点，说不清就回到对应章节补。

这张表的使用方法是逐行过，任何一行卡住就停下来定位，不要跳过去继续往下做，因为后面的环节都依赖前面的连通性。梳理下来会发现，四个实验真正难的不是某个命令，而是连接信息的对齐——endpoint、AK/SK、hosts、JAVA_HOME 这几项只要有一处不一致，表现出的报错往往和根因隔了好几层，这也是血泪经验里最常见的一类翻车。

从那以后我每次做这类云上集群实验，都会在动手前先把连接信息表填完，跑完一个环节就回到表里打勾，而不是等最后一起验证。这个习惯让我少走了很多「进程都起着但就是算不出结果」的弯路。希望这份梳理能帮到你，把四个实验当成一条链路来复习，而不是四份互不相干的报告。

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