大数据上云实验链路：从云主机到Hadoop与Spark SQL

简介：这份docx实验报告面向学习华为云大数据平台部署与运维的高校学生及入门工程师，围绕弹性云服务器、OBS对象存储与Hadoop/Spark集群展开，帮助读者理解云主机和云服务两种实现路径。压缩包仅含1个docx文件，大小约4.36MB，目录按实验一、实验二、综合实验一和综合实验四组织，便于按模块查阅。内容覆盖ECS与OBS配置、节点间SSH互信、OpenJDK安装、防火墙关闭、Hadoop集群搭建及与OBS互联测试，也记录BigData Pro场景下的ECS购买、OBS创建和Spark集群配置，并延伸到Spark SQL、Flink SQL等交互式查询。已有2542人学习，适合对照实验流程复盘关键配置、梳理集群搭建思路，并作为课程实验或大数据上机实践的参考材料。

1. 大数据上云这套实验，真正的骨架只有一条链路

四份实验文档摆在面前时，多数人的第一反应是“四个互不相干的任务”：云主机实现大数据、云服务实现大数据、一站式大数据平台、交互式查询。把目录顺序打乱重排一遍会发现，它们其实是同一条链路上的四段：申请算力与存储（云主机和对象存储）→ 铺集群地基（主机名、免密、JDK、防火墙、四个配置文件）→ 用一个 WordCount 和一次对象存储读写证明链路真的通了 → 最后把自建集群换成托管服务，用 SQL 做交互式分析。反直觉的地方在于，这套东西卡人的从来不是 MapReduce 的编程模型，而是主机名解析、密钥配对、端口放行这些“外围”。这份笔记按模块把散落的步骤串成一张地图，适合正在做同类课程实验、或者复习大数据上机环节的人对照自查。

2. 云资源底座：云主机、对象存储与访问密钥的配置链条

实验一和综合实验一的前半段，落到纸面上只有三行字：买云主机、买对象存储、拿访问密钥。真做起来，这三步的先后顺序和参数细节决定了后面八成以上的返工量。最省事的顺序是先定区域，再买机器和桶，最后建子用户拿密钥——因为桶和云主机不在同一区域，后面所有读写都会绕远路，甚至因为内网 endpoint 不通而直接失败。这一章把这条链条拆成三段：机器怎么选、桶怎么配、密钥怎么管。

2.1 云主机的选型与网络规划：四台节点为什么必须同规格同子网

节点规划先定下来，后面所有配置文件才有地方填。项目里是四台节点，node1 兼做主节点（NameNode、ResourceManager），node2 到 node4 做数据节点和计算节点。规格上不需要多豪华，但要满足三个硬条件：同一可用区、同一子网、系统镜像一致。同一子网是为了内网直通，安全组里可以只放行内网网段；镜像一致是为了 JDK 路径、包管理器、默认字符集完全相同，避免出现“三台能跑一台报错”的玄学问题。

只给 node1 绑公网地址，是这套实验里很实用的一条经验：四台机器全开公网，安全组规则会变成一团乱麻，而且每台都要单独记地址。把 node1 当跳板，先连它，再从它 ssh 到其余三台，内网地址固定不变，配置文件里的主机名映射也稳定。买完机器第一件事不是装软件，而是改主机名，让 hostname 和配置文件里的名字对得上：

# 每台机器各自执行，把 nodeX 换成自己的编号 hostnamectl set-hostname node1 # 立刻生效并确认，输出必须是 node1 而不是默认的一长串实例 ID hostname

hostnamectl改的是持久化配置，重启不丢；hostname只是查看当前值。很多人只执行了后者，看着像改成功了，一重启又变回默认的实例 ID，于是免密登录、Hadoop 启动全部失效。改完主机名顺手确认时间同步，四台机器时间差超过几分钟，YARN 的任务状态和日志时间戳就会错乱，排查时非常干扰判断。

2.2 对象存储：桶名、区域与 endpoint 的三元组

对象存储在这个实验里承担两件事：存放 WordCount 的输入输出数据，以及给后面托管大数据服务当数据湖底座。配的时候有三个参数必须一起记：桶名、区域、endpoint。桶名全局唯一，撞名了就换一个带前缀的名字；区域必须和云主机同区域，跨区域访问会走公网，既慢又可能产生额外流量；endpoint 通常有内网、公网、双栈几种写法，集群内部访问一律用内网地址。

# 用命令行工具做最小验证：能列出桶，说明鉴权、网络、endpoint 三者都对了 obsutil ls -limit=10 # 上传一个本地文件，确认写权限；失败时优先看返回码而不是猜网络 obsutil cp ./README.md obs://bucket-demo/input/README.md

ls只验证读权限和连通性，cp才验证写权限，两个都要跑。返回 403 一般是密钥或桶策略问题，返回超时基本是 endpoint 写成了公网地址而机器没有出网权限，返回 404 则要检查桶名和区域是否匹配。这一步花十分钟做扎实，后面 Hadoop 集群连对象存储时能省掉一整轮排查。

2.3 访问密钥：从凭据文件到环境变量的最短路径

访问密钥是一对字符串：Access Key Id 用来标识身份，Secret Access Key 用来签名。平台一般只在创建时给一次下载机会，拿到的是一个 CSV 文件，里面写着用户名、AK 和 SK 三列。这三列里，AK 可以出现在日志里问题不大，SK 一旦泄露等于把桶的读写权限交出去。

import os from obs import ObsClient # 具体包名以所用平台 SDK 为准 # 凭据一律从环境变量读，代码里不出现任何明文 ak = os.environ["CLOUD_AK"] sk = os.environ["CLOUD_SK"] endpoint = os.environ["OBS_ENDPOINT"] client = ObsClient( access_key_id=ak, secret_access_key=sk, server=endpoint, # 集群内访问必须用内网 endpoint ) resp = client.listBuckets() print(resp.status) # 200 表示鉴权与连通同时成立

环境变量在每台机器上单独 export，或者写进只读的 profile 文件并限制权限。更好的做法是建一个子用户，只授予目标桶的读写权限，而不是用主账号密钥——主账号密钥权限过大，实验里用不上，一旦写进配置文件再截图发出去，就是典型的血泪经验。梳理下来会发现，访问对象存储其实只需要凑齐四样东西：身份（AK/SK）、地址（endpoint）、目标（桶名）、权限（桶策略或子用户授权），缺一样都会以一个含糊的报错收场。

3. 集群地基：四节点互通与四个配置文件的关键项

真正决定这套集群能不能起来的，是装 Hadoop 之前的那半小时：主机名映射对不对、四台机器能不能互相免密登录、防火墙有没有放行、JDK 装没装好。这四件事任何一件没做透，后面start-dfs.sh都会以一种极其模糊的方式失败——进程起了一半、日志里只有一行 Connection refused。这一章按执行顺序把地基铺一遍。

3.1 四节点的角色划分与 hosts 映射

角色划分在买机器时就应该定好，落到配置上就是哪台写进workers文件、哪台当主节点。主机名映射写错是最高频的低级错误，因为它不一定立刻报错：ping node2能通，但通的是错的机器，集群看起来启动了，数据其实写到了别处。

# 四台机器都要写同一份映射，用内网地址，不要用公网地址 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 # 验证：每台机器上都要能解析出同一个内网地址 getent hosts node2

用getent hosts而不是ping，是因为它只查解析、不发包，输出干净、脚本里好判断。四台的/etc/hosts内容必须完全一致，改完可以用md5sum /etc/hosts在四台上对比一次。注意这里填的是内网地址，公网地址只在本地电脑连跳板机时用，两者混写是后面所有连接超时的根源。

3.2 免密互信：从生成密钥到下发授权文件的三步闭环

Hadoop 的主从架构要求主节点能免密登录到所有从节点，从节点之间在 shuffle 阶段也可能互相通信，所以最稳的做法是四台全互通，而不是只做 node1 到其余三台的单向。三步闭环：各自生成密钥对、把四份公钥汇总成一份、把汇总文件下发成每台的授权文件。

# 1) 四台各自生成密钥对，-N "" 表示不设口令，-f 指定路径 ssh-keygen -t rsa -b 2048 -N "" -f /root/.ssh/id_rsa # 2) 在 node1 上把四台的公钥收进一个临时文件 for h in node1 node2 node3 node4; do ssh $h 'cat /root/.ssh/id_rsa.pub' >> /root/.ssh/all_keys.tmp done # 3) 下发成每台的 authorized_keys，并收紧权限 for h in node1 node2 node3 node4; do ssh $h 'mkdir -p /root/.ssh && chmod 700 /root/.ssh' scp /root/.ssh/all_keys.tmp $h:/root/.ssh/authorized_keys ssh $h 'chmod 600 /root/.ssh/authorized_keys' done

-N ""省掉交互输入口令，代价是私钥文件不能泄露，实验环境可以接受。第 3 步的chmod 700和chmod 600不是可选项，SSH 对权限的要求很严格，目录是 755 或文件是 644 时它会直接拒绝认证，而且报错信息不会告诉你是权限问题。下发的是一次性覆盖，所以汇总必须在 node1 上一次做完；如果四台分别追加，容易出现公钥重复多份、顺序混乱的问题。验证方式是每台机器上ssh node1到ssh node4全部不输密码能进，第一次连接会提示确认指纹，输入 yes 之后把 known_hosts 也一并接受，别在自动化脚本里卡在这一步。

3.3 系统前置：防火墙、JDK 与时间同步

防火墙是第二高频翻车点。云平台有安全组，操作系统里还有一层防火墙，两层都开着的时候，即使安全组放行了 9870，本机防火墙也会把请求挡掉。实验环境里最省事的做法是把系统防火墙关掉，安全边界交给安全组来控制。

# 关闭并禁止开机自启，两台都要确认状态是 inactive systemctl stop firewalld systemctl disable firewalld systemctl status firewalld --no-pager # 安装 OpenJDK 并确认 java 可执行文件路径 yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel readlink -f $(which java)

最后一行输出的路径决定JAVA_HOME怎么填——要填到 jre 目录的上两级，而不是bin/java本身。这一步写错的表现是hadoop version报 “JAVA_HOME is not set”，但java -version明明正常，容易被误判成 Hadoop 包损坏。四台机器都要装、都要配，缺一台的表现是那台节点启动后立刻退出，日志里只有一行找不到 Java 运行时。

提示：改完JAVA_HOME后，用echo $JAVA_HOME和hadoop version各验证一次，两个都要有输出才算过。

3.4 四个 XML 与 workers 文件的关键项

Hadoop 的配置看着文件多，真正需要改的核心项就那么几条。剩下的大量默认值对单机伪分布式够用，对四节点小集群也基本够用，关键是别把地址和路径写错。

<!-- core-site.xml：文件系统入口 + 对象存储接入所需的三项 --> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://node1:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/hadoop/tmp</value> </property> <!-- 对象存储接入：类名与前缀以平台文档为准，这里只示意结构 --> <property> <name>fs.obs.endpoint</name> <value>obs.<region>.example.com</value> </property> </configuration>

hadoop.tmp.dir单独指到一个磁盘目录，是因为默认的/tmp在部分系统上会被定期清理，清理之后 NameNode 元数据和 DataNode 块文件就可能对不上，表现为集群启动成功但一读数据就报错。另外副本数不要超过从节点数量，四节点里 node1 也当 DataNode 的话设 3 合理，只留三台纯数据节点就设 2 或 3，设 4 会让写入一直等待副本完成而卡住。配置改完在四台上同步一遍，用scp或rsync都行，然后逐台diff确认一致——不一致的配置文件导致的问题最难查，因为报错往往出现在没有错的那台机器上。

4. 跑通链路：WordCount、对象存储读写与 Spark 交互式查询

地基铺好后，接下来全是验证动作。这一章覆盖四件事：格式化与启动顺序、WordCount 跑通、对象存储互联验证、Spark 集群与交互式查询。它们的共同点是“看起来简单但必须逐条确认”，因为每一步的成功都是下一步的前提，中途跳过一步，后面就会在一个完全无关的地方报错。

4.1 格式化与启动顺序：format 只做一次

NameNode 格式化是这套流程里唯一一个“做错了很难挽回”的动作。它只在集群第一次启动前执行一次，重复执行会让集群 ID 变化，原来 DataNode 上的块全部被判定为属于另一个集群，等于数据全丢。

# 只在首次部署时执行，输出里出现 successfully formatted 才算成功 hdfs namenode -format # 启动顺序：先 HDFS 再 YARN，最后用 jps 逐台核对进程 start-dfs.sh start-yarn.sh jps

jps是这套实验里最实用的自检命令。node1 上应该看到 NameNode、ResourceManager、SecondaryNameNode，从节点上应该看到 DataNode、NodeManager。少一个进程就去翻对应目录下的日志，而不是反复重启脚本。启动顺序上，先 HDFS 后 YARN 是因为 YARN 启动时会去读 HDFS 的状态，反过来的话 ResourceManager 可能因为连不上 NameNode 而进入重试。真要做重置，正确做法是先停集群、清空所有节点的数据目录和临时目录、再格式化一次，删目录这一步不能省。

4.2 WordCount 的三段式验证：输入、执行、读结果

WordCount 之所以是所有大数据实验的第一个例子，是因为它一次性把 HDFS 读、MapReduce 计算、YARN 调度、HDFS 写四条链路全走了一遍。所以验证要按三段来，每段都有明确的成功标志。

# 1) 输入：本地文件传进 HDFS，确认副本和路径 hdfs dfs -mkdir -p /user/wordcount/input hdfs dfs -put ./data.txt /user/wordcount/input/ hdfs dfs -ls /user/wordcount/input/ # 2) 执行：跑自带示例，输出目录必须不存在，否则会直接失败 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \ wordcount /user/wordcount/input /user/wordcount/output # 3) 读结果：先看目录结构，再看内容 hdfs dfs -ls /user/wordcount/output hdfs dfs -cat /user/wordcount/output/part-r-00000 | head -20

第 2 步的 jar 包路径用了通配符，是因为包名里带版本号，写死版本号换环境就失效。输出目录必须提前不存在，这是 Hadoop 的保护机制，防止误覆盖历史结果，所以重复跑要先hdfs dfs -rm -r删掉。第 3 步看到_SUCCESS空文件和不带下划线的part-r-00000，说明任务真的成功了；只看命令返回码不够，因为有些失败会以退出码 0 收场，结果目录里只有_SUCCESS而没有 part 文件。

4.3 与对象存储互通：验证“写得进去”，而不是“配了就行”

对象存储互联这一步，很多人卡在“配置文件写了、重启了、看起来没报错”就认为通了。真正的验证是双向的：既能把 HDFS 数据写到对象存储，也能从对象存储读回 HDFS。

# 先看能不能识别对象存储路径，能列出桶内对象说明鉴权和 endpoint 都对 hadoop fs -ls obs://bucket-demo/input/ # 双向验证：HDFS 写出去，再读回来 hadoop fs -copyFromLocal ./data.txt obs://bucket-demo/input/data.txt hadoop fs -copyToLocal obs://bucket-demo/input/data.txt ./data_back.txt diff ./data.txt ./data_back.txt && echo "round-trip ok"

URI 前缀（示例里的obs://）由平台提供的文件系统实现决定，接别的对象存储时可能是s3a://、oss://或cos://，照文档填，别照抄。失败时优先看三处：endpoint 是不是内网地址、AK/SK 有没有漏字符或多了空格、桶策略是否允许当前身份读写。diff那一步看着多余，实际能抓到编码和换行被改写的问题，尤其是 Windows 上编辑过的文本文件。

4.4 Spark 集群与交互式查询：拆成提交层和执行层来看

Spark 在这套实验里不是独立存在的，它跑在已有的 HDFS 和 YARN 之上，所以配置的核心只有一句话：让 Spark 知道 HDFS 在哪、YARN 在哪。做法是把 Hadoop 的配置目录直接指给 Spark，而不是把一堆地址重新抄一遍。

# spark-env.sh 里三个变量就够：Java、Hadoop 配置目录、本机地址 export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop export SPARK_LOCAL_IP=192.168.0.10 # 提交任务：client 模式适合调试，日志直接打在终端 spark-submit \ --master yarn \ --deploy-mode client \ --num-executors 4 \ --executor-cores 2 \ --executor-memory 2g \ /opt/spark/jobs/wordcount.py

HADOOP_CONF_DIR是关键，指对之后fs.defaultFS、YARN 地址都不用重复配置。--num-executors乘--executor-cores不能超过集群总可用核数，超了任务会一直挂在等待资源的状态；--executor-memory加上 driver 内存要小于单机可用内存，否则 NodeManager 会以超出物理内存为由杀掉容器。client和cluster的差别在于 Driver 跑在哪：调试用 client，提交机断了任务就断；交给集群长期跑用 cluster，日志要去 YARN 上捞。

交互式查询这一段，本质是把 SQL 当作查询入口，底层仍然是 Spark。建表时把位置指到对象存储，就同时在验证 SQL 引擎、元数据服务和存储三层。

-- 建一张指向对象存储的外表，location 换成自己的桶路径 CREATE TABLE IF NOT EXISTS access_log ( dt STRING, uid STRING, url STRING, status INT, bytes BIGINT ) USING parquet LOCATION 'obs://bucket-demo/warehouse/access_log'; -- 按天看状态码分布，既能验证读权限也能看出分区是否生效 SELECT dt, status, count(*) AS cnt FROM access_log WHERE dt BETWEEN '2024-01-01' AND '2024-01-07' GROUP BY dt, status ORDER BY dt, cnt DESC;

USING parquet指定文件格式，和写入端保持一致，否则会出现“表建成功但查询报 schema 不匹配”。LOCATION指向桶内目录而不是单个文件。查询时把过滤条件放在分区列上，能明显看出扫描量差异，这也是判断“外表到底有没有走到分区裁剪”的土办法。托管式大数据服务的价值在这一步体现得最清楚：自建集群时这些组件要一台台配、一个个调，托管服务里建好工作空间、挂上桶、开个 SQL 编辑器就能跑，代价是对底层参数的控制权变少。

5. 易漏易错：五个最容易翻车的点

这一章单独拎出来，是因为下面这些点几乎每个做过这套实验的人都踩过至少两个，而且它们有一个共同特征：报错信息指向的地方，往往不是真正出问题的地方。按“易漏点 → 为什么漏 → 怎么补”的结构过一遍，比事后翻日志快得多。

5.1 公网地址与内网地址混用

易漏点：本地电脑连机器用公网地址，配置文件里也顺手写了公网地址，集群内部通信全走公网。为什么漏：两种地址在控制台上并排显示，复制时很容易拿错，而且单机测试时公网地址也能通，看不出问题。怎么补：定一条硬规则——凡是写进/etc/hosts、XML 配置、连接串的，一律用内网地址；公网地址只出现在本地终端的 ssh 命令里。改完用getent hosts在四台上各确认一次。

5.2 密钥写进配置文件还同步给了所有人

易漏点：为了省事把 AK/SK 直接写进core-site.xml，然后scp同步到四台机器。为什么漏：这样确实能跑通，而且在实验环境里“反正只有自己用”。怎么补：密钥改走环境变量或独立的凭据文件，配置文件里只留路径引用；同步配置文件时用rsync --exclude把凭据文件排除掉。顺带养成习惯，截图和报告里出现密钥的位置一律打码，这不是洁癖，密钥轮换的成本远高于一开始就管好。

5.3 安全组只放了 22 端口

易漏点：能 ssh 上去就以为网络没问题，结果 9870 的管理页面打不开、8088 看不到任务、9000 连不上。为什么漏：ssh 是最先验证的一步，通过了就形成“网络已通”的错觉，而 Hadoop 用的端口是另一批。怎么补：买机器时就把端口清单一次性配好，除了 22，还要放行 HDFS 的 9000 与 9870、YARN 的 8088、以及节点间通信端口。用ss -lntp在本机看实际监听端口，用telnet node1 9870从另一台验证连通，两个命令配合基本能定位是没监听还是没放行。

5.4 版本与路径的隐性不匹配

易漏点：java -version正常但 Hadoop 起不来，或者 Spark 提交时报找不到类。为什么漏：报错只说了结果，没说原因，而版本兼容和路径引用是两件看不出因果的事。怎么补：把三件事固定下来——JDK 主版本在四台上完全一致、JAVA_HOME指到 jre 的上一级、Spark 用的 Scala 主版本与发行包匹配。hadoop version、spark-submit --version、java -version三个命令的输出存进一个文本文件，出问题时先对比这份基线。

5.5 只验证“进程起来了”，不验证“数据通不通”

易漏点：jps看到进程齐了、页面能打开，就认为实验完成。为什么漏：进程存活和链路可用是两件事，中间隔着权限、端口、配置一致性三层。怎么补：每加一个组件就配一个读写验证动作——HDFS 用put加cat，对象存储用cp加diff，Spark 用一次count()。验证要能看见数据，而不是看见状态。这条习惯的价值在后面做托管服务和交互式查询时会成倍放大，因为那时候连进程都看不见了，只剩数据能证明一切正常。

6. 复习清单：把四个实验压成一张自检表

复习这套内容时，我建议不要按实验顺序从头看，而是按“资源 → 地基 → 连通 → 查询”四层做一张自检表，每层只留最关键的三四条。原因很实际：这套实验的知识点密度不高，但步骤之间的依赖极强，按层次复习能迅速定位自己是哪一层没夯实，而不是笼统地觉得“都学过但都记不清”。

填这张表有个技巧：不要一次性全填，按层填。第一层全绿再动第二层，因为后面每一层的失败都可能是前面某层留下的坑，混在一起填只会把排查范围放大四倍。另外，把每层的验证命令存成一个脚本，重装环境时直接跑一遍，比凭记忆重敲可靠得多。

查漏补缺的优先级，我的排序是：先补“地址类”问题（hosts、endpoint、端口），再补“权限类”问题（密钥、桶策略、目录权限），最后才是“参数类”问题（副本数、内存、并发）。前两类问题占了我见过的失败案例的绝大多数，而且都有一个共同点——配置看起来完全正确，只有实际跑一次数据才暴露。

从那以后我每次重做这类集群实验，都会在装 Hadoop 之前强制走一遍“四台主机名、四台 hosts 哈希、四台两两免密、四台 JDK 版本”这四项核对，四个全过才动配置文件。这个习惯看着笨，但它把最容易反复踩的坑一次性前置了，后面省下的时间远超这十分钟。希望帮到你。

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