企业官网建设流程全解析

简介：一份华为云大数据实验报告，围绕云主机与云服务两大路径，完整覆盖实验一（云主机实现大数据）、实验二（云服务实现大数据）、综合实验一（BigData Pro）与综合实验四（大数据交互式查询），面向高校大数据课程、云计算实训及毕业设计等场景。报告以弹性云服务器ECS、对象存储OBS为基础，详细记录了购买ECS、创建OBS、配置访问密钥、安装OpenJDK、关闭防火墙、SSH免密登录、Hadoop集群搭建、Spark环境配置及SQL交互式查询等关键操作，适合正在学习华为云大数据部署或需要完成类似课程设计的读者参考。压缩包内含1个docx文档（共4.36MB），文字流程与命令说明清晰，目录结构完整，可直接对照实验步骤复现。目前已有2448人学习下载，实用性得到较多关注。通过这份报告，读者可以快速梳理从购买云资源到搭建Hadoop/Spark集群、再到交互式查询的完整链路，掌握云上大数据平台的实操要点，为独立完成实验或解决部署问题提供有效借鉴。

1. 从头搭一套华为云大数据环境：这份实验报告替你趟平了多数暗坑

做华为云大数据相关实验，最耗时间的往往不是 Hadoop 参数本身，而是环境：四台 ECS 要在一个内网里互通、每台机器都要配 SSH 互信、OBS 桶要拿到能用的 AK/SK、防火墙和安全组还得同步放行。我有一次按教程硬搭，结果卡在 SSH 公钥分发上，一个下午全耗在 Permission denied 上。这份「华为云大数据实验报告」把云主机实验、云服务实验、BigData Pro 和交互式查询四条链路串在了一起，从买 ECS 建 OBS 桶开始，到 Hadoop 集群、Spark集群、最后跑 SQL 查询，每一步都有对应命令。它适合两类人：一类是正在做云计算或大数据课设、需要一份能照着敲的实验流程的学生；另一类是刚接触公有云、想把 Hadoop 集群从本地虚拟机迁到云上的运维开发。它解决的核心问题就是：别让环境配置挡住你学大数据。

2. 云主机实验：从 ECS 和 OBS 准备到四节点 Hadoop 集群

这份报告里第一个实验的核心动作，是把原本在本地虚拟机做的事搬到云主机上：开四台 ECS 当集群节点、开一个 OBS 桶存数据、装 JDK 和 Hadoop、配好节点互信。

2.1 买 ECS 和 OBS 桶：先规划再下单，省掉后面改配置的麻烦

原文第一步就是购买弹性云服务器 ECS 和对象存储 OBS。这里容易犯的第一个错误，是买 ECS 的时候不规划内网 IP，导致四台机器不在同一个 VPC 网段，后面 hosts 怎么配都连不通。我一般会按下面这张表提前列好节点角色：

规格上实验环境不用贪大，4C8G 足够跑 wordcount 和 Spark SQL。选系统盘的时候建议做到 40G 以上，因为 Hadoop 的日志和数据目录默认都写在本地盘，空间小了跑两天就满。

OBS 桶的购买则注意一个细节：实验二和综合实验用的是「并行文件系统」而不是普通 OBS 桶。并行文件系统在 HDFS 语义兼容上做得更好，Hadoop 可以直接把它当文件系统挂载。购买时选好区域后，记录下访问域名，典型的地址格式是obs.<region>.myhuaweicloud.com，后面配fs.obs.endpoint时要用。

2.2 配置 hosts 和 SSH 互信：四台节点必须能免密互跳

集群搭建前先改/etc/hosts，这个文件四台节点都要改，内容保持一致。我在 node1 上执行：

cat >> /etc/hosts <<EOF 192.168.0.10 ecs-node01 node1 192.168.0.53 ecs-node02 node2 192.168.0.169 ecs-node03 node3 192.168.0.77 ecs-node04 node4 EOF

这里把主机名、短名都映射上，是因为 Hadoop 的配置里有时写短名、有时写全名，统一之后能避免 NameNode 解析节点时找不到主机。

接着用ssh-keygen生成密钥对：

ssh-keygen -t rsa -b 4096 -N "" -f /root/.ssh/id_rsa

-N ""表示空密码，-f指定生成路径。生成后把公钥收集到每台节点的authorized_keys里，常见做法是像报告里那样，在每个节点执行cat /root/.ssh/id_rsa.pub，把内容复制到其余三台机器的/root/.ssh/authorized_keys中。手动复制容易漏文件，我更习惯用ssh-copy-id：

ssh-copy-id -i /root/.ssh/id_rsa.pub node2 ssh-copy-id -i /root/.ssh/id_rsa.pub node3 ssh-copy-id -i /root/.ssh/id_rsa.pub node4

复制完成后，在 node1 上依次执行ssh node2、ssh node3、ssh node4，第一次会提示确认指纹，输入 yes 后如果不再要求输密码，互信就通了。这里有个判断技巧：如果ssh node2直接卡住不提示密码也不提示指纹，大概率是/etc/hosts解析错了，先ping node2看通不通。

2.3 安装 OpenJDK、关防火墙、初始化 Hadoop

每台节点都要装 JDK，Hadoop 3.x 要求 JDK 8 以上。在线下载包或者直接yum install -y java-1.8.0-openjdk都行，装完用java -version验证。

防火墙是集群搭建里最常见的拦路虎。我一般直接在每台节点执行：

systemctl stop firewalld systemctl disable firewalld systemctl status firewalld

实验环境可以直接关闭，生产环境不建议这么干，应该放行 8020、9870、8088 等端口，后续章节会提到安全组放行规则。

Hadoop 解压到/opt/hadoop后，需要改四个配置文件。core-site.xml里指定 NameNode 地址和 OBS 相关属性：

<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://node1:8020</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/data/hadoop/tmp</value> </property> </configuration>

hdfs-site.xml设置副本数和 NameNode 数据目录：

<configuration> <property> <name>dfs.replication</name> <value>3</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/data/hadoop/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/data/hadoop/datanode</value> </property> </configuration>

副本数设 3 是因为有四台 DataNode，能完整模拟生产冗余。dfs.namenode.name.dir和dfs.datanode.data.dir是元数据和数据块的落地目录，一定要建好，否则格式化时报目录不存在。

配置完成后，首次启动前要格式化 NameNode，格式化是一锤子买卖，执行一次以后不要再跑，否则集群元数据清空会直接起不来：

hdfs namenode -format

格式化完成后，在 node1 上启动 HDFS，在 node2~node4 上确认 DataNode 已经注册。用jps看进程是最快的验证方式：node1 上应该有 NameNode 和 SecondaryNameNode，其余节点有 DataNode。报告里在最后跑了 Hadoop wordcount 验证，这一步用到hadoop jar提交一个自带示例，能跑出统计结果就说明集群链路完全通了。

3. 云服务实验与 BigData Pro：把 OBS 变成 Hadoop 的「外接硬盘」

第二个实验和综合实验一侧重点不一样：前者强调用云服务收数据，后者强调 BigData Pro 的一站式环境。两者共同的落点，是 Hadoop 集群与 OBS 的连通。

3.1 获取 AK/SK：credentials.csv 是你访问 OBS 的唯一凭证

OBS 的认证不依赖 ECS 的内网互通，它走的是 AK/SK 签名。在控制台里创建用户后，会生成一个credentials.csv文件，里面有 Access Key Id 和 Secret Access Key 两列。这份文件只出现一次，下载后要立刻保存。

很多人在这个环节把密钥配错，症状是 Hadoop 访问obs://路径时报 AccessDenied。注意报告里后来出现的访问密钥是S8RS...这一组，和前面创建用户时看到的信息可能不同，用的时候要用当前有效的那份，不要从旧截图里抄。

拿到 AK/SK 后，把它们写进 Hadoop 的core-site.xml：

<property> <name>fs.obs.access.key</name> <value>你的AccessKeyId</value> </property> <property> <name>fs.obs.secret.key</name> <value>你的SecretAccessKey</value> </property> <property> <name>fs.obs.endpoint</name> <value>obs.<region>.myhuaweicloud.com</value> </property>

这里三个属性缺一不可。fs.obs.endpoint填的是对象存储服务的区域域名，必须和桶所在区域一致，跨区域访问会直接报错。如果走内网访问，还有一类地址是obs.dualstack.<region>.myhuaweicloud.com，双栈域名同时支持 IPv4 和 IPv6，实验环境用哪个都行，只要和 endpoint 保持一致。

3.2 Hadoop 挂载并行文件系统：从 HDFS 目录看到 OBS 里的对象

OBS 与 Hadoop 的互联需要配套的 JAR 包。常见的做法是把hadoop-huaweicloud相关的依赖包放到 Hadoop 的lib目录下，然后在core-site.xml里启用 OBS 文件系统实现：

# 解压后复制到 Hadoop 的 lib 目录 cp hadoop-huaweicloud-*.jar $HADOOP_HOME/share/hadoop/common/lib/ cp esdk-obs-java-*.jar $HADOOP_HOME/share/hadoop/common/lib/

复制完要重启 HDFS 才能生效。验证是否连通，直接列桶内容：

hdfs dfs -ls obs://你的桶名/

如果能正常列出目录结构，说明 Hadoop 已经把 OBS 当成底层文件系统了。这里要确认你在 OBS 控制台建的是「并行文件系统」而不是「对象存储桶」，两者的协议细节不同，并行文件系统对 HDFS 的rename和mkdir操作兼容得更好，普通 OBS 桶在跑 Spark 写临时文件时容易出现目录操作不支持的问题。

3.3 Spark 集群搭建：环境变量和 Worker 注册是关键

综合实验里 Hadoop 搭完接着搭 Spark。Spark 不负责存储，它依赖 HDFS 或 OBS 读数据，所以 Spark 安装包的节点和 Hadoop 节点是同一批。安装包解压后，改spark-env.sh：

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_HOME=/opt/hadoop export SPARK_MASTER_HOST=node1 export SPARK_WORKER_CORES=2 export SPARK_WORKER_MEMORY=4g

然后在slaves文件里写上 worker 节点：

node2 node3 node4

SPARK_MASTER_HOST必须写 node1 的地址，写 localhost 会导致外部节点注册失败。启动后用jps检查，node1 有 Master 进程，node2~node4 有 Worker 进程，Spark 才算真正起来。我一般还会跑一个 Pi 示例验证调度：

$SPARK_HOME/bin/spark-submit --class org.apache.spark.examples.SparkPi \ --master spark://node1:7077 \ $SPARK_HOME/examples/jars/spark-examples_*.jar 10

能正常输出 Pi 的近似值，说明 worker 资源已经能被 Master 调度，集群就绪了。

4. 大数据交互式查询：Spark SQL 从建表到出结果的完整链路

综合实验四做的是交互式查询，这和大数据平台「存下来之后怎么用」直接相关。实验里没有锁定具体引擎，但按报告语境和常见实现，Spark SQL 是最顺的选择。

4.1 为什么交互式查询选 Spark SQL 而不是 Hive

Hive 和 Spark SQL 都能跑 SQL，但它们的执行模型不同。Hive 默认把 SQL 翻译成 MapReduce 作业，跑一个小查询要经历完整的 map 和 reduce 阶段；Spark SQL 基于内存计算，对交互式探索更友好。实验场景是「创建数据表、编写 SQL、实时查看结果」，用 Spark SQL 省去了 Hive 单独维护 Metastore 的负担，还能直接复用已经搭好的 Spark 集群。

4.2 建表加载 OBS 数据：外部表和内部表的取舍

在spark-sql交互式命令行里，第一步是建表。表数据放在 OBS 上时，用外部表更合理，因为删除表不会把 OBS 里的原始文件删掉：

CREATE EXTERNAL TABLE IF NOT EXISTS user_log ( user_id STRING, action STRING, event_time TIMESTAMP ) USING csv OPTIONS ( path 'obs://你的桶名/user_log', header 'true' );

USING csv指定文件格式，OPTIONS里的path指向 OBS 路径，header指定 CSV 首行是否为表头。外部表的好处是元数据与数据分离，同一份 OBS 数据可以建多张表从不同角度分析。加载完数据后用SELECT COUNT(*) FROM user_log验证，能返回行数就说明 OBS 上的文件已经被正确解析。

建表时有一个容易忽略的点：如果 CSV 里的时间字段是字符串，直接查没问题，但要做时间过滤就最好在建表时转成 Timestamp 类型。否则每次过滤都要对字符串做隐式转换，查询会慢不少。

4.3 跑聚合查询：看 Stage 和 Shuffle 判断资源消耗

交互式查询的典型操作是按某个维度聚合，比如统计每种 action 的数量：

SELECT action, COUNT(*) AS cnt FROM user_log GROUP BY action ORDER BY cnt DESC;

在 Spark Web UI 的 SQL 标签页里可以看到这个查询拆成了哪几个 Stage。GROUP BY需要把相同 key 的数据汇聚到同一个 executor，中间会产生 Shuffle，Shuffle 数据量过大时查询会变慢。日常调优我会关注两个参数：

SET spark.sql.shuffle.partitions = 40;

默认值是 200，对实验环境的小数据量来说反而浪费调度资源，调到 40 可以减少空任务。如果查询连的是外部数据源，共享 Metastore 的话还能支持多引擎同时查同一张表，不过这需要额外部署 Hive Metastore，实验阶段不折腾。

5. 常见问题排查：做这套实验我踩过的四个真实坑

这套实验的难点不在概念，而在环境。下面按现象、原因、解决三个层次，把最容易卡住人的四个问题列出来。

5.1 SSH 互信配好了，ssh node2 还是要密码

先确认所有节点的/root/.ssh目录权限。我遇到过authorized_keys权限是 644 的情况，SSH 出于安全策略会拒绝使用权限过宽的文件，表现为免密失效但不报明确错误。解决方法是：

chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys

另外注意每台节点的公钥文件是否真的追加进了对应节点的authorized_keys，而不是只写进了 node1。常见原因是没有把 node1 的公钥分发给 node2~node4，只做了单向免密。

5.2 节点间连接被拒，HDFS 起不来

现象是start-dfs.sh之后，NameNode 进程存在，但 DataNode 一直连不上。排查时先在 node1 上ping node2，能通再telnet node2 8020看端口通不通。这类问题一半出在没关防火墙，一半出在 ECS 安全组没放行内网端口。

实验环境省事做法是直接关掉系统防火墙，但云上的安全组策略仍然生效。需要在 ECS 控制台的安全组里，对四台机器的内网网段放行全部端口。如果只放行公网 IP 访问，内网节点之间照样不通。安全组放行规则可以这样配：

5.3 访问 OBS 报 403 AccessDenied

这种情况几乎都是 AK/SK 或 endpoint 不匹配。core-site.xml里fs.obs.endpoint的 region 必须和 OBS 桶所在 region 一致；密钥必须是当前有效的，不能使用已删除或禁用的访问密钥。另外credentials.csv下载后可能被重复使用，如果之前重置过密钥，旧的就没用了。

解决方法是重新回到控制台下载最新的credentials.csv，把fs.obs.access.key和fs.obs.secret.key的值替换掉，然后重启相关服务。排查时可以在任意一台节点上用命令行工具直接测试 AK/SK 是否有效，比如用 Python 的 OBS SDK 列桶，能列出来说明密钥没问题，问题出在 Hadoop 侧的配置。

5.4 hosts 文件配置不一致，NameNode 不识别节点

现象是 SSH 能跳转，但 HDFS 报UnknownHostException或节点名解析错误。原因通常是有某台节点的/etc/hosts少写了映射，或者把主机名对应的 IP 写成了公网 IP。

解决方法是把四台节点的/etc/hosts统一成同一份，内网 IP 对应的短名和全名都写全。改完后用hostname -i确认每台机器解析出来的 IP 是内网地址，而不是 127.0.0.1。一个小技巧是配置完 hosts 后，在所有节点执行一次ssh node1、ssh node2、ssh node3、ssh node4，把 SSH 指纹全部写入 known_hosts，避免运行时首次连接等待确认。

6. 验证集群是否真能用：快速自检流程与资源收尾技巧

集群搭完不能只看进程在跑，要按固定顺序验证一遍，我习惯按下面这套流程走：

第一，jps确认进程角色。node1 有 NameNode、ResourceManager，node2~node4 有 DataNode、NodeManager。Spark 节点上再确认 Master 和 Worker。

第二，检查 Web UI。NameNode 的页面默认在http://node1:9870，ResourceManager 页面在http://node1:8088。浏览器打不开时，先确认安全组是否放行了公网入方向的 9870 和 8088 端口，再看系统防火墙是否还开着。

第三，做一次真实的读写验证。用hdfs dfs -put上传一个本地文件到 HDFS，再用hdfs dfs -cat读回内容，比hdfs dfsadmin -report更能确认数据通路完好。

第四，验证 OBS 和 Spark 联动。用spark-sql跑一遍上一章的外部表查询，能出结果才算是端到端全通。

最后是关于资源的收尾。很多人做完实验直接关机走人，结果下个月账单还在扣费。ECS 关机后，云盘和公网 IP（如果绑定了弹性公网 IP 且未释放）仍然计费。做完实验的正确操作是进入 ECS 控制台，把临时实验用的机器「释放」掉，而不是「关机」；OBS 桶里的测试数据也删干净，否则对象存储按存储容量持续计费。需要保留环境时，至少要把弹性公网 IP 解绑，节省这部分费用。

从那以后，我每次搭完集群都会强制走一遍上述自检流程，再处理资源释放的事。这套实验报告最值钱的部分不是命令本身，而是它把从零到通的完整链路记录了下来——如果你也准备在华为云上跑一遍大数据实验，按这份报告的路径执行，能少踩很多我当年踩过的坑。希望帮到你。

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