云上大数据实验：Hadoop集群搭建与Spark SQL查询

简介《华为云大数据实验报告hhu》面向高校大数据课程学习者与华为云入门实践者围绕云上大数据平台的部署与管理给出四组实验记录。内容从弹性云服务器ECS与对象存储OBS的环境准备切入覆盖Hadoop集群搭建、节点SSH互通、关闭防火墙与OpenJDK安装并延伸至云服务支撑的大数据流程、BigData Pro中Hadoop与Spark集群配置及OBS互联测试最后落到Spark SQL等交互式查询的数据表创建与分析实践。资源包仅含1个docx文档约4.36MB目录按实验模块编排便于对照操作与复盘关键配置。已有2542人学习适合需要完成课程实验、梳理华为云大数据操作链路或查漏补缺的读者参考。1. 云上大数据实验全景从一台云主机到一条查询语句在云上做 big data大数据和在本地机房做差别不在于 Hadoop 本身而在于资源从哪里来。这套实验把整条链路切成四段先用云主机把集群跑起来再用对象存储把数据放进去接着用一站式大数据平台把部署过程缩短最后用交互式查询把数据用起来。四段实验训练的知识点相同都落在节点、网络、存储、计算、查询这条主线上只是每一段替你解决一个具体麻烦第一段解决“机器怎么来”第二段解决“数据放哪”第三段解决“部署能不能更快”第四段解决“数据怎么问出答案”。这套内容适合已经会用 Linux 基础命令、知道 HDFS 和 YARN 大概负责什么但一上手就卡在“节点之间连不通”“密钥到底是什么”这类问题上的人。往下看重点不要放在照着敲步骤上应该放在每一步背后那条不能断的因果关系上为什么私网 IP 写进 hosts、为什么不配 HADOOP_CONF_DIR 就会报错、为什么 namenode 只能格式化一次。把这条因果链记住换一台机器、换一个区域你照样能搭起来。2. 资源准备云主机、对象存储与访问密钥的三角关系云上大数据的第一道关卡不在 Linux而在资源模型。很多人在本地搭过伪分布式觉得上云只是“把机器换成虚拟机”结果第一步就卡住因为没有分清三个东西各自负责哪一段云主机负责计算和运行进程对象存储负责放数据和结果文件访问密钥负责“你凭什么能碰这个桶”。这三者组成一个三角形缺一边或者配错边后面的集群都搭不起来。2.1 弹性云服务器先定规格再定网络买云主机弹性云服务器ECS的时候有几个参数需要先想清楚不是随便点一下就买。区域Region要先定。所有资源尽量放在同一个区域因为你后面要买的的对象存储桶也在某个区域跨区域访问会有额外的网络延迟甚至因为权限策略不通而直接失败。实验里用到的 endpoint 形如obs.cn-north-4.myhuaweicloud.com中间那段就是区域标识区域选错后面的链接一定对不上。规格上四节点的 Hadoop 集群每台 2 vCPU / 4 GB 是能跑起来的下限如果还要在同一批机器上跑 Spark 作业namenode 那台建议提到 4 vCPU / 8 GB。磁盘 40 GB 起步因为要放 JDK、Hadoop、Spark 三个压缩包加上解压后的目录空间紧张的时候连解压都会失败。镜像选通用 Linux 发行版即可关键是能正常使用yum或apt并且默认带ssh服务。网络这一步最容易含糊。四台机器放在同一个 VPC、同一个子网里互相之间用私网 IP 通信。私网 IP 是192.168.x.x这种形式只有同子网内互通公网 IP 只在你用本地终端登录的时候用。这个区分在实验里被反复验证/etc/hosts里写的一定是私网 IP写公网 IP 会让节点间通信绕出云外速度慢还可能被安全组挡掉。节点名私网 IP 示例承担角色node1192.168.0.10NameNode、ResourceManager、SecondaryNameNodenode2192.168.0.53DataNode、NodeManagernode3192.168.0.169DataNode、NodeManagernode4192.168.0.77DataNode、NodeManager还有一个容易忽略的点云主机默认分配的私网 IP在关机再开机之后不保证不变。做实验的当天最好一次开完四台中途别关如果确实要重启重开之后先ip addr看一眼私网 IP 有没有变化变了就同步改四台的/etc/hosts不然集群会莫名其妙地少节点。2.2 对象存储桶、并行文件系统与 endpoint对象存储OBS在实验里出现了两种形态很多人把它们混为一谈实际上语义完全不同。普通桶是对象语义里面存的是 key-value通过 HTTP API 读写适合放安装包、日志、最终结果文件。你在控制台点“创建桶”填一个全局唯一的桶名选好区域和访问策略桶就建好了。桶名全局唯一这件事会带来一点麻烦如果名字被别人占了创建会直接失败换一个带自己前缀的名字就行。并行文件系统是 POSIX 语义有目录树、能挂载到云主机上当成一块盘用读写行为和本地文件系统接近。它更适合给 Hadoop、Spark 当共享存储因为很多计算框架假设自己有目录、有文件句柄。两种形态各有用途实验里“创建桶对象”和“创建并行文件系统”是并列出现的别以为只是同一个东西换了两个入口。endpoint 是访问入口格式一般是obs.区域.域名。实验里还给出了一个双栈地址obs.dualstack.cn-north-4.myhuaweicloud.com多出来的dualstack表示同时支持 IPv4 和 IPv6。这个地址要不要用取决于你的集群网络是否开了 IPv6没开就老老实实用普通地址强行用双栈反而会解析失败。提示endpoint、桶名、区域这三样必须自洽。排查连通性问题时先用一条不带任何密钥的请求确认域名能不能通再去怀疑密钥。# 只探测域名与网络连通性不带任何凭证 curl -I https://obs.cn-north-4.myhuaweicloud.com # 返回 200 或 403 都说明网络和域名没问题403 是没带凭证的正常拒绝 # 返回 Could not resolve host基本可以判定区域写错或 DNS 没配这条命令的价值在于分层它把“网络通不通”和“密钥对不对”拆成两个独立问题。很多人一上来就怀疑 AK/SK 写错折腾半天最后发现是区域填错导致域名根本不存在。2.3 访问密钥AK/SK 到底在验证什么地址解决了“往哪发请求”密钥解决“凭什么让你发”。这两个是正交的配错任意一个都会失败但报错信息完全不同这是排查时的分水岭。在控制台创建访问密钥后会下载到一个credentials.csv文件里面三列User Name、Access Key Id、Secret Access Key。Access Key Id 简称 AK是身份标识可以理解为用户名Secret Access Key 简称 SK是密钥相当于密码。两者配对使用只给 AK 不给 SK 是签不出请求的。SK 有一个残酷的特性只在创建时完整展示一次页面关掉之后再也看不到丢了只能删掉重建。所以拿到credentials.csv的第一件事是确认里面的内容完整然后把它放到一个不会误提交的位置。# 推荐做法用环境变量注入避免密钥写进代码或配置文件 export OBS_AK你的Access Key Id export OBS_SK你的Secret Access Key export OBS_ENDPOINTobs.cn-north-4.myhuaweicloud.com # 校验变量是否生效注意不要 echo 出完整 SK echo AK 长度: ${#OBS_AK} SK 长度: ${#OBS_SK}用环境变量的好处是密钥不落盘到项目目录git status里不会突然冒出一个带密钥的配置文件。代价是每个新开的终端都要重新 export 一次这一点在实验里会造成“刚才还能用换个窗口就 403”的错觉后面易错点那章会专门说。还有一层容易漏密钥对只是身份权限是另一回事。如果这个用户所属的账号没有被授予目标桶的读写策略密钥再正确也会被拒。现象是“认证通过但操作被拒绝”和“认证失败”是两种不同的错误码看到前者要去查权限策略不要再去折腾密钥本身。3. Hadoop 集群四节点、互信与配置文件里的必改项资源准备好之后真正的集群搭建才开始。这一章是整份实验报告里内容最密的一段因为它同时涉及主机名解析、免密登录、四个 XML 配置文件和一次性的格式化操作。任何一处没对上start-dfs.sh跑完之后jps就会少进程而且报错往往指向别处非常考验按层排查的耐心。3.1 节点规划与 /etc/hosts 的写法四台机器的角色分配是固定的node1 当主节点跑 NameNode、ResourceManager、SecondaryNameNodenode2 到 node4 当从节点跑 DataNode 和 NodeManager。这是单 NameNode 架构没有高可用对实验来说完全够用但要知道它意味着 node1 挂了整个 HDFS 就不可用。/etc/hosts的作用是让机器名和 IP 建立映射Hadoop 的配置文件里到处写的是主机名而不是 IP所以这份文件必须在四台上完全一致。# 四台机器上都要写入同样的内容 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格式是「IP 主机名」行内用空格或 Tab 分隔不要写成node1 192.168.0.10。写完立刻验证别等到启动集群才发现解析不了。这里有一个隐藏的坑主机名必须和hostname命令的真实返回值一致。有些镜像默认主机名是一长串自动生成的字符串而你在 hosts 里手写了node1Hadoop 启动时 DataNode 会拿真实主机名去 NameNode 注册两边对不上结果就是 NameNode 起来了、DataNode 也起来了但hdfs dfsadmin -report里一个存活节点都没有。补法是先hostname看一眼再用hostnamectl set-hostname node1把真实主机名改成和 hosts 一致改完重新登录生效。同一批要做的还有两件基础工作。一是装 JDK实验里用的是 OpenJDK装完要确认JAVA_HOME指向正确因为后面hadoop-env.sh里要显式写死这个路径。二是关防火墙systemctl stop firewalld systemctl disable firewalld再把 SELinux 设成disabled并写进/etc/selinux/config否则重启之后又会回来。这一步经常被当成走过场但 NodeManager 和 DataNode 之间那些端口一旦被拦症状就是进程在、端口不通。3.2 SSH 免密互信把四台机器变成一台Hadoop 的主从架构依赖一个前提主节点能免密登录到所有从节点并且从节点之间最好也能互相免密。因为start-dfs.sh在 node1 上执行时它要 SSH 到 node2、node3、node4 去拉起各自的守护进程。原理很朴素本地生成一对密钥公钥追加到目标机器的~/.ssh/authorized_keys里之后本地用私钥签名对方用公钥验证就不用输密码了。# 在每台机器上生成密钥对-N 表示不设密码短语 ssh-keygen -t rsa -b 2048 -N -f ~/.ssh/id_rsa # 查看生成结果id_rsa 是私钥绝不能外传id_rsa.pub 是公钥 ls -l ~/.ssh/ # 把本机公钥复制到目标节点会要求输一次目标机密码 ssh-copy-id node2如果要四台两两互通一共需要 12 次复制。手敲太累可以套一层循环# 在每台机器上执行把自己推给其它三台 for target in node1 node2 node3 node4; do if [ $(hostname) ! $target ]; then ssh-copy-id -o StrictHostKeyCheckingno $target fi done-o StrictHostKeyCheckingno的作用是跳过第一次连接时的指纹确认否则每台都要手动输一次 yes。验证方式是用ssh node2 hostname这种带命令的形式如果直接返回node2而不问密码就说明通了。别只看“没报错”有些环境会卡在密码提示上你没注意就以为成功了。权限是这里最容易翻车的地方。~/.ssh目录必须是 700authorized_keys必须是 600id_rsa建议 600。权限松了sshd 会直接忽略这个文件表现就是“文件明明有内容但还是要密码”。chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 600 ~/.ssh/id_rsa还有一点认知层面的混淆实验报告里贴出来的那一长串以ssh-rsa开头的内容是公钥不是私钥。公钥本来就可以公开贴出来没问题但如果你把id_rsa没有.pub后缀的那个当成公钥发出去或者写进 authorized_keys那就直接把私钥泄了而且互信也不会生效。3.3 四个 XML 文件的最小改动集Hadoop 的配置项有几百个但实验里真正需要动的就那么几个。记住“最小改动集”比背下所有参数有用得多因为剩下的都是默认值在起作用。core-site.xml定两件事默认文件系统是谁以及临时目录放哪。configuration property namefs.defaultFS/name valuehdfs://node1:9000/value /property property namehadoop.tmp.dir/name value/opt/hadoop/data/tmp/value /property /configurationfs.defaultFS写成hdfs://node1:9000端口 9000 是约定俗成的改成别的也能用但要保证所有客户端配置一致。hadoop.tmp.dir决定了 NameNode 和 DataNode 的元数据、块文件落在哪默认值在/tmp下面机器一重启就可能被清空所以一定要改成持久化目录。hdfs-site.xml定副本数和数据目录configuration property namedfs.replication/name value3/value /property property namedfs.namenode.name.dir/name value/opt/hadoop/data/namenode/value /property property namedfs.datanode.data.dir/name value/opt/hadoop/data/datanode/value /property /configuration副本数 3 是 HDFS 的默认值四个 DataNode 撑得住。如果实验环境只开了两个从节点就得改成 2否则 HDFS 会一直处于“副本不足”的告警状态虽然能读写但看着很别扭。mapred-site.xml只有一行关键配置告诉 MapReduce 跑在 YARN 上property namemapreduce.framework.name/name valueyarn/value /propertyyarn-site.xml定 ResourceManager 的位置和 shuffle 服务property nameyarn.resourcemanager.hostname/name valuenode1/value /property property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /propertymapreduce_shuffle这个名字必须一字不差写成mapreduce-shuffle或者shuffle都会导致 Reduce 阶段卡死在 0%。除了这四个文件还有两处必须改。一是hadoop-env.sh里的JAVA_HOME默认是注释掉的不显式写死启动时会报JAVA_HOME is not set。二是 workers 文件老版本叫 slaves里面每行一个从节点主机名写node2、node3、node4不要写 node1主节点不承担 DataNode 角色。改完之后环境变量也别忘了# 追加到 /etc/profile 或 ~/.bashrc export HADOOP_HOME/opt/hadoop export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk写完要source /etc/profile才生效这一步漏掉的话hadoop命令会提示 command not found而你会以为安装失败。3.4 格式化、启动与 wordcount 验证配置齐了接下来是一次性的格式化# 只在 node1 上执行且整个集群生命周期内只执行一次 hdfs namenode -format这条命令会在dfs.namenode.name.dir里生成一个 clusterIDDataNode 启动时靠这个 ID 认主。如果重复执行格式化clusterID 会变而已经跑过的 DataNode 目录里存的还是老 ID两边对不上DataNode 就拒绝启动日志里会写Incompatible clusterIDs。真遇到了怎么办两条路一是把每个 DataNode 的dfs.datanode.data.dir目录清空让它们重新注册二是把 NameNode 的目录也清掉重新格式化一次。前者保数据但操作碎后者简单但数据全丢。实验环境一般选后者生产环境只能选前者。启动顺序是先 HDFS 后 YARN都在 node1 上执行start-dfs.sh start-yarn.sh # 用 jps 分别在四台机器上确认进程 jpsnode1 上应该看到 NameNode、SecondaryNameNode、ResourceManagernode2 到 node4 上应该看到 DataNode 和 NodeManager。少哪个就去对应机器的logs目录翻日志日志文件名里带角色名很好找。集群起来之后先做健康检查# 查看存活节点数、总容量、已用容量 hdfs dfsadmin -report存活节点数应该是 3三个 DataNode如果显示 0问题多半在 hosts 解析或者主机名不一致。确认没问题再跑 wordcount 做端到端验证# 造一份输入数据并上传到 HDFS echo hello hadoop hello spark hello bigdata /opt/data/words.txt hdfs dfs -mkdir -p /input hdfs dfs -put /opt/data/words.txt /input # 提交自带示例作业注意 /output 目录必须不存在 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \ wordcount /input /output # 查看结果 hdfs dfs -cat /output/part-r-00000三个参数分别是输入路径、输出路径和作业名省略后的默认行为。输出目录如果已经存在作业会直接报FileAlreadyExistsException这不是 bug是 MapReduce 的保护机制防止误覆盖上一次的结果。删掉重跑或者换个输出目录名就行。看到hello 3、hadoop 1这样的计数结果说明 HDFS 读写、YARN 调度、MapReduce 执行三条链路全通了。这一步跑通实验一的核心目标就算达成。4. Spark 与存储打通从离线计算到交互式查询Hadoop 跑通之后计算层的下一站是 Spark。它和 Hadoop 的关系不是替代而是叠加HDFS 继续当存储YARN 继续当资源调度Spark 只是换了一种计算引擎把中间结果尽量放在内存里迭代型作业的速度差距就出来了。这一章的重点有两个一是 Spark 怎么挂到已有的 YARN 上二是怎么让它读写云上的对象存储。4.1 部署模式怎么选Spark 有三种常见部署方式选错会让后面所有配置都对不上。local 模式是单机多线程只适合验证代码逻辑不涉及集群实验里用它跑个spark-shell试试语法还行正式作业不能这么跑。standalone 模式自带一套 Master/Worker 调度不依赖 YARN好处是独立、配置简单坏处是集群里同时存在两套资源调度器容易出现“YARN 觉得空闲、Spark 觉得没资源”的尴尬。on YARN 模式把资源申请交给 YARNSpark 只作为客户端提交应用这是实验里选的路子也是把 Hadoop 集群利用率拉满的做法。选 on YARN 之后要理解一个前提Spark 的安装包不需要装在每一个节点上YARN 的 NodeManager 会在需要时把依赖分发下去。但spark-submit所在的机器必须能读到 YARN 和 HDFS 的配置否则它不知道资源管理器在哪。实际做法是把 Spark 装在 node1 上同时把HADOOP_CONF_DIR指向 Hadoop 的配置目录让它借用那份 XML。这样集群拓扑只有一份定义改一处两边都生效。4.2 spark-env.sh 与 spark-defaults.conf 的关键项spark-env.sh管的是进程级的环境变量spark-defaults.conf管的是应用级的默认参数两者不要混着写。# $SPARK_HOME/conf/spark-env.sh export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop export SPARK_MASTER_HOSTnode1 export SPARK_LOCAL_IP192.168.0.10HADOOP_CONF_DIR是这里最关键的一行。不配它spark-submit --master yarn会直接报找不到 YARN 配置或者报Yarn application has already ended让人以为是集群挂了其实是客户端根本不知道去哪找 ResourceManager。SPARK_LOCAL_IP也要写私网 IP不写的话 Spark 可能拿公网 IP 去注册节点之间连不上。spark-defaults.conf里几个参数值得手动写死spark.master yarn spark.submit.deployMode client spark.eventLog.enabled true spark.eventLog.dir hdfs://node1:9000/spark-eventlog spark.serializer org.apache.spark.serializer.KryoSerializer spark.driver.memory 1g spark.executor.memory 2g spark.executor.cores 2deployMode选 clientdriver 跑在提交作业的那台机器上日志直接打在终端里调试方便选 cluster 则 driver 也在集群里终端看不到输出适合正式跑长作业。eventLog打开之后作业历史可以在 History Server 里回看排查失败原因时是唯一的现场记录。内存参数要和机器规格对齐。executor.memory设成 4g 而节点只有 4 GB 物理内存YARN 会因为超出yarn.nodemanager.resource.memory-mb而拒绝分配容器表现出来就是作业一直停在 ACCEPTED 状态、进度条不动。这时候要去 YARN 的资源页面看可用内存别在 Spark 侧反复改参数。启动之后先用spark-shell --master yarn验证一下能进去并且sc.master返回yarn说明客户端和集群接上了。4.3 读写对象存储的两种接法Spark 要处理的数据很多时候不在 HDFS 上而在对象存储里。这一步是实验里“测试与 OBS 互联”对应的内容有两种接法适用场景不同。第一种是 s3a 直连。对象存储兼容 S3 协议Spark 通过 Hadoop 的 s3a 文件系统直接读写不需要额外挂载。# 在 spark-defaults.conf 或提交时用 --conf 传入 spark.hadoop.fs.s3a.access.key 你的AK spark.hadoop.fs.s3a.secret.key 你的SK spark.hadoop.fs.s3a.endpoint obs.cn-north-4.myhuaweicloud.com spark.hadoop.fs.s3a.path.style.access truepath.style.access这一项容易被漏掉。默认是虚拟主机风格bucket.endpoint但很多对象存储实现要求路径风格endpoint/bucket不开这一项会解析到错误的地址症状是域名解析失败而不是权限错误。配好之后先用命令行验证# 用 hadoop 命令列一下桶里的内容能列出来说明鉴权和端点都对 hadoop fs -ls s3a://你的桶名/第二种是把并行文件系统挂载到本地目录Spark 直接按普通路径读写。这种接法的好处是完全不用改配置/mnt/obs/data对 Spark 来说就是个本地目录坏处是多了一层挂载性能和一致性取决于挂载实现大批量随机写不如走 HDFS。# 走 s3a 直连的读写示例 df spark.read.csv(s3a://你的桶名/input/words.csv, headerTrue) df.createOrReplaceTempView(words) result spark.sql( SELECT word, COUNT(*) AS cnt FROM words GROUP BY word ORDER BY cnt DESC LIMIT 10 ) # 结果写回对象存储coalesce(1) 让它输出单个文件方便查看 result.coalesce(1).write.mode(overwrite).csv(s3a://你的桶名/output/top10)coalesce(1)的含义是把分区数降到 1避免输出目录里散着一堆part-00000小文件。代价是大数据量时会退化成单任务只适合看结果不适合生产。4.4 交互式查询Spark SQL 的最小闭环综合实验四讲的是大数据交互式查询落到工具上就是 Spark SQL。它不是另一个系统而是 Spark 之上的一层 SQL 接口底层还是同一套执行引擎。最小闭环是三步建表、查询、看结果。建外部表的好处是删表不删数据反复实验的时候不用每次重新上传。-- 建一张指向 HDFS 目录的外部表字段按分隔符切分 CREATE EXTERNAL TABLE IF NOT EXISTS access_log ( ip STRING, url STRING, status INT, bytes BIGINT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY , STORED AS TEXTFILE LOCATION hdfs://node1:9000/warehouse/access_log;LOCATION要指到具体目录不是文件路径目录里可以放多个文件Spark 会全部当成分区数据读进来。FIELDS TERMINATED BY必须和数据文件里的分隔符一致逗号写成竖线查出来所有字段就都是 NULL。查询可以用spark-sql交互式敲也可以通过spark.sql()在代码里执行# 交互式进入自带 SQL 补全和历史 spark-sql --master yarn-- 按状态码分组看流量分布 SELECT status, COUNT(*) AS req_cnt, SUM(bytes) AS total_bytes FROM access_log GROUP BY status ORDER BY req_cnt DESC;结果对不对先看行数再看聚合值。行数明显偏少多半是分隔符切分后部分行字段数不够被丢弃聚合值明显偏大多半是重复读了一个目录下的多个副本文件。如果要把查询结果开放给外部工具可以起一个 Thrift Server用 JDBC 连进来这一步实验里没有展开但知道有这条路就够了。5. 易错点清单五个一跑就翻车的地方前面三章讲的是“应该怎么做”这一章讲“实际做的时候会怎么错”。这些点有个共同特征报错信息指向的地方往往不是真正出问题的地方。所以每条都按「易漏点 → 为什么漏 → 怎么补」的结构展开重点是最后那一步。5.1 区域与 endpoint 对不上密钥再对也白搭易漏点桶建在 A 区域endpoint 写的是 B 区域或者 endpoint 拼错一个字符。为什么漏这类错误在控制台侧是看不出来的桶明明建好了AK/SK 也是刚下载的人的第一反应永远是“密钥是不是贴错了”。而且报错信息通常只有一句访问失败不告诉你是域名解析的问题。怎么补排查顺序固定成三步。第一步curl -I探测 endpoint 域名能不能解析解析失败就是区域写错或者网络不通第二步用hadoop fs -ls s3a://桶名/验证鉴权认证失败和权限不足是两种错误码第三步才去核对 AK/SK。把这个顺序固化下来能省掉绝大多数瞎折腾。5.2 免密互信看着做了其实没生效易漏点authorized_keys写进去了但目录权限 755、文件权限 644。为什么漏文件内容是对的cat出来能看见公钥视觉上完全正常。sshd 的判断依据是权限不是内容权限太松它会静默忽略整个文件不报任何错。怎么补复制完立刻跑一遍权限修正再用带命令的 ssh 验证而不是只ssh node2看它连不连。看到密码提示第一件事就是查这三个权限位.ssh700、authorized_keys600、id_rsa600。另外要分清公钥和私钥ssh-rsa开头的是公钥可以到处贴没有.pub后缀的是私钥贴出去就是事故。5.3 重复格式化 NameNode集群再也起不来易漏点集群起不来习惯性再跑一次hdfs namenode -format越跑越坏。为什么漏格式化看起来像“重置”直觉上应该能修好一切实际上每次格式化都会生成新的 clusterID而 DataNode 目录里存的还是旧 ID两边不匹配就互相拒绝。怎么补把“只格式化一次”当成铁律。真需要重来要么清空每台机器的 DataNode 数据目录让它重新注册要么把 NameNode 目录也清掉重新格式化。判断依据在日志里看到Incompatible clusterIDs就说明是这个问题别再重复格式化。5.4 集群起来了作业却一直停在 ACCEPTED易漏点jps显示进程齐全HDFS 也能读写但 Spark 作业提交后卡在 ACCEPTED 不动。为什么漏进程在运行不代表资源够用。YARN 能分配的内存和每个节点实际物理内存是两码事spark.executor.memory设得比节点可用内存大容器申请永远满足不了作业就一直排队。怎么补先去 YARN 的资源页面看可用内存和可用 vcore再回头调 Spark 的 executor 参数。经验值是单节点可用内存留 1 GB 给系统剩下的才是 YARN 能分配的。另外别忽略内核参数vm.overcommit_memory设得太保守也会让容器申请被拒。5.5 环境变量只在当前终端生效易漏点export完命令能用了换个终端窗口又报 command not found。为什么漏export是会话级的关掉就没了。而实验里经常要开多个窗口一个跑spark-submit一个看日志另一个改配置很容易在“这个窗口能用那个不能用”的状态里打转。怎么补所有需要长期生效的变量写进/etc/profile.d/下的独立脚本或者写进~/.bashrc写完source一次然后新开一个终端验证。判断标准是“新窗口里echo $HADOOP_HOME有输出”不是当前窗口能用就行。密钥类变量更要注意别为了图省事写进全局 profile那是把 SK 明文摊在所有用户面前。6. 复习清单一条能自己跑通的自测路径复习这份实验报告别从第一页翻到最后一页那样只会把步骤又看一遍。更有效的做法是按“能不能跑通”来验收每一项都有一个可执行的判断命令跑通了打勾跑不通就回到对应章节。阶段验收动作通过标准对应章节资源curl -I https://obs.区域.域名返回 200 或 4032.2资源hadoop fs -ls s3a://桶名/能列出目录内容2.3网络四台机器互ping主机名全部可达3.1互信ssh node2 hostname返回 node2 且不问密码3.2HDFShdfs dfsadmin -report存活节点数等于 DataNode 数3.4计算wordcount 作业 SUCCEEDED输出目录有 part-r-000003.4Sparkspark-shell --master yarn后sc.master返回 yarn4.2查询SELECT COUNT(*) FROM 表名行数与源数据一致4.4具体操作上我建议分三轮每轮只关注一个维度不要把网络、配置、计算混在一起查。第一轮只查“通不通”。四台机器互 ping、互 ssh、endpoint 能 curl 通、对象存储能 ls 出来。这一轮全部用命令行验证不看控制台因为控制台显示“运行中”不代表端口通。第二轮只查“配置对不对”。把四个 XML 文件、hadoop-env.sh、spark-env.sh、spark-defaults.conf挨个打开逐项对照最小改动集。重点核三样主机名和/etc/hosts一致、JAVA_HOME是绝对路径且真实存在、HADOOP_CONF_DIR指向 Hadoop 配置目录而不是安装根目录。第三轮只查“结果对不对”。跑 wordcount 看计数、跑一个GROUP BY看聚合值、把结果写回对象存储再看一遍。这一轮的意义是端到端任何一环断开都会在这里暴露。# 一条命令做完整健康检查粘到 node1 上直接跑 hdfs dfsadmin -report | head -20 \ yarn node -list \ hdfs dfs -ls / \ echo --- 三步都无报错说明存储与调度层是健康的 ---三个命令分别对应 HDFS 节点状态、YARN 节点状态、HDFS 根目录可读。前两个看的是“集群在不在”第三个看的是“权限对不对”。如果前两个正常、第三个报权限错误问题在用户身份而不是集群。最后说一个自己的教训。我刚开始做这类实验的时候习惯把四台机器一口气全开好然后从第一步开始按顺序敲中间不验证。结果经常是敲到第七八步才发现第一步的 hosts 就写错了前面全白做还得回头排查是哪一步开始偏的。从那以后我每次动配置之前都强制走一遍“改一处、验一处”hostname改完立刻pingauthorized_keys写完立刻sshXML 改完立刻hdfs dfsadmin -report。看起来慢实际快得多因为错误永远停在最小范围内。希望帮到你。本文还有配套的精品资源点击获取