简介：围绕华为云大数据实验教学整理的一份实操型报告，面向高校大数据、云计算相关课程学生及需要熟悉华为云平台的技术人员。整包仅含1个docx文档，约4.36MB，以图文实验记录形式组织，便于按实验模块查阅与复盘。内容覆盖云主机实现大数据、云服务实现大数据、BigData Pro综合实验和大数据交互式查询四个部分，涉及ECS、OBS访问配置、Hadoop集群搭建与节点通信、Spark集群部署、Spark SQL/Flink SQL查询等关键环节，并保留环境准备、配置命令、测试验证和结果查看等过程性材料。已有2541人学习，适合用于课程实验对照、步骤复现、报告撰写参考及排错思路梳理。
1. 先说一下这套四节点云的第一个坑：顺序比配置更要命
在华为云上做 big data 大数据实验，很多人以为难点是 Hadoop 那一堆 xml，真正把集群搞趴的往往是装机顺序：四台 ECS 先把主机名和/etc/hosts定死，再做 SSH 互信，最后才装 JDK 和 Hadoop——顺序反了，后面每一步都在补前面的问题。见得最多的失败案例是 node1 上hdfs namenode -format执行了两次，DataNode 一个都起不来，jps里只剩一个 NameNode，日志里 clusterID 对不上，只能删目录重来，而云主机还在按小时计费。这套环境本身不复杂，难在试错成本按分钟算，装错一次就是一次重装。这篇写给要在云上从零搭出一套能跑 wordcount、又能读到 OBS 的 Hadoop + Spark 集群的人：装什么、参数怎么填、坏了怎么救，一条条走。
2. 开装前把资源备齐：ECS 规格、OBS 桶与 AK/SK 的三个准备动作
装 Hadoop 之前最容易省掉、又最不该省的是资源规划。云上不像本地机房，机器是现买的，规格选错要么跑不动，要么钱包先受不了。这一步的核心是三件事：四台 ECS 按角色分配规格、OBS 建对桶类型、AK/SK 拿到手并保管好。这三件事做完，后面所有配置都有地方填值。
2.1 四台 ECS 的规格、镜像与计费方式
节点规划我一般这么分：node1 当 master，同时承担 NameNode 和 ResourceManager；node2 到 node4 当 worker，跑 DataNode 和 NodeManager。四台机器必须在同一 VPC、同一子网、同一安全组内，内网互通是 Hadoop 集群的生命线，跨子网跨安全组带来的排查成本远超想象。
| 主机名 | 角色 | 建议规格 | 数据盘 | 是否绑 EIP |
|---|---|---|---|---|
| node1 | NameNode / ResourceManager | 4 vCPU / 8 GiB | 100 GiB | 是，做跳板 |
| node2 | DataNode / NodeManager | 4 vCPU / 8 GiB | 100 GiB | 否 |
| node3 | DataNode / NodeManager | 4 vCPU / 8 GiB | 100 GiB | 否 |
| node4 | DataNode / NodeManager | 4 vCPU / 8 GiB | 100 GiB | 否 |
只有 node1 绑弹性公网 IP，其余三台只走内网。这是省钱也是省事的做法：实验期间所有操作从 node1 跳过去，公网暴露面只有一台。规格上 2 vCPU / 4 GiB 也能把集群拉起来，但一跑 Spark shuffle 就容易 OOM，重跑一次的时间成本比升配贵。系统盘 40 GiB 够用，数据盘单独挂载到/data，Hadoop 的tmp、name、data三个目录全放数据盘，后面扩容、做快照、整盘重建都方便。
镜像选 openEuler 或 CentOS 7.9 系的 x86_64 版本，架构必须和 ECS 规格一致。计费方式选按需（按小时），实验做完直接释放，包年包月在这类一次性场景里纯属浪费。安全组入方向只放 22 端口，来源限制成自己的出口 IP；9870、9000、8088、7077 这些端口只放安全组内部互访，不要对公网开放。
2.2 OBS 桶与并行文件系统怎么建
OBS 在这个环境里承担两件事：一是放实验数据（wordcount 的输入、Spark 的源数据），二是作为 Hadoop 兼容文件系统被obs://协议直接访问。建桶的时候有几条硬规则：桶名全局唯一、全小写、3 到 63 个字符；区域必须和 ECS 一致，ECS 在 cn-north-4，桶也建在 cn-north-4，否则跨区访问延迟高、还可能产生额外流量费用；存储类别选标准存储，实验数据不需要归档级别的低频访问。
访问域名有两套，用哪套取决于网络：
# 桶的访问域名（区域 cn-north-4） obs.cn-north-4.myhuaweicloud.com # IPv4 终端节点 obs.dualstack.cn-north-4.myhuaweicloud.com # 双栈终端节点，集群开了 IPv6 时用这个如果实验里要用 Hadoop 或 Spark 直接对 OBS 做文件系统级读写，还需要建并行文件系统，而不是普通对象桶。普通对象桶是键值语义，rename、append这类操作代价很高；并行文件系统提供 POSIX 语义，元数据操作快，Hadoop 的FileSystem接口在上面跑才不至于卡在 list 和 rename 上。桶策略保持私有，不要图省事开公共读，实验室里数据泄露和密钥泄露往往是一起发生的。
2.3 AK/SK 的生成、下载与保管
访问 OBS 靠的是访问密钥对：Access Key Id（AK）和 Secret Access Key（SK）。生成路径在控制台右上角「我的凭证」→ 访问密钥 → 新增访问密钥，确认后会下载一个credentials.csv，里面是三列：
# credentials.csv 的结构（值已打码，真实文件只下一次） User Name,Access Key Id,Secret Access Key "<用户名>","<AK，20 位左右>","<SK，40 位左右>"这个文件只在那一次生成时能下载，关掉页面就再也拿不到 SK，只能重新生成一对。一个账号最多保留两对密钥，够做轮换。我在实验报告里见过最危险的写法：把 AK/SK 原样贴进报告正文和截图里，甚至提交到公开仓库——这等于把桶的读写权限公开了。如果已经贴出去了，正确动作是立刻去控制台禁用这对密钥、重新生成一对，然后检查桶日志有没有异常访问，而不是删掉文字了事。
密钥在集群里怎么存也有讲究。直接写进core-site.xml明文是可以跑通的，但这份 xml 会被分发到四台机器，也会被顺手提交进代码仓库。稳妥一点的做法是用 Hadoop 的凭据提供者把 SK 存进密钥库，配置文件里只留别名。实验环境图快可以先用环境变量注入，至少别写死在版本库里。
装 obsutil 做个连通性验证，比后面在 Hadoop 里盲试省时间：
# 在 node1 上配置并验证 AK/SK 与桶是否互通 ./obsutil config -i=<AK> -k=<SK> -e=obs.cn-north-4.myhuaweicloud.com ./obsutil ls obs://<桶名>/-i和-k分别是 AK 和 SK，-e是终端节点，必须和桶所在区域匹配，填错区域会报 403 而不是 404，很容易误判成权限问题。ls能列出桶内容，说明密钥和网络都通了，再往下配 Hadoop 才有意义。
3. 系统底座：OpenJDK、hosts 与 SSH 互信的落地顺序
资源开好之后，四台机器要变成「一个集群」，靠的是三样东西：统一的 JDK、能互相解析的主机名、以及免密登录。这三件事有严格先后：先主机名和 hosts，再 SSH 互信，最后装 JDK 和 Hadoop。原因很简单，SSH 互信里要拼公钥，公钥末尾带的是root@主机名，主机名没定死，拼出来的文件四台机器对不上，后面所有分发脚本都会失败。
3.1 装 OpenJDK 并关掉防火墙
Hadoop 3.x 对 JDK 的要求是 8 或 11，实验环境用 8 最省事，镜像仓库里直接有。四台机器都要装，不要只装 node1，start-dfs.sh会 ssh 到其他节点去拉进程，对端没有 java 就直接退出。
# node1 到 node4 分别执行 dnf install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel # CentOS 7 系用 yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel java -version readlink -f $(which java) # 拿到真实路径，后面配 JAVA_HOME 用java-1.8.0-openjdk是运行环境，-devel带编译工具，Hadoop 本身不需要编译，但有些压缩库依赖它，一起装掉省事。readlink -f那条很关键：JAVA_HOME要填的是 JDK 根目录，不是bin/java的路径，很多人在这里多写一层bin，Hadoop 启动时报找不到 java。
防火墙这块，实验环境常见做法是直接关掉，因为 Hadoop 节点之间要开的端口太多，一个个放行容易漏：
# 四台分别执行 systemctl stop firewalld systemctl disable firewalld setenforce 0 # 临时关闭 SELinux sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config # 永久关闭需要注意的是，关防火墙只是实验环境的简化。真要在受控网络里跑，正确做法是保留 firewalld，按端口放行：9870 是 NameNode Web UI，9000 是 HDFS RPC，8088 是 YARN ResourceManager，9864 是 DataNode HTTP，7077 是 Spark master。生产环境靠安全组做边界，主机防火墙做细粒度，两层都留着。
3.2 主机名与 /etc/hosts 一一对应
云主机默认主机名是ecs-xxxx-0001这种自动生成的串，重启、重建实例还会变。集群里所有配置都引用主机名，所以第一步就是改名并写死解析。
# 每台机器只改自己的主机名 hostnamectl set-hostname node1 # node2/node3/node4 对应改 # 四台都编辑同一个文件 vim /etc/hosts内容统一成四行，全部用内网 IP：
192.168.0.10 node1 192.168.0.53 node2 192.168.0.169 node3 192.168.0.77 node4这里有两个坑。一是不要写公网 IP，Hadoop 节点之间走内网，写公网 IP 会导致数据在公网上绕一圈，速度慢还计费；而且 ECS 停止再启动后公网 IP 可能变化，hosts 就失效了。二是不要给同一台机器写多个别名（比如node1 ecs-ca89-0001 ecs-ca89-0001这种），主机名解析出现歧义时，Hadoop 会用不同名字注册同一个节点，NameNode 里就会出现"死节点"和"活节点"同时存在的怪现象。
还有一条容易被忽略：ECS 如果按需创建、中途关机再开机，内网 IP 有概率变化。实验周期超过一天的话，建议在控制台给每台机器指定固定内网 IP，或者干脆不关机，用快照保留现场。
3.3 authorized_keys 的正确拼法
免密登录的原理不复杂：把四台的公钥合成一个文件，让每台机器的~/.ssh/authorized_keys里都包含全部四个公钥。麻烦在拼接这个动作上，十个翻车里有八个栽在这。
# 四台分别生成密钥对，-N "" 表示空密码，避免脚本卡在交互 ssh-keygen -t rsa -b 2048 -N "" -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub # 复制输出的整行内容把四台的公钥各自存成一个文件传到 node1，然后合并：
# node1 上执行：四行公钥合成一份，注意每行结尾必须有换行 cat node1.pub node2.pub node3.pub node4.pub > /tmp/all_keys sort -u /tmp/all_keys -o /tmp/all_keys wc -l /tmp/all_keys # 正常情况下应该是 4 行 # 分发到四台，权限一并设好 for h in node1 node2 node3 node4; do scp /tmp/all_keys $h:~/.ssh/authorized_keys ssh $h "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys && chmod 600 ~/.ssh/id_rsa" donesort -u去重是因为 node1 自己可能既在本地文件里又在别处被收集过一次，重复项本身不影响登录，但会让后面排查时误以为公钥数量不对。wc -l是自检：四台机器就是 4 行，如果是 3 行，说明有两行粘在一起了。
验证不要用交互式ssh node2，那样即使要密码你也不一定注意。用批处理模式，有密码提示就直接失败：
# 四台全测一遍，任何一台要密码都会立刻报错 for h in node1 node2 node3 node4; do ssh -o BatchMode=yes -o ConnectTimeout=5 $h hostname done输出四个主机名，说明互信成立。BatchMode=yes禁止任何交互，ConnectTimeout=5防止网络不通时卡住。这个命令我后面每次动过网络配置都会再跑一遍，比事后在 Hadoop 日志里找"Permission denied"快得多。
4. Hadoop 与 Spark 集群搭建：配置文件、格式化与启动
底座通了，接下来是把 Hadoop 装上去并让四个节点组成一个 HDFS 集群，再把 Spark 接进来。这一段是整个实验里配置项最密集的地方，核心只有一句话：所有配置文件在 node1 上改好，再一次性分发到其他三台。四台各改一遍，必然出现某一台workers少一行、某一台core-site.xml端口不一样的经典事故。
4.1 下载解包与 HADOOP_HOME
安装包建议直接从对象存储或内网镜像拉，四台都下载一遍太慢，我一般是 node1 下好，再 scp 分发。
# node1 上执行 cd /opt wget https://<镜像站>/hadoop/hadoop-3.3.6.tar.gz tar -zxvf hadoop-3.3.6.tar.gz mv hadoop-3.3.6 hadoop mkdir -p /data/hadoop/{tmp,name,data} chown -R root:root /opt/hadoop版本上，Hadoop 3.x 这一档内部小版本差异不大，关键是四台必须完全一致，混装 3.3 和 3.4 会在 RPC 协议上出问题，报错信息还特别含糊。解包目录我习惯放/opt/hadoop，数据目录放/data/hadoop，两者分开的好处是以后换机器只要挂数据盘就行。
环境变量写进~/.bashrc：
export HADOOP_HOME=/opt/hadoop export PATH=$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$PATH export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk # 用 readlink 拿到的真实路径 export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop改完source ~/.bashrc，hadoop version能输出版本号就算装好了。注意JAVA_HOME在这里写一份还不够，后面hadoop-env.sh里还要再写一次，原因在 5.3 会讲。
4.2 core-site.xml、hdfs-site.xml 与 workers
配置文件都在$HADOOP_HOME/etc/hadoop/下。先改core-site.xml，它决定整个集群的默认文件系统和临时目录：
<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://node1:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/data/hadoop/tmp</value> </property> </configuration>fs.defaultFS里的主机名必须是 node1，写成 IP 也能跑，但换机器时要改的地方就多了。hadoop.tmp.dir一定要改到数据盘，默认值在/tmp下，机器一重启临时文件被清理，NameNode 元数据跟着没了，这是最贵的坑之一。
再改hdfs-site.xml：
<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>dfs.replication默认是 3，四节点集群里挂掉一台副本数就凑不齐，写操作会一直重试。实验环境降到 2，磁盘占用砍掉三分之一，稳定性也够用。三个目录都指向/data，容量不够时只扩数据盘，不用动系统盘。
然后是workers文件，列出所有 DataNode 节点：
node2 node3 node4node1 不写进去，它只当 master。这里有个版本差异必须提：Hadoop 3.x 读的是workers，2.x 时代这个文件叫slaves。从老教程抄过来的配置，文件名写成slaves，在 3.x 上启动时不会有任何报错，只是 DataNode 一个都不启动，jps里干干净净，新手很容易在这里卡半天。
hadoop-env.sh里补一行 JAVA_HOME：
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk改完打包分发，四台的配置必须字节级一致：
# node1 上执行，把整个配置目录同步到其他节点 for h in node2 node3 node4; do rsync -av $HADOOP_HOME/etc/hadoop/ $h:$HADOOP_HOME/etc/hadoop/ done4.3 首次格式化与 start-dfs.sh
格式化 NameNode 是整个流程里唯一带「不可逆」性质的动作：
# 只在 node1 上执行，且只执行一次 hdfs namenode -format执行完会打印一串Storage directory /data/hadoop/name has been successfully formatted，看到这句就停手。第二次执行会把 clusterID 重新生成，而已经启动过的 DataNode 本地记录的还是旧的 clusterID，两边对不上，DataNode 启动即退出，日志里写的是Incompatible clusterIDs。真发生了也不是没救：停掉全部进程，删掉/data/hadoop/name和所有节点上的/data/hadoop/data，重新格式化一次，代价是数据全丢——实验环境无所谓，生产环境这就是事故。
启动顺序是 HDFS 先行、YARN 跟上：
start-dfs.sh start-yarn.sh # 四台分别执行 jps 检查 jpsnode1 上应该看到NameNode、ResourceManager、SecondaryNameNode；node2 到 node4 上应该看到DataNode、NodeManager。少任何一个，都先去对应节点的logs/目录看.log和.out，Hadoop 的报错信息写得比大多数中间件都清楚，前提是你去找。
4.4 Spark 与环境变量对接
Spark 在这里的角色是计算引擎，读 HDFS 也读 OBS。装法比 Hadoop 简单，预编译包解压即用，关键是版本要选-bin-hadoop3后缀的，否则自带的 Hadoop 客户端版本对不上。
cd /opt tar -zxvf spark-3.x.x-bin-hadoop3.tgz mv spark-3.x.x-bin-hadoop3 spark cd /opt/spark/conf cp spark-env.sh.template spark-env.shspark-env.sh里加三行：
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_CONF_DIR=/opt/hadoop/etc/hadoop export SPARK_MASTER_HOST=node1HADOOP_CONF_DIR这一行是整套配置里最值钱的一行。指向 Hadoop 的配置目录后，Spark 会自动读取core-site.xml和hdfs-site.xml，也就自动拿到了fs.defaultFS和后面要加的 OBS 相关参数。少了这一行，Spark 读obs://会报No FileSystem for scheme "obs"，很多人以为是 jar 没放对，其实是配置根本没被读到。
OBS 对接要往core-site.xml里补四个属性，并把 OBS 的 Hadoop 插件 jar 丢进share/hadoop/tools/lib/：
<property> <name>fs.obs.impl</name> <value>org.apache.hadoop.fs.obs.OBSFileSystem</value> </property> <property> <name>fs.obs.access.key</name> <value>${env.OBS_AK}</value> </property> <property> <name>fs.obs.secret.key</name> <value>${env.OBS_SK}</value> </property> <property> <name>fs.obs.endpoint</name> <value>obs.cn-north-4.myhuaweicloud.com</value> </property>用${env.OBS_AK}这种写法是为了不把密钥落盘，代价是启动进程的环境里必须有这两个变量，spark-submit和hadoop命令都要在同一 shell 下执行。fs.obs.endpoint填 IPv4 终端节点，集群开了 IPv6 才换成双栈那一个，填错区域会报鉴权失败，报错信息指向密钥，实际是域名问题。
5. 排错避坑：五条把集群搞趴的现场记录
这套环境跑通之后回头看，真正花时间的不是装，是装错之后的定位。下面五条是实验里出现频率最高的，每条都按「现象 → 原因 → 解决」记，照着对号入座能省掉大半重装。
5.1 现象：jps 只有 NameNode，DataNode 集体消失
原因基本锁定在格式化次数上。hdfs namenode -format每执行一次，/data/hadoop/name/current/VERSION里的clusterID就重新生成一次，而 DataNode 的VERSION里记的还是上一次的 ID。两边不一致时，DataNode 启动瞬间完成注册又立刻退出，jps里看不到，日志里能看到Incompatible clusterIDs。
解决分两种情况。如果集群里还没有任何数据，直接停进程、删目录、重新格式化：stop-dfs.sh之后删掉 node1 的/data/hadoop/name和四台的/data/hadoop/data，再hdfs namenode -format一次。如果已经有数据不能丢，就别格式化，改成把 NameNode 的VERSION里clusterID抄到各 DataNode 的VERSION里，重启 DataNode。前一种做法在实验环境里占九成，后一种只在数据不能丢时用。
顺带说一个排查习惯：判断 DataNode 是真没起还是起了又挂，看logs/hadoop-root-datanode-nodeX.log的最后 30 行比反复jps有效。
5.2 现象：ssh 免密登录某台机器仍然要密码
ssh node3弹密码，或者报Permission denied (publickey)。先别怀疑密钥生成，八成是authorized_keys的拼接出了问题：两个公钥粘在同一行，中间没有换行符，SSH 把后半段当成第一个密钥的注释，整行解析失败，那一台的公钥等于没写进去。
验证方法很直接：awk 'END{print NR}' ~/.ssh/authorized_keys，四台机器都该是 4。少于 4 就是粘一起了。修法是重新用cat a.pub b.pub c.pub d.pub合并，确保每个.pub文件本身以换行结尾。
还有一类是同权限相关的：家目录权限 755 不够，SSH 对.ssh目录要求 700、对authorized_keys要求 600，对家目录要求不能是 group 可写。chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys之后再试。这两种原因长得一样，先查行数再查权限，顺序别反。
5.3 现象：start-dfs.sh 报 JAVA_HOME is not set
明明java -version能输出版本，echo $JAVA_HOME也有值，一执行start-dfs.sh就提示找不到 java。原因是start-dfs.sh通过 ssh 去其他节点拉起进程，走的是非交互式 shell，不加载~/.bashrc，那里面的JAVA_HOME根本不存在。
解决是把JAVA_HOME写进$HADOOP_HOME/etc/hadoop/hadoop-env.sh，这个文件是 Hadoop 启动脚本自己 source 的，不受 shell 类型影响。同样的问题会出现在yarn-env.sh和 Spark 的spark-env.sh里，三个文件都写上最稳。
另一种变体是 java 路径写错，多写了一层bin。JAVA_HOME要的是 JDK 根目录，$JAVA_HOME/bin/java才是可执行文件。用readlink -f $(which java)拿到真实路径，去掉末尾的/bin/java就是正确答案。
5.4 现象：ECS 重启后集群起不来，hosts 里的 IP 全部失效
按需计费的 ECS 停机再开机，内网 IP 有概率变化，/etc/hosts里写死的地址就对不上了，表现为节点之间互相 ping 不通、start-dfs.sh卡在某台机器上超时。如果同时主机名也被重置成ecs-xxxx-0001，那就是双重故障。
预防比修复重要：创建实例时在控制台指定固定内网 IP，或者在实验周期内不关机，用快照保存状态。已经变了的话，去控制台查四台机器当前的内网地址，重写/etc/hosts并重新分发，然后跑一遍 3.3 里的BatchMode批量探测确认互信还在。主机名被重置的，重新hostnamectl set-hostname之后要重启一次，否则hostname命令的输出和内核里登记的名字不一致，Hadoop 注册节点时用的还是旧名。
5.5 现象：Spark 读 obs:// 报 No FileSystem for scheme "obs"
集群本身是好的，hdfs dfs -ls /正常，一读 OBS 就报这个错。三种原因按概率排：插件 jar 没放到$HADOOP_HOME/share/hadoop/tools/lib/下，或者放了但四台只放了一台；core-site.xml里fs.obs.impl写错类名；HADOOP_CONF_DIR没在spark-env.sh里配，Spark 压根没读到这份配置。
排查顺序是先确认 jar：ls $HADOOP_HOME/share/hadoop/tools/lib/ | grep obs，四台都要有。再确认配置：hadoop fs -ls obs://<桶名>/，这条能在 node1 上跑通，说明 Hadoop 侧配好了，问题就落在 Spark 的HADOOP_CONF_DIR上。最后确认密钥和区域，fs.obs.endpoint与桶所在区域不一致时报的是鉴权失败，容易误判成 AK/SK 错了。
6. 装完怎么验证：三条线跑通才算真的装好
装完不等于跑通，我一般按三条线验证，每条都对应一个具体的能力，全部通过才认为这套环境可以交付。
| 验证项 | 命令 | 健康输出 |
|---|---|---|
| HDFS 读写 | hdfs dfs -mkdir -p /test/input && hdfs dfs -put /etc/hosts /test/input/ | 无报错，hdfs dfs -ls /test/input/能看到文件 |
| wordcount | hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar wordcount /test/input /test/output | 任务 SUCCEEDED，part-r-00000里有词频 |
| OBS 互联 | hadoop fs -ls obs://<桶名>/ | 列出桶内对象或返回空列表 |
第一条验证的是 HDFS 本身。put成功说明 NameNode 和至少一个 DataNode 在正常工作，如果put卡住然后报could only be replicated to 0 nodes，回去看 5.1。第二条验证的是 YARN 和整个 MapReduce 链路，wordcount是最经典的冒烟测试，因为它同时压到了 HDFS 读、shuffle 写、HDFS 写三个环节。跑完之后hdfs dfs -cat /test/output/part-r-00000 | head看到每个词后面跟着次数，这条线就算通了。
第三条验证 OBS。这里有个细节：hadoop fs -ls obs://能列出内容，只说明读权限和网络通；要验证写，得再跑一次hdfs dfs -put /etc/hosts obs://<桶名>/test/，写成功才说明 AK/SK 的完整权限没问题。写不进去但能列出，多半是桶策略只给了读权限，或者用的是并行文件系统却按普通桶的路径访问。
Spark 侧的验证放在最后，因为它的依赖最多：
# 交互式查询，直接读 OBS 上的文件做统计 spark-sql --master local[2] -e " SELECT count(*) FROM parquet.\`obs://<桶名>/test/\`; "这条命令能返回行数，说明 Spark、Hadoop 配置、OBS 密钥三者全部对齐。跑不通就按 5.5 的顺序倒查，别一上来就重装 Spark，那是最没效率的做法。
从那以后我每次开新集群，都强制先跑一遍四节点的ssh -o BatchMode=yes批量探测，再hdfs dfs -put一个小文件确认写入，最后才动业务数据。这套动作花不到两分钟，能挡掉后面百分之八十的返工。希望帮到你。
本文还有配套的精品资源，点击获取
