ECS四节点Hadoop集群与对象存储、Spark SQL实验避坑指南

简介《华为云大数据实验报告hhu》面向高校大数据、云计算课程学习者及华为云实操入门者围绕云主机与云服务两条技术路径解决从环境准备、集群搭建到交互式查询的实验落地问题。报告按四个模块组织利用ECS与OBS配置访问密钥、打通节点SSH并安装OpenJDK完成Hadoop集群搭建借助云服务实现数据存储、处理与分析在BigData Pro中购买ECS、创建OBS并部署Hadoop与Spark集群使用Spark SQL或Flink SQL开展大规模数据查询与结果验证。资源包内含1个docx约4.36MB目录与实验步骤对应清晰便于按章节查阅命令、配置和验证记录也可作为课程实验报告撰写与云端排错的参考。目前已有2541人学习适合需要系统完成华为云大数据实验的读者。1. 一台 ECS 起四节点集群这份大数据实验报告到底值不值得照着跑很多人对“云上大数据实验”的印象就是开一台云主机、装个 Hadoop、跑个 WordCount 截张图交差。真照着这份实验报告完整走一遍会发现价值不在那个 WordCount而在于它把“弹性云服务器ECS 对象存储 四节点 Hadoop 集群 Spark 交互式查询”串成了一条闭环前半段在云主机上手工搭集群后半段把数据落点从本地磁盘换到对象存储最后用 Spark SQL 去查。它适合两类人手上有大数据课程设计要交、又不想在本地虚拟机里跟网络较劲的人以及要在真实公有云环境验证 HDFS 兼容文件系统、但不想从零写部署脚本的工程师。这份材料不完美报告里夹着明文访问密钥和一堆硬编码的内网 IP照着抄一定会踩坑——但坑本身恰恰是这份报告最值钱的部分。2. 云端四节点拓扑怎么切角色分配、规格与对象存储选型2.1 四节点角色分配与实例规格报告里用的是 node1 到 node4 四台 ECS这个数量不是随便定的。Hadoop 的默认副本数是 3四节点刚好能满足“一份数据落在三个 DataNode 上、还剩一台可以挂掉”的最小容错组合同时 node1 兼任 NameNode 和 ResourceManagernode2~node4 只跑 DataNode 和 NodeManagerCPU 和内存压力不会全压在管理节点上。这套分法在课程实验里够用也最省机器。规格上建议别省。我见过太多人开 2 vCPU / 4 GB 的入门款装完 JDK 和 HadoopNameNode 一启动内存就剩几百兆WordCount 跑到 map 0% 就再也不动了。四台机器统一的起步配置是 4 vCPU / 8 GB / 系统盘 40 GB如果数据要落本地 HDFS再挂一块 100 GB 的数据盘单独挂到/opt/bigdata下把系统和数据分开后面清理环境时不会误删。节点角色建议规格说明node1NameNode / ResourceManager / SecondaryNameNode4C8G管理节点堆内存调大node2DataNode / NodeManager4C8G数据节点node3DataNode / NodeManager4C8G数据节点node4DataNode / NodeManager4C8G数据节点兼 Spark Worker提示四台机器尽量选同一个可用区、同一个子网内网互通不需要额外配置后面写/etc/hosts时也只用内网地址。2.2 为什么数据落点要选对象存储而不是本地 HDFS报告里有一个很容易被忽略的设计它没有让实验数据停在本地 HDFS 上而是要求把 ECS 和对象存储打通WordCount 的输入输出都能走obs://开头的路径。这个选择的现实理由是——ECS 是按小时计费的实验做完一释放本地磁盘上的数据全没了下次再做实验要么重新上传要么从头跑一遍。对象存储按量计费、容量几乎不受限桶里的数据可以跨会话、跨机器复用这在上课场景里非常关键。技术上云厂商一般会提供一个 Hadoop 兼容的文件系统实现一个 jar 包把它丢进$HADOOP_HOME/share/hadoop/common/lib/或者加到 classpathHadoop 就能把obs://bucket/path当成一个普通的文件系统来读写。上层 MapReduce、Spark 代码完全不用改只是把路径从hdfs://换成obs://。代价是延迟对象存储的元数据操作比 NameNode 慢一个数量级小文件多的时候会非常明显所以实验里要养成“先合并再上传”的习惯。还有一种更省事的做法是并行文件系统它提供 POSIX 语义可以像本地目录一样挂载到 ECS 上适合需要随机读写或者多机共享同一份训练数据的场景。两种方式在报告里都出现了选哪个取决于你的作业是不是需要“文件系统语义”——如果只是 WordCount 这种顺序读写直接用连接器就够了。2.3 上机前必须先对齐的资源清单动手前把下面这些信息一次性收集齐比中途来回翻控制台强得多。报告里最容易出错的地方就是密钥和端点很多“连不上”的问题到最后都是复制粘贴时多了一个空格。资源项用途需要注意VPC 与子网四台 ECS 的内网互通四台必须在同一 VPC安全组放行 22 / 9870 / 8088 / 7077 / 8080 / 18080实验期可对内网全放行别开公网对象存储桶存输入输出数据与 ECS 同区域避免跨区流量访问密钥 AK/SK连接器认证用完即删别写进截图服务端点 Endpoint连接器寻址用服务级域名不是桶域名内网 IP 列表写/etc/hosts四台机器内容完全一致注意报告里贴出的访问密钥、SSH 公钥和公网 IP 都是真实值这类材料在流转过程中基本等于公开。自己复现时凡是出现在文档、截图、代码注释里的密钥一律视为已泄露实验结束立刻在控制台删除并重建。3. 从空系统到 SSH 互信节点初始化里最容易被跳过的一小时3.1 主机名与 /etc/hosts 的固定写法Hadoop 全靠主机名找节点配置文件里写的是node1:9000这种形式一旦解析不到NameNode 起来也是白起。四台机器分别执行下面的命令设置主机名然后统一写 hosts 文件。注意 hosts 里必须用内网 IP公网 IP 写进去在跨节点通信时会绕出去再绕回来慢且容易失败。# 四台机器分别执行node1 上的就把 node1 换成对应名字 hostnamectl set-hostname node1 # 四台机器统一追加内容必须完全一致 cat /etc/hosts EOF 192.168.1.11 node1 192.168.1.12 node2 192.168.1.13 node3 192.168.1.14 node4 EOF # 验证四台互相 ping 通、hostname -f 返回正确 ping -c 2 node3 hostname -fhostnamectl set-hostname只改运行时主机名重启后依然有效hostname -f如果返回的不是短名而是带域名的长名说明云厂商的 DHCP 下发了一套默认域名要么在/etc/hostname里写死要么在/etc/hosts里保证短名排在第一位否则 Hadoop 会拿长名去通信配好的互信直接失效。3.2 密钥分发与 authorized_keys 的合并姿势报告里是让每台机器生成密钥、再把四份公钥粘贴到同一个文件里。手工复制四段公钥十个里有八个会少一个换行或者多一个空格结果就是“配了免密但还是要密码”。写成脚本一次做完顺便把known_hosts也处理掉避免第一次连接时卡在 yes/no 交互上。#!/bin/bash # 在 node1 上执行前提/etc/hosts 已配好四台 root 密码一致 set -e # 1. 四台机器各自生成密钥已存在则跳过 for h in node1 node2 node3 node4; do ssh $h test -f /root/.ssh/id_rsa || ssh-keygen -t rsa -b 2048 -N -f /root/.ssh/id_rsa done # 2. 收集四台公钥去重后写入统一文件 : /tmp/all_pub for h in node1 node2 node3 node4; do ssh $h cat /root/.ssh/id_rsa.pub /tmp/all_pub done sort -u /tmp/all_pub /root/.ssh/authorized_keys # 3. 分发到四台并修正权限 for h in node1 node2 node3 node4; do ssh $h mkdir -p /root/.ssh chmod 700 /root/.ssh scp -q /root/.ssh/authorized_keys $h:/root/.ssh/authorized_keys ssh $h chmod 600 /root/.ssh/authorized_keys done # 4. 预置 known_hosts消除首次连接交互 for h in node1 node2 node3 node4; do ssh-keyscan -H $h /root/.ssh/known_hosts 2/dev/null done sort -u /root/.ssh/known_hosts -o /root/.ssh/known_hosts这段脚本的核心是第 2 步sort -u去重保证四台机器的authorized_keys内容完全一致、每行一个公钥、末尾有换行。第 3 步的两个权限是关键——.ssh目录必须是 700authorized_keys必须是 600权限过宽 sshd 会直接拒绝使用这个文件而且默认不打印任何日志表现就是“怎么都不免密”。第 4 步用ssh-keyscan把主机指纹提前写进known_hosts脚本化部署时能省掉大量StrictHostKeyCheckingno的临时手段。验证方式很土但有效四台机器上分别执行ssh node1到ssh node4四次都应该直接进 shell 不提示密码。这一步不过后面的start-dfs.sh一定起不来。3.3 JDK 与 Hadoop 安装包落地报告里是在 node1 上在线下载 OpenJDK 和 Hadoop 安装包然后分发给其余节点。实际做的时候建议固定版本号别用latest四台机器版本不一致是后面最隐蔽的故障来源之一。# 统一安装 OpenJDK 8 与 Hadoop 3.x yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel # 解压到统一目录 mkdir -p /opt/bigdata tar -zxf hadoop-3.x.x.tar.gz -C /opt/bigdata/ mv /opt/bigdata/hadoop-3.x.x /opt/bigdata/hadoop # 写环境变量四台机器内容一致 cat /etc/profile.d/bigdata.sh EOF export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_HOME/opt/bigdata/hadoop export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop export PATH$PATH:$JAVA_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbin export HADOOP_HEAPSIZE2048 EOF source /etc/profile.d/bigdata.sh hadoop versionHADOOP_HEAPSIZE这一行报告里没提但 8 GB 的机器如果不显式指定NameNode 默认堆只有 1 GB 左右稍微跑点作业就会 OOM 或者频繁 Full GC。设成 2048 之后NameNode 和 ResourceManager 各自占 2 GB 堆四节点实验完全够用。3.4 防火墙、SELinux 与时间同步实验环境里防火墙是纯负担Hadoop 节点间要开十几个端口一个个放行不如直接关掉用安全组在云平台侧做访问控制更清晰。SELinux 对 HDFS 目录权限的干扰也很玄学关掉省事。# 四台机器分别执行 systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config # 时间同步四台偏差超过 30 秒集群会出各种奇怪问题 systemctl enable --now chronyd chronyc sources -v时间同步容易被忽略但它是典型的黑匣子故障源NameNode 和 DataNode 之间靠心跳和租约协作机器之间时间偏差大了会出现“DataNode 明明活着却被标记为 dead”或者“作业卡在 commit 阶段”。chronyc sources里只要能看到带^*的服务器就说明同步正常。4. Hadoop 配置与对象存储对接core-site.xml 里四个必须对齐的参数4.1 core-site.xml默认文件系统与对象存储接入core-site.xml是整个集群的地基改错一个标签四个节点全部起不来。报告里最关键的是两块配置HDFS 的默认地址以及对象存储连接器的四个参数。参数名通常以fs.obs.开头别自己臆造。configuration property namefs.defaultFS/name valuehdfs://node1:9000/value /property property namehadoop.tmp.dir/name value/opt/bigdata/tmp/value /property !-- 对象存储连接器实现类 -- property namefs.obs.impl/name valueorg.apache.hadoop.fs.obs.OBSFileSystem/value /property !-- 密钥通过环境变量注入不要把明文写进这个文件 -- property namefs.obs.access.key/name value${env.OBS_AK}/value /property property namefs.obs.secret.key/name value${env.OBS_SK}/value /property !-- 服务端点必须与桶所在区域一致 -- property namefs.obs.endpoint/name valueobs.cn-north-4.myhuaweicloud.com/value /property /configuration逐项说fs.defaultFS里的node1必须是能被四台机器解析的主机名写成 IP 也能跑但换机器时全得改hadoop.tmp.dir建议单独指定不要用默认的/tmp很多云主机/tmp分区只有几个 G跑两个作业就写满fs.obs.impl是连接器的入口类jar 包不在 classpath 里时这个属性会静默失效表现是obs://路径报No FileSystem for schemefs.obs.access.key用${env.OBS_AK}做变量替换Hadoop 的 Configuration 支持env.前缀这样密钥就不会留在配置文件里被截图带走——报告里明文贴密钥的做法别学。注意端点必须用服务级域名不是桶域名。写成bucket-name.obs.xxx.com这种形式绝大部分连接器都不认报的还是认证失败很容易误判成密钥错了。4.2 hdfs-site.xml、workers 与副本策略hdfs-site.xml里改三件事就够跑通副本数、NameNode 元数据目录、DataNode 数据目录。四节点环境副本数设 3既能看到三副本分布又不至于把四台机器写满。configuration property namedfs.replication/name value3/value /property property namedfs.namenode.name.dir/name value/opt/bigdata/hdfs/name/value /property property namedfs.datanode.data.dir/name value/opt/bigdata/hdfs/data/value /property property namedfs.namenode.http-address/name valuenode1:9870/value /property /configurationHadoop 3.x 用workers文件2.x 是slaves内容是三个数据节点的主机名一行一个node1 写在第一行也行但通常只放工作节点cat $HADOOP_CONF_DIR/workers EOF node2 node3 node4 EOF这个文件决定了start-dfs.sh会去哪些机器上拉起 DataNode。报告里出现“集群起来了但只有一个 DataNode”的情况九成是这里没改或者改了没分发到 node1。改完记得用scp把整个etc/hadoop目录同步到其余三台配置不一致是分布式环境最典型的翻车方式。4.3 格式化、启动与 jps 验收格式化只做一次这是血泪经验。hdfs namenode -format会在dfs.namenode.name.dir下生成 clusterIDDataNode 首次启动时把自己的 clusterID 写进数据目录两边对不上就拒绝加入集群。第二次格式化会让 NameNode 换一个新 ID而 DataNode 还留着旧的现象就是“DataNode 进程在、但集群里看不到”。# 只在 node1 上执行且全生命周期只执行一次 hdfs namenode -format # 启动 HDFS 与 YARN start-dfs.sh start-yarn.sh # 四台机器分别检查进程 jps验收标准是 node1 上能看到NameNode、SecondaryNameNode、ResourceManagernode2~node4 上能看到DataNode、NodeManager。少了哪个先看对应机器上logs/目录下最新的.log别急着删目录重来。启动完成后浏览器打开http://node1:9870Live Nodes 显示 3 才算真正起来了。4.4 WordCount 跑通与对象存储回读WordCount 是这份实验的验收动作但它真正的目的是验证两条路径本地 HDFS 读写是否正常以及对象存储连接器是否可以跨系统读写。建议把输入先放 HDFS 跑一遍再把输出直接写到对象存储一次把两个问题都暴露出来。# 准备输入 hadoop fs -mkdir -p /input hadoop fs -put /opt/bigdata/data/*.txt /input/ # 第一次输入输出都走 HDFS hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.x.x.jar \ wordcount /input /output/wc01 # 第二次输出直接落到对象存储 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.x.x.jar \ wordcount /input obs://my-bigdata-lab/output/wc02 # 两边都检查一下 hadoop fs -cat /output/wc01/part-r-00000 | head hadoop fs -ls obs://my-bigdata-lab/output/wc02/hadoop jar后面跟的 jar 包路径里版本号要跟你实际解压的一致用通配符hadoop-mapreduce-examples-*.jar更稳妥。第二次作业如果卡在map 0%很久然后失败先去看 ResourceManager 的 8088 页面大概率是容器内存不够或者连接器 jar 没被分发到计算节点——MapReduce 会把依赖 jar 打进 DistributedCache连接器 jar 如果只放在 node1 的 classpath 里任务跑到 node2 上就会报ClassNotFoundException。稳妥做法是把连接器 jar 直接放进$HADOOP_HOME/share/hadoop/common/lib/并分发到四台。4.5 Spark 复用同一套 Hadoop 配置Spark 不需要单独配一套文件系统参数它读的是HADOOP_CONF_DIR指向的目录。所以只要spark-env.sh里把这两行加上Spark 就能直接读写 HDFS 和对象存储连密钥都不用再配一遍。# 在 $SPARK_HOME/conf/spark-env.sh 中追加 export HADOOP_CONF_DIR/opt/bigdata/hadoop/etc/hadoop export SPARK_DIST_CLASSPATH$(hadoop classpath) # conf/workers 写三个工作节点 node2 node3 node4 # 启动 $SPARK_HOME/sbin/start-all.shSPARK_DIST_CLASSPATH$(hadoop classpath)这一行是关键它把 Hadoop 的所有依赖包括连接器 jar一次性塞进 Spark 的运行时 classpath省掉逐个拷 jar 的麻烦。启动后在 node1 上执行spark-sql能进交互式命令行说明集群和配置都对上了。5. 避坑排查五条照着报告做却卡住的真实记录5.1 SSH 免密配完仍要密码、DataNode 起不来现象ssh node2仍然提示输入密码或者免密通了但start-dfs.sh之后jps里只有 NameNodeDataNode 一个都没有。原因前者基本是权限问题.ssh目录不是 700 或authorized_keys不是 600sshd 会静默忽略这个文件也可能是四台机器的authorized_keys内容不一致脚本只在一台上跑过。后者最常见的原因是格式化执行了两次NameNode 和 DataNode 的 clusterID 对不上日志里会明确写Incompatible clusterIDs。解决先ls -ld /root/.ssh和ls -l /root/.ssh/authorized_keys看权限再md5sum四台的authorized_keys确认一致。clusterID 问题只能停集群、清空dfs.namenode.name.dir和dfs.datanode.data.dir下的内容、重新格式化一次然后重新启动。养成习惯格式化这个动作在任何环境里都只做一次重装集群就先把数据目录清干净。5.2 对象存储认证失败与端点错配现象obs://路径报InvalidAccessKeyId或者Status 403但同样的密钥在控制台上能正常访问桶。原因三种情况最常见——AK/SK 从文档里复制时带了首尾引号或空格端点写成了桶域名而不是服务域名桶和 ECS 不在同一区域连接器按区域拼出来的地址实际指向了另一个端点。还有一种是密钥本身是子账号的权限策略里没给这个桶的读写权限报错信息同样是 403很容易误判。解决把 AK/SK 用echo -n打进环境变量再用env | grep OBS确认没有多余字符端点统一用控制台给出的服务级地址跨区域问题直接在桶所在区域重建 ECS或者换一个同区域的桶做实验。排查顺序固定为先验证密钥能否ls一个已知存在的桶再验证能否写最后才跑作业别一上来就用 MapReduce 试错。5.3 WordCount 卡在 map 0% 或容器被 kill现象作业提交后进度条长时间停在map 0% reduce 0%8088 页面显示容器状态KILLED日志里有Container killed on request. Exit code is 137。原因137 是 OOM 被杀。YARN 默认的yarn.nodemanager.resource.memory-mb在 8 GB 机器上通常给到 8 GB但单个容器默认申请 1 GB 虚拟内存、实际物理内存不够时会触发超配限制另外yarn.nodemanager.vmem-check-enabled默认开启虚拟内存超了也会被杀而 JVM 的虚拟内存占用天然偏高。解决在yarn-site.xml里把yarn.nodemanager.resource.memory-mb设成 6144yarn.scheduler.maximum-allocation-mb设成 4096并把yarn.nodemanager.vmem-check-enabled设为 false实验环境可以关生产别关。改完同步到四台并重启 YARN。这一条在 4 GB 内存的机器上几乎必现所以第 2 章才建议直接上 8 GB。5.4 集群时间漂移导致的假死现象集群运行一段时间后9870 页面上某个 DataNode 显示Dead但那台机器上jps明明有 DataNode 进程重启后又正常过一阵再死。原因节点间时间不同步心跳包的时间戳被判为过期。云主机默认可能没开时间同步服务或者 NTP 源不可达机器之间的偏差会慢慢累积。解决四台统一启用chronydchronyc sources -v确认有^*标记的同步源同时在hdfs-site.xml里把dfs.namenode.heartbeat.recheck-interval适当调大给网络抖动留出余量。这条不解决你会反复怀疑是 Hadoop 的 bug实际上跟 Hadoop 一点关系都没有。5.5 实验报告里的明文密钥现象报告正文和截图里直接贴着 AK/SK、SSH 公钥、内网 IP 和主机名照着复制就能用。原因作者在做实验时没有脱敏直接把控制台和终端截图贴进了文档。这类材料一旦在群里、网盘里流转密钥等于公开桶里的数据、甚至同账号下的其他资源都存在风险。解决自己复现时密钥一律走环境变量或临时凭证绝不写进配置文件和截图用子账号而不是主账号权限策略只给实验桶的读写实验结束当天就在控制台删除密钥并重建。文档里出现的 IP、主机名、密钥、桶名提交前统一替换成占位符这一条比任何技术细节都重要。6. 跑通之后的验证与脱敏把一次实验变成可复用的检查单作业跑绿不等于集群健康。我习惯在交报告之前做一轮端到端校验HDFS 侧看副本是否真的落到了三台机器上对象存储侧看输出目录里的_SUCCESS文件和 part 文件数量是否对得上Spark SQL 再用count(*)跟 HDFS 的结果交叉验证一次。三边数字一致才算这次实验真的跑通了。# 1. 副本分布每个块应该出现三次且分布在 node2~node4 hdfs fsck /output/wc01 -files -blocks -locations # 2. 对象存储侧校验有 _SUCCESS 且 part 文件数等于 reduce 数 hadoop fs -ls obs://my-bigdata-lab/output/wc02/ # 3. Spark SQL 交叉验证结果应与 HDFS 上 wc01 的总行数一致 spark-sql -e CREATE EXTERNAL TABLE wc02(line STRING) LOCATION obs://my-bigdata-lab/output/wc02; SELECT count(*) FROM wc02; 第一行fsck看的是数据可靠性副本数不足会在输出里标Under-replicated第二行看的是连接器写入是否完整缺_SUCCESS说明作业没正常提交第三行用 Spark 直接读对象存储建外部表是验证“交互式查询”这条路是否真正打通的最快方式。LOCATION指向目录而不是单个文件Spark 会把目录下所有 part 文件当成表数据这也是为什么一定要确认 part 文件数量。交报告之前还有一步脱敏。密钥、公钥、内网 IP、主机名、桶名一个都不能留。手工改容易漏用一条命令扫一遍更稳# 扫描报告和脚本里疑似敏感信息输出行号方便定位 grep -nE (AK|SK|access[_-]?key|secret|ssh-rsa|192\.168\.|10\.[0-9]\.[0-9]\.) report.md命中之后逐条替换成ACCESS_KEY、INTERNAL_IP这类占位符再重新扫一遍直到没有输出。这一步花不了五分钟但能避免把一份带密钥的文档发给别人。从那以后我每次做云上实验收尾都强制走一遍这套校验加脱敏跑通了不等于交付了交付的是别人能照着复现、又不会泄露自己环境的那一版。希望帮到你。本文还有配套的精品资源点击获取