企业官网建设流程全解析

简介：这份华为云大数据实验报告面向高校大数据、云计算相关课程的学习者与实验备考学生，围绕在华为云上部署和管理大数据平台的关键技术展开，帮助读者打通从云主机到云服务、再到一站式大数据方案的实践链路。压缩包内为1个docx文档，约4.36MB，按实验模块组织，涵盖云主机实现大数据、云服务实现大数据、BigData Pro综合实验以及大数据交互式查询四部分内容。文档中既有Hadoop集群搭建、节点SSH互通、OBS对象存储配置与互联测试等基础操作，也涉及Spark集群部署、Spark SQL与Flink SQL交互式查询等进阶环节，目录层级清晰，便于按实验进度检索对照。目前已有2490人学习下载，适合需要完成课程实验、复盘云上大数据环境搭建流程或查漏补缺的读者参考使用。

1. 从四台 ECS 到能跑 WordCount 的集群：这份实验报告到底能帮你省掉哪些弯路

如果你正在搜“华为云大数据实验报告”，大概率不是想读一篇云服务科普，而是手里有个课程设计、实训任务或者自学计划，卡在“四台机器怎么连起来、Hadoop 怎么装、OBS 怎么接”这些具体动作上。这份报告的价值就在这里：它把弹性云服务器 ECS、对象存储 OBS、Hadoop 集群、Spark 集群和交互式查询串成了一条完整的动手链路，从买机器、配密钥、改 hosts、做免密，一直走到提交 WordCount 任务看到输出。适合两类人：一类是第一次在云上搭集群、需要一份能照着敲的流程参考的新手；另一类是做过本地伪分布式、但没碰过“多节点 + 对象存储”组合的熟手。需要先说明的是，报告里出现的访问密钥、IP、主机名都属于实验环境的一次性配置，你复现时必须换成自己账号下的资源，不能直接照抄。

2. 云主机与 OBS 的前置配置：先把地基打对再谈集群

很多人搭集群失败，不是 Hadoop 配错了，而是前置资源就没准备好——ECS 之间网络不通、OBS 桶建错区域、AK/SK 拿错。这一章把报告里“准备环境”的部分拆开讲清楚，因为后面所有步骤都依赖这里的正确性。

2.1 ECS 选型与四节点规划

报告用的是四台节点，命名 node1 到 node4，其中 node1 兼作主节点。这个规模对教学和轻量实验刚好够用：一台 NameNode + ResourceManager，其余做 DataNode + NodeManager，既能体现分布式角色分工，又不会因为机器太多把预算和排错复杂度拉满。

选型上有几个参数值得说清楚。操作系统建议统一用同一镜像，避免不同发行版之间包管理器和默认路径不一致；规格上，教学场景 2 核 4G 起步，如果要在上面跑 Spark 任务，内存给到 8G 更稳，否则容易在 shuffle 阶段被 OOM 打断。四台机器必须放在同一个虚拟私有云和同一个子网内，这是内网互通的前提，跨子网虽然也能通，但安全组规则会多一层排查成本。

购买时还有一步容易被忽略：安全组。报告里明确写了“关闭防火墙”，这在实验环境里是为了省事，但更规范的做法是在安全组里按需放行端口，而不是直接把系统防火墙全关。我的建议是实验阶段可以按报告来，但心里要清楚这是教学简化，生产环境不能这么干。

机器起来之后，第一件事是确认每台的内网 IP，并统一写进/etc/hosts。报告里给出的是一组 192.168 段的内网地址映射到主机名，这个动作看似简单，却是后面免密登录和集群通信的基础。主机名和 IP 的对应关系一旦写错，后面 ssh 会时通时不通，非常折磨人。

# 在四台节点上分别执行，写入统一的主机名映射 # 注意：这里的 IP 必须换成你自己 ECS 的内网地址 cat >> /etc/hosts <<'EOF' 192.168.0.10 node1 192.168.0.53 node2 192.168.0.169 node3 192.168.0.77 node4 EOF # 验证解析是否生效，四台都要能 ping 通彼此的主机名 ping -c 2 node2

这段的核心是“统一”——四台机器的 hosts 文件内容必须完全一致，否则 node1 认识的 node2 和 node3 认识的 node2 可能指向不同地址。参数上唯一要改的就是 IP 段，其余主机名保持 node1 到 node4 的约定即可。执行完用 ping 验证，能通说明解析和网络都没问题，不通就先查安全组和子网，别急着往下走。

2.2 OBS 桶创建与 AK/SK 的正确拿法

报告里 OBS 部分出现了桶的访问域名和一组访问密钥，这里要讲清楚的是“怎么拿自己的密钥”而不是照抄。OBS 作为对象存储，在 Hadoop 生态里通常通过 S3A 或华为云提供的连接器接入，用来做数据落地和跨集群共享，实验里“测试与 OBS 互联”就是验证这条链路。

创建桶时有两个参数要盯住：区域和桶名。区域必须和 ECS 所在区域一致，否则内网访问会绕公网，速度和费用都不对；桶名全局唯一，建完记下来。访问密钥在控制台的“我的凭证”里创建，下载得到的 credentials.csv 里包含 User Name、Access Key Id 和 Secret Access Key 三列，报告里展示的就是这个文件的内容。

提示：AK/SK 等同于账号密码，实验报告里贴出来的密钥在真实环境必须视为已泄露并立即删除重建，任何情况下都不要把明文密钥提交到代码仓库。

拿到密钥后，建议先在 ECS 上用命令行工具做一次连通性验证，确认桶能列出来，再往 Hadoop 配置里填。这样出问题时能快速定位是密钥问题还是 Hadoop 配置问题。

# 配置访问密钥（交互式输入，避免密钥落到命令历史里） # 这里以常见的对象存储命令行工具为例，具体命令名以你环境里的工具为准 obsutil config -i=<你的AK> -k=<你的SK> -e=obs.cn-north-4.myhuaweicloud.com # 列出桶，验证密钥和网络是否正常 obsutil ls

参数说明：-i是 Access Key Id，-k是 Secret Access Key，-e是 OBS 的终端节点，必须和你桶所在区域匹配。如果ls报鉴权失败，先核对密钥有没有多余空格；如果报连接超时，查安全组出方向和终端节点地址。这一步通了，后面 Hadoop 接 OBS 才有意义。

2.3 节点免密登录：别在复制公钥这一步翻车

报告里大段内容是四台节点的公钥，然后“复制进入后保存退出”。免密登录的原理很简单：每台机器生成自己的密钥对，把公钥追加到所有节点（包括自己）的authorized_keys里。但实操里翻车点不少，最常见的是权限问题——.ssh目录必须是 700，authorized_keys必须是 600，权限不对 ssh 会直接拒绝。

# 四台节点分别执行：生成密钥对，一路回车即可 ssh-keygen -t rsa -b 2048 -N '' -f /root/.ssh/id_rsa # 把本机公钥分发到四台节点（需要先手动输入一次密码） for host in node1 node2 node3 node4; do ssh-copy-id -i /root/.ssh/id_rsa.pub root@$host done # 修正权限，这一步不做后面大概率连不上 chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys

逻辑说明：ssh-keygen的-N ''表示空密码，方便脚本化；ssh-copy-id会自动把公钥追加到目标机的 authorized_keys，比手动 cat 更不容易出错。四台都执行完后，从 node1 依次ssh node2、ssh node3、ssh node4，第一次会提示确认指纹，输入 yes 之后应该直接进 shell 不再要密码。如果还要密码，按顺序查：authorized_keys 权限、.ssh目录权限、SELinux 是否拦截、目标机 sshd 是否允许公钥认证。

3. Hadoop 与 Spark 集群搭建：从装包到跑通 WordCount

前置通了，这一章进入正题。报告里 Hadoop 集群搭建占了最大篇幅，Spark 集群单独一节，交互式查询放在综合实验四。我按“装环境 → 配 Hadoop → 验 OBS → 上 Spark”的顺序拆，每一步给出可抄的命令和该盯的参数。

3.1 OpenJDK 安装与防火墙处理

Hadoop 和 Spark 都跑在 JVM 上，JDK 是第一个依赖。报告里写的是在线下载安装 OpenJDK，四台节点都要装，版本要统一。用包管理器装最省事，装完用java -version确认，并把JAVA_HOME写进环境变量，因为 Hadoop 的启动脚本会读这个变量。

# 四台节点分别执行 yum install -y java-1.8.0-openjdk-devel # 确认安装路径，不同发行版路径可能不同 readlink -f $(which java) # 写入环境变量，路径以上一步输出为准去掉 /bin/java cat >> /etc/profile <<'EOF' export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk export PATH=$JAVA_HOME/bin:$PATH EOF source /etc/profile java -version

参数说明：装-devel包是因为编译和部分工具需要头文件；JAVA_HOME必须指向 JDK 根目录而不是 bin 目录，写错会导致 Hadoop 启动时报“JAVA_HOME is not set”。防火墙按报告关闭，命令是systemctl stop firewalld && systemctl disable firewalld，实验环境可以这么做，但要记住这是为了减少变量，不是最佳实践。

3.2 Hadoop 配置文件逐项改

Hadoop 的配置集中在etc/hadoop下的几个 XML 文件。报告没有逐行列配置，但要让四节点集群跑起来，核心是改core-site.xml、hdfs-site.xml、yarn-site.xml和workers。下面给出一份最小可用配置，参数值按四节点、副本数 2 来设。

<!-- core-site.xml：指定 HDFS 的默认访问入口 --> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://node1:9000</value> </property> </configuration> <!-- hdfs-site.xml：副本数设为 2，四节点教学环境够用且省空间 --> <configuration> <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/data/hadoop/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/data/hadoop/data</value> </property> </configuration>

逻辑说明：fs.defaultFS指向 node1 的 9000 端口，所有客户端都通过它找 NameNode；副本数设 2 而不是默认 3，是因为四台机器里 node1 还要跑其他角色，留点余量。name.dir和data.dir指向独立数据盘目录，避免和系统盘混在一起，实验里用/data即可，记得提前mkdir -p并确认磁盘空间。

workers文件（老版本叫 slaves）列出所有 DataNode 主机名，每行一个：node1 到 node4。yarn-site.xml里至少要配yarn.resourcemanager.hostname为 node1，以及 NodeManager 的辅助服务，否则 WordCount 提交后会卡在资源分配。

配完后在 node1 上格式化 NameNode，然后启动。格式化只能做一次，重复格式化会导致 DataNode 的 clusterID 和 NameNode 对不上，这是新手高频翻车点。

# 只在 node1 执行，且只执行一次 hdfs namenode -format # 启动 HDFS 和 YARN start-dfs.sh start-yarn.sh # 验证进程：node1 应有 NameNode 和 ResourceManager jps

jps在 node1 上应该看到 NameNode、ResourceManager、SecondaryNameNode，其余节点看到 DataNode 和 NodeManager。少进程就去看对应日志，日志在logs目录下，按进程名找.log文件，报错通常很直白。

3.3 测试与 OBS 互联

报告里“测试与 OBS 互联”是实验一和综合实验一的衔接点。做法是在 Hadoop 的core-site.xml里增加 OBS 的连接配置，把 AK/SK、终端节点、桶名填进去，然后用hadoop fs -ls访问obs://你的桶名/验证。这一步的意义是把计算和存储解耦：数据放 OBS，集群只负责算，机器可以随时释放。

配置时注意密钥不要写死在 XML 里提交到公开仓库，实验环境图方便可以，但要有意识。验证命令很简单，能列出桶内对象就说明链路通了；报No FileSystem for scheme说明连接器 jar 没放到 classpath，报鉴权错误则回到 2.2 节重新核对密钥。

3.4 Spark 集群与交互式查询

Spark 集群搭建在报告里是独立一节，核心是让 Spark 认识 Hadoop 的配置。常见做法是把 Hadoop 的core-site.xml和hdfs-site.xml复制或软链到 Spark 的conf目录，再配spark-env.sh里的HADOOP_CONF_DIR。这样 Spark 读写 HDFS 和 OBS 时能复用同一套配置，不用重复填密钥。

# 在 Spark 的 conf 目录下建立软链，避免配置漂移 ln -s /opt/hadoop/etc/hadoop/core-site.xml $SPARK_HOME/conf/core-site.xml ln -s /opt/hadoop/etc/hadoop/hdfs-site.xml $SPARK_HOME/conf/hdfs-site.xml # spark-env.sh 中指定 Hadoop 配置目录 echo 'export HADOOP_CONF_DIR=/opt/hadoop/etc/hadoop' >> $SPARK_HOME/conf/spark-env.sh

综合实验四的交互式查询，落到操作上就是用 Spark SQL 建表、跑查询。数据可以先放 OBS 或 HDFS，用spark-sql或spark-shell进入交互环境，建外部表指向数据路径，然后写 SQL 做聚合。这一步验证的是整条链路：存储能读、计算能跑、结果能出。查询慢的时候先看是不是数据倾斜，再看分区数，别一上来就加资源。

4. 避坑与排查：这几处翻车我见得太多了

4.1 免密登录配了但还是输密码

现象：ssh node2仍然提示输入密码。原因通常是权限不对或公钥没追加成功。解决：检查/root/.ssh是否为 700、authorized_keys是否为 600，用ssh -v node2看认证过程卡在哪一步，日志里会明确写“bad permissions”或“no such identity”。

4.2 重复格式化导致 DataNode 起不来

现象：jps里没有 DataNode，日志报 clusterID 不一致。原因：NameNode 格式化了多次，DataNode 记录的 clusterID 和新的对不上。解决：清空所有节点的dfs.datanode.data.dir目录后重新启动，或者只在首次部署时格式化一次并养成习惯。

4.3 OBS 连接报 scheme 不支持

现象：hadoop fs -ls obs://bucket/报No FileSystem for scheme "obs"。原因：OBS 连接器 jar 没放进 Hadoop 的 classpath。解决：把对应版本的连接器 jar 放到$HADOOP_HOME/share/hadoop/common/lib/下，重启相关进程，确认 jar 版本和 Hadoop 版本匹配。

4.4 WordCount 卡在 ACCEPTED 不动

现象：任务提交后一直 ACCEPTED，不进入 RUNNING。原因：YARN 资源不足或 NodeManager 没注册上。解决：看 ResourceManager 页面确认节点数，检查yarn-site.xml里 ResourceManager 主机名是否写对，以及各节点 NodeManager 进程是否在。

4.5 主机名解析时通时不通

现象：有时能 ssh，有时超时。原因：hosts 文件四台不一致，或某台机器改过主机名没同步。解决：四台cat /etc/hosts逐行比对，确保完全一致，改完用getent hosts node2验证解析结果。

5. 把实验报告变成可复用模板：我的验证习惯

这份报告最大的用处不是让你抄一遍配置，而是给你一条已经验证过的路径，你可以把它固化成自己的检查清单。我的习惯是每搭完一个集群，按“网络 → 免密 → 进程 → 存储 → 计算”五层各跑一条验证命令，全部通过再往下走，任何一层失败就停在那里查，绝不带着问题叠加配置。

具体做法是写一个自检脚本，放在 node1 上，每次重建环境先跑一遍。下面这个脚本覆盖了最关键的几项，输出全绿再开始装 Hadoop。

#!/bin/bash # 集群前置自检：网络、解析、免密、时间同步 for host in node1 node2 node3 node4; do # 1. 主机名解析 getent hosts $host >/dev/null || echo "FAIL: $host 解析失败" # 2. 免密登录（BatchMode 禁止交互，超时 5 秒） ssh -o BatchMode=yes -o ConnectTimeout=5 $host true \ || echo "FAIL: $host 免密失败" done # 3. 时间偏差，集群节点时间差过大会导致认证和任务异常 for host in node2 node3 node4; do ssh $host date +%s | xargs -I{} echo "$host 时间戳 {}" done date +%s

逻辑说明：BatchMode=yes让 ssh 在需要密码时直接失败而不是挂起，适合脚本化检测；时间戳对比是为了发现节点间时钟漂移，偏差超过几十秒就可能出问题。这个脚本不复杂，但能挡掉大部分“莫名其妙”的故障。

还有一个习惯值得分享：每次改完配置文件，先diff一下四台机器的同名文件，确认没有漏同步。Hadoop 的很多问题本质是“配置不一致”，而不是“配置错误”。另外，实验报告里的密钥、IP、主机名都是环境相关的，复现时建议单独维护一份env.sh存这些变量，脚本里引用变量而不是硬编码，换环境时只改一个文件。

从那以后我每次重建集群，都强制先跑一遍自检脚本再动手装组件，省下的排错时间远比写脚本的几分钟多。希望帮到你。

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