四台云主机+对象存储桶：Hadoop/Spark实验链路复现与避坑

简介《华为云大数据实验报告hhu》是一份面向高校大数据课程学习者与云计算入门实践者的实验指导文档围绕在华为云上搭建与管理大数据平台展开帮助读者打通从云主机、对象存储到集群部署与查询分析的完整链路。压缩包共1个文件为4.36MB的docx文档按实验模块编排便于按目录检索与对照操作。内容覆盖实验一云主机实现大数据中的ECS与OBS配置、访问密钥设置及Hadoop集群搭建实验二的云服务大数据实践综合实验一BigData Pro中Hadoop与Spark集群的部署验证以及综合实验四基于Spark SQL或Flink SQL的交互式查询。读者可从中获得节点通信、集群测试、与OBS互联、环境配置与查询分析等具体操作记录和排错参考。目前已有2541人学习适合课程实验、上机实训与云平台入门自学者使用。1. 四台云主机加一个对象存储桶把四个大数据实验串成一条可复现的链路拿到这份资源的人多半是在赶一个「云上大数据」的课程实验要在大数据实验报告里同时交代清楚云主机怎么开、Hadoop 集群怎么搭、对象存储怎么接、Spark 怎么跑查询。单看每个环节都不难难的是四件事连起来之后的衔接处——节点互信没做全、NameNode 格式化了两遍、OBS 的 jar 没进 classpath、YARN 容器被内存掐死任何一处卡住后面全是白干。这份资源的价值不在「讲大数据是什么」而在于它留下了一条从买 ECS、建 OBS 桶、配 hosts、做免密、装 JDK 到跑通 wordcount 和 Spark SQL 的完整命令链和配置片段你可以照着抄也可以拿它当排错时的对照物。适合两类人一类是要在一两天内把实验环境和报告一起交出去的学生另一类是想在云上搭一套最小可用 Hadoop/Spark 集群、又不想从零翻官方文档的工程师。先说一句可能不太中听的这份报告原文里贴了明文的访问密钥、完整的公钥和四台机器的内网 IP。这些对复现没有任何帮助反而属于典型的血泪教训式泄露。你拿到手第一件事应该是把它们打码第二件事是去控制台把对应的密钥删掉重发一对。下面的内容会把所有凭据换成占位符配置项一个不少密钥一个不写。2. 节点规划与系统基线hosts、免密、防火墙这三件事必须先做对集群搭建里 80% 的「玄学问题」都出在正式装 Hadoop 之前的那半小时。很多人打开四台机器就开始解压安装包结果 DataNode 起不来、SSH 还要输密码、Web UI 打不开回头一个个排查时间全耗在这。我一般的顺序是规划角色 → 定主机名 → 写 hosts → 做全互联免密 → 关防火墙并对时。这五步做完再碰 Hadoop后面会顺很多。2.1 为什么是四节点而不是一台全装一台机器上把 NameNode、DataNode、ResourceManager、NodeManager 全塞进去技术上能跑但你会失去两个关键观察点一是副本因子没法真实生效dfs.replication 设成 3 也只是一份数据二是 YARN 的资源调度看不出来容器分配、队列、节点黑名单这些行为全被掩盖。四台1 主 3 从是成本最低的「能看到分布式行为」的配置也是多数实验报告要求的最小拓扑。角色主机名建议规格进程Masternode14 vCPU / 8 GB / 系统盘 40 GBNameNode、SecondaryNameNode、ResourceManagerWorkernode24 vCPU / 8 GB / 系统盘 40 GBDataNode、NodeManagerWorkernode34 vCPU / 8 GB / 系统盘 40 GBDataNode、NodeManagerWorkernode44 vCPU / 8 GB / 系统盘 40 GBDataNode、NodeManager四台机器务必放在同一个 VPC、同一个子网、同一个安全组里走内网通信。这一点不是建议是硬要求如果节点之间用公网 IP 互相注册DataNode 上报给 NameNode 的地址会是公网地址跨节点传数据会绕出去再绕回来轻则慢到无法接受重则因为安全组规则不匹配直接连不上。买机器的时候顺手把内网 IP 记下来后面 hosts 只写内网地址。2.2 主机名与 /etc/hosts别让 Hadoop 去猜每台机器先设主机名再写统一的 hosts。四台机器的 /etc/hosts 内容必须完全一致否则某个节点解析不到别人表现就是「能 ping 通 IP、ping 不通主机名」。改完主机名要重新登录一次 shell否则提示符还是旧的。# 在各自节点上执行node1~node4 按角色替换 hostnamectl set-hostname node1 # 四台机器都要写内容完全相同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 # 逐个验证四台机器上都要能解析出正确地址 for h in node1 node2 node3 node4; do ping -c1 $h /dev/null echo $h ok; done这里的 192.168.0.x 是内网网段示例实际以控制台里每台机器的私网地址为准。注意不要写成 127.0.0.1 或者公网地址。另外有些镜像自带 cloud-init 生成的 hostname 映射会把 node1 指向 127.0.0.1那种情况下你的追加行要放在文件靠前的位置或者直接把自带的那行删掉否则 Hadoop 会连到自己身上。2.3 全互联免密为什么不能只做单向Hadoop 的启动脚本有个容易被忽略的行为在 node1 上执行 start-dfs.sh它会通过 SSH 到各个 worker 上拉起 DataNode而 SecondaryNameNode 又可能需要反向连回。只做 node1 → node2/3/4 的单向免密某些版本能启动但一旦涉及 distcp、跨节点脚本分发就会卡在密码提示上。既然四台机器都要互信那就一次做全。常见做法是每台机器生成密钥把所有公钥汇总成一个 authorized_keys 再分发回去而不是挨个执行 ssh-copy-id 做 12 次。# 四台机器分别执行一路回车不要设密码短语 ssh-keygen -t rsa -b 2048 -N -f /root/.ssh/id_rsa # 每台机器执行把本机公钥临时汇总到 node1 ssh node1 mkdir -p /root/.ssh/keys # 在 node1 上收集如果 node1 到其他节点此时还没免密就手工拷贝文件 cat /root/.ssh/id_rsa.pub /root/.ssh/keys/all.pub # node1 上把汇总文件分发到四台机器的 authorized_keys for h in node1 node2 node3 node4; do scp /root/.ssh/keys/all.pub $h:/root/.ssh/authorized_keys ssh $h chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys done # 验证四台机器交叉 ssh做到完全不提示密码 ssh node1 for h in node1 node2 node3 node4; do ssh -o BatchModeyes $h hostname; done参数含义里最要紧的是-N 空密码短语和最后的chmod 600。权限是免密失败的头号原因SSH 对 authorized_keys 和 .ssh 目录的权限极其挑剔755 或 644 都会被拒绝而且日志只给你一句Permission denied (publickey)不说为什么。BatchModeyes的作用是强制非交互一旦需要密码就直接失败比手工测试可靠得多——否则脚本会静静地卡在密码提示那里你以为跑完了。2.4 防火墙、安全组与时间同步实验环境里最常见的处理是直接关掉 firewalld 和 SELinux省得跟端口较劲。但云上还有一层安全组关掉系统防火墙不等于端口放通这点经常被漏掉。NameNode 的 9000、YARN 的 8088、HDFS Web 的 9870、Spark 的 8080这几台机器之间要互通安全组里加一条「同安全组内全部放行」最省事。# 四台机器都执行 systemctl stop firewalld systemctl disable firewalld setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config # 时间同步集群节点时间差过大会导致 Kerberos、日志排查全乱 yum install -y chrony systemctl enable --now chronyd chronyc sources -vSELinux 那条 sed 改的是配置文件setenforce 0只对当前生效重启后会按配置文件来两条要一起做。chrony 装完用chronyc sources看一眼有没有^*标记的同步源如果全是?说明出网受限实验环境里影响不大但排查日志时心里要有数时间戳对不齐的时候别急着怀疑代码。3. Hadoop 集群搭建从 JDK 到 wordcount 出结果到这里四台机器已经是「互相认识、互相能免密登录、端口全通」的状态了剩下的就是把软件铺上去、配置写对、启动验证。这一章按执行顺序走每一步之后都给了「应该看到什么」对照不上就停下来查别硬着头皮往下装——带着错误的 NameNode 去格式化后面只会更乱。3.1 JDK 与目录约定Hadoop 对 JDK 版本敏感生产上常见的组合是 JDK 8 配 Hadoop 3.x实验环境用发行版自带的 OpenJDK 8 就够。安装位置统一到 /opt四台机器路径必须一致否则后面环境变量一改就出岔子。# 四台机器执行 yum install -y java-1.8.0-openjdk-devel java -version # 应输出 1.8.0_xxx # 统一软件目录 mkdir -p /opt/bigdata cd /opt/bigdata # Hadoop 安装包用 wget 从镜像站拉或者本地上传注意选带 hadoop 前缀的 tar.gz tar -xzf hadoop-3.x.x.tar.gz -C /opt/bigdata ln -s /opt/bigdata/hadoop-3.x.x /opt/bigdata/hadoop # 环境变量四台机器保持一致 cat /etc/profile.d/bigdata.sh EOF export JAVA_HOME/usr/lib/jvm/jre-1.8.0-openjdk export HADOOP_HOME/opt/bigdata/hadoop export SPARK_HOME/opt/bigdata/spark export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$SPARK_HOME/bin export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop EOF source /etc/profile.d/bigdata.shJAVA_HOME一定要用readlink -f $(which java)反查真实路径后再填/usr/lib/jvm/jre-1.8.0-openjdk在很多发行版上是个软链而 Hadoop 的启动脚本对软链的容忍度不高会报JAVA_HOME is not set。我一般直接readlink -f /usr/bin/java | sed s:/bin/java::拿到绝对路径写进去。HADOOP_CONF_DIR 这个变量是为 Spark 准备的Spark 找 Hadoop 配置就是靠它现在设好后面能省一次排查。3.2 四个 XML 配置逐项拆配置目录是$HADOOP_HOME/etc/hadoop。四个文件里core 定全局默认文件系统hdfs 定副本和存储路径yarn 定资源调度mapred 定计算框架。每改一个文件都要四台同步我习惯在 node1 上改完统一 scp 分发。!-- core-site.xml -- configuration property namefs.defaultFS/name valuehdfs://node1:9000/value /property property namehadoop.tmp.dir/name value/opt/bigdata/data/tmp/value /property property namefs.trash.interval/name value1440/value /property /configurationfs.defaultFS写的是逻辑名 端口用主机名而不是 IP这样将来迁移节点只改 hosts。9000 是 NameNode 的 RPC 端口被占用了就换 8020改完记得同步到所有客户端配置。hadoop.tmp.dir千万别留在 /tmp 下系统重启或定时清理任务会把它删掉表现是集群莫名其妙起不来、元数据全丢这个坑我踩过不止一次。!-- hdfs-site.xml -- configuration property namedfs.replication/name value3/value /property property namedfs.namenode.name.dir/name valuefile:///opt/bigdata/data/dfs/name/value /property property namedfs.datanode.data.dir/name valuefile:///opt/bigdata/data/dfs/data/value /property property namedfs.namenode.secondary.http-address/name valuenode1:9868/value /property /configuration副本数 3 对应三台 worker正好一个不浪费。file:///前缀不能省省了 Hadoop 会按默认文件系统去解析这个路径结果路径跑到 HDFS 上去了报错信息还很绕。三个 worker 的 data.dir 是本地盘路径四台机器上都要提前 mkdir 好目录权限给 root。!-- yarn-site.xml -- configuration property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property property nameyarn.resourcemanager.hostname/name valuenode1/value /property property nameyarn.nodemanager.resource.memory-mb/name value6144/value /property property nameyarn.scheduler.maximum-allocation-mb/name value6144/value /property property nameyarn.nodemanager.env-whitelist/name valueJAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_MAPRED_HOME/value /property /configuration内存这两个参数是 8 GB 机器的经验值给 NodeManager 留 6 GB剩下的留给系统和 DataNode。env-whitelist是 Hadoop 3.x 之后必须显式配的不配会出现容器里找不到 JAVA_HOME、任务一启动就失败日志里只有一句Container exited with a non-zero exit code 1非常不友好。!-- mapred-site.xml -- configuration property namemapreduce.framework.name/name valueyarn/value /property property nameyarn.app.mapreduce.am.env/name valueHADOOP_MAPRED_HOME/opt/bigdata/hadoop/value /property property namemapreduce.map.env/name valueHADOOP_MAPRED_HOME/opt/bigdata/hadoop/value /property property namemapreduce.reduce.env/name valueHADOOP_MAPRED_HOME/opt/bigdata/hadoop/value /property /configuration框架设成 yarn 之后那三条 env 必须补上否则任务容器里找不到 mapreduce 的 jar 包。这一条在很多老教程里没有因为 Hadoop 2.x 时期有默认值兜底换到 3.x 就翻车。还有一个容易被版本差异坑到的点worker 列表文件在 Hadoop 2.x 叫slaves3.x 叫workers。里面一行一个主机名node1 通常不写进去它是 master不跑 DataNode写 node2/3/4 三行即可。3.3 格式化只能做一次# 仅在 node1 上执行且只执行一次 hdfs namenode -format # 启动 HDFS脚本会自动 ssh 到各 worker 拉起 DataNode start-dfs.sh # 启动 YARN start-yarn.sh # 验证 jps hdfs dfsadmin -reportjps在 node1 上应该看到 NameNode、SecondaryNameNode、ResourceManager 三个进程node2~4 上应该看到 DataNode、NodeManager 两个。少一个就去看对应节点的日志路径在$HADOOP_HOME/logs/文件名后缀是进程名先看最后 50 行。hdfs dfsadmin -report是比 jps 更硬的证据它会列出 Live datanodes 的数量和每台的容量。数量是 3、状态是 In Service才算集群真的组起来了。如果显示 0或者报告里有 Dead datanodes回去查 hosts 解析和防火墙别在别处浪费时间。关于格式化必须强调hdfs namenode -format会生成一个新的 clusterID 并清空 name 目录。第二次执行后三个 DataNode 上存的还是旧 clusterID 的数据块握手时对不上表现是 DataNode 起来几秒后自动退出日志里写Incompatible clusterIDs。解决办法只有两个要么删掉所有节点上的 data 目录重新格式化要么手工把 clusterID 对齐。所以我一般格式化前先ls /opt/bigdata/data/dfs/name确认目录是空的格式化后立刻hdfs dfsadmin -report记录下来后面出问题第一时间知道是不是又格式化了。3.4 wordcount 跑通与结果解读# 造一份输入数据 hdfs dfs -mkdir -p /input/wordcount echo -e hadoop spark hdfs\nspark yarn hdfs\nhdfs namenode /tmp/words.txt hdfs dfs -put /tmp/words.txt /input/wordcount/ # 跑自带的 wordcount 示例 hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \ wordcount /input/wordcount /output/wc1 # 看结果 hdfs dfs -cat /output/wc1/part-r-00000输出目录必须不存在Hadoop 不会覆盖已有路径这是防误删的设计报FileAlreadyExistsException时换个目录名就行别去 rm -r 生产路径。part-r-00000里的r表示 reduce 阶段的输出如果只看到part-m-00000说明 reduce 数是 0检查输入是不是太小或者配置里mapreduce.job.reduces被设成了 0。跑通之后去 8088 端口看 YARN 的任务页面能看到这个 application 的 Map 和 Reduce 各几个、各在哪个节点上跑、耗时多少。这一步比看输出文件更有价值它是「集群真的在协同工作」的最直接证据也是实验报告里最有说服力的一张截图。4. OBS 对接AK/SK、并行文件系统与一次连通性验证HDFS 解决的问题是「集群内怎么存」对象存储解决的是「集群外怎么喂数据和怎么长期留」。把两者接上才能做「数据放对象存储、计算在集群里跑」这种真实场景。这一章的重点不在创建桶的按钮在哪而在配置项的语义和那几个必然会踩的坑。4.1 对象存储和 HDFS 的边界先划清两者不是替代关系。HDFS 是块存储思路适合顺序读写大文件、支持追加和多副本本地化计算对象存储是扁平命名空间容量近乎无限、按量计费、支持 HTTP 直读但 rename 操作在底层是 copy delete小文件多的时候性能会掉得很厉害也不支持随机写。所以合理的用法是原始数据、历史归档、Spark 读取的大宽表放对象存储中间结果、shuffle 数据、需要频繁重命名的临时目录放 HDFS。我见过有人把 shuffle 目录配到对象存储上任务跑了四十分钟没出结果查下来全是 rename 卡住——这不是配置错是选型错。实际配置里还有一个概念要分清普通对象桶和并行文件系统。前者走 S3 风格接口适合 Spark/Hive 直接读后者是挂载成 POSIX 文件系统用适合需要文件语义的场景。做 Hadoop 对接实验用前者配fs.obs.impl更直接用后者就要走 obsfs 挂载多一层依赖。4.2 建桶、拿密钥、配访问方式控制台上建桶的时候区域要选得和 ECS 一致跨区域的访问延迟和流量费用都很难看。桶名全局唯一建完把 endpoint 抄下来形如obs.region.xxx.com注意这里要用不带桶名的那条。访问密钥从控制台的「我的凭证」里创建下载下来的 csv 里包含 Access Key Id 和 Secret Access KeySecret 只显示一次丢了只能删了重建。这份 csv 绝对不能进 git、不能贴进实验报告、不能截图发群里。同一对密钥可以用「临时凭证 委托」的方式下发给程序但那属于进阶用法实验环境里直接把密钥写进配置文件也行前提是机器只有你自己用。稳妥一点的做法是用环境变量注入至少别落到提交物里。4.3 让 Hadoop 认识 obs:// 这个 schemeHadoop 默认只认 hdfs、file 这几种 scheme看到obs://会直接抛No FileSystem for scheme obs。要让它认识需要两样东西对接 jar 包和 fs.obs.* 系列配置。# 1) 把对象存储的 hadoop 对接 jar含依赖放到公共 classpath # 注意 Hadoop 3.x 用 share/hadoop/tools/lib部分版本用 common/lib两个都放一份最稳 cp obs-hadoop-*.jar $HADOOP_HOME/share/hadoop/tools/lib/ cp obs-hadoop-*.jar $HADOOP_HOME/share/hadoop/common/lib/ # 2) 同步到四台机器 for h in node2 node3 node4; do scp $HADOOP_HOME/share/hadoop/tools/lib/obs-hadoop-*.jar \ $h:$HADOOP_HOME/share/hadoop/tools/lib/ donejar 包版本必须和 Hadoop 大版本对齐2.x 的包丢进 3.x 会在类加载阶段就报NoSuchMethodError那种报错信息指向的类名和实际问题毫无关系非常费时间。放完 jar 要重启 HDFS 和 YARN因为 classpath 是在 JVM 启动时确定的。!-- core-site.xml 追加 -- 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.region.xxx.com/value /property property namefs.obs.buffer.dir/name value/opt/bigdata/data/obs-buffer/value /propertyfs.obs.impl是 scheme 到实现类的映射写错了不会报错只会在真正访问 obs:// 时才失败。AK/SK 这里用了${env.OBS_AK}的写法Hadoop 支持从环境变量取值这样配置文件本身可以进版本库而密钥不进。注意环境变量要在启动脚本能读到的位置设置比如写进/etc/profile.d/bigdata.sh后重新登录否则守护进程读不到。buffer.dir是上传大文件时的本地暂存目录空间要比单个最大文件大一些默认值在 /tmp 下同样有被清理的风险。4.4 连通性测试与一次 Spark SQL 交互式查询验证分两层先看能不能列目录再看能不能读数据算结果。第一层不通就别写 SQL。# 第一层列桶、传文件、读回来 hadoop fs -ls obs://your-bucket/ echo hello obs /tmp/t.txt hadoop fs -put /tmp/t.txt obs://your-bucket/demo/ hadoop fs -cat obs://your-bucket/demo/t.txt # 第二层把 HDFS 上的结果直接拷到对象存储 hadoop distcp /output/wc1 obs://your-bucket/output/wc1distcp是跨文件系统的标准搬运工具比hdfs dfs -cp靠谱得多后者在跨 scheme 时偶发权限和并发问题。跑完去控制台的对象列表里确认文件真的在别只信命令行的返回码。交互式查询这一层用 Spark SQL 直接读对象存储上的数据最省事-- 启动spark-sql --master yarn --deploy-mode client CREATE EXTERNAL TABLE IF NOT EXISTS demo_words ( line STRING ) ROW FORMAT DELIMITED FIELDS TERMINATED BY \t LOCATION obs://your-bucket/demo/; SELECT line, length(line) AS len FROM demo_words ORDER BY len DESC LIMIT 10;EXTERNAL很关键它让元数据挂在 Hive Metastore 上而数据仍在对象存储里删表不会删数据。LOCATION指向桶内目录末尾要不要斜杠取决于实现建议统一带斜杠能少一类找不到文件的报错。这条 SQL 跑通说明「对象存储 → 计算引擎 → 结果」这条链路是通的实验报告里综合实验那部分的证据链也就齐了。5. 避坑与排查五条真金白银的记录下面这五条基本覆盖了复现过程中 90% 的卡点。每一条我都按「现象 → 原因 → 解决」写照着对号入座比从头读日志快得多。5.1 DataNode 起来几秒就退出日志写 Incompatible clusterIDs现象jps里 DataNode 时有时无hdfs dfsadmin -report显示 live datanodes 为 0看 DataNode 日志能看到Incompatible clusterIDs in ... namenode clusterID xxx; datanode clusterID yyy。原因namenode 被格式化了不止一次。每次 format 都会生成新 clusterID 并写进 name 目录而 DataNode 的 data 目录里记的还是上一次的握手时校验不通过就直接退出。解决删掉所有节点上的dfs/data目录然后在 node1 上重新 format 一次再启动。要根治这个问题就得把 format 当成一次性操作格式化前确认 name 目录为空格式化后立刻把 clusterID 记下来后面任何异常先核对这个值。5.2 免密配完了ssh 还是要密码现象手工ssh node2能进但脚本里ssh -o BatchModeyes node2报Permission denied (publickey)或者 Hadoop 启动脚本卡在密码提示。原因三个高频原因——authorized_keys 权限不是 600、.ssh 目录权限不是 700、公钥内容被换行符或多余空格破坏。还有一种少见情况只做了 node1 到其他节点的单向而某些脚本需要反向登录。解决先ls -ld /root/.ssh ls -l /root/.ssh/authorized_keys核对权限再wc -l看公钥行数是不是等于机器数。权限问题用两行 chmod 就能修好但要注意 SELinux 开着的时候即使权限对了也会被拒getenforce确认一下是 Disabled。5.3 集群内部能通Web UI 从浏览器打不开现象节点之间 ping、ssh、hdfs 命令全正常但在本地浏览器访问 9870 或 8088 一直转圈。原因两层防火墙。系统层的 firewalld 关了但云平台的安全组没放行入方向端口公网流量根本到不了机器。另一种情况是绑定的地址是内网 IP而你在用公网地址访问。解决安全组里按需放行 9870、8088、8080、9000 的入方向来源限制成自己的出口 IP。放行之后如果还打不开ss -lntp | grep 9870看监听地址如果是 127.0.0.1 或者内网地址说明服务只绑了那一块网卡得从配置层面调。5.4 访问 obs:// 报 No FileSystem for scheme obs现象hadoop fs -ls obs://bucket/直接抛异常堆栈里说找不到对应 scheme 的文件系统实现。原因三种可能——jar 包没放、放错了目录、放了但没重启。Hadoop 的 classpath 在 JVM 启动时固定热拷贝 jar 进去是不生效的。还有一种是把 jar 只放到了 node1其他节点上的任务容器里找不到。解决hadoop classpath | tr : \n | grep -i obs确认 jar 在搜索路径里不在就把 jar 放到$HADOOP_HOME/share/hadoop/common/lib并全节点分发然后stop-all.sh start-all.sh。如果 jar 在位还报同样的错用hadoop fs -Dfs.obs.implorg.apache.hadoop.fs.obs.OBSFileSystem -ls obs://bucket/手工指定一次能通说明是 core-site.xml 没同步到所有节点。5.5 任务跑一半容器被杀日志只有 exit code 1现象MapReduce 或 Spark 任务提交后页面上一片红容器状态失败日志里最有用的一句是Container exited with a non-zero exit code 1看不出根因。原因八成都不是代码问题是资源。容器申请的内存超过 NodeManager 可用内存、或者物理内存超用被系统 OOM Killer 干掉都会表现成这个。另外 env-whitelist 没配导致容器里读不到 HADOOP_MAPRED_HOME也是同一个现象。解决先看 NodeManager 日志里的Killing container前后几行确认是超内存还是启动失败。超内存就调小mapreduce.map.memory.mb同时把yarn.nodemanager.resource.memory-mb和yarn.scheduler.maximum-allocation-mb对齐——这两个值不一致时调度器放行、节点拒绝报错信息会互相矛盾。启动失败就去容器日志目录看 stderr通常能看到具体缺哪个环境变量。6. 复现验收清单与三个能省半天的技巧一套集群搭完之后不要凭感觉认为「应该没问题了」。我习惯跑一份固定清单每一项都有明确的期望输出对不上就不算完成。这份清单在实验报告里也能直接当验收章节用。检查项命令期望结果进程完整jps四台分别执行master 三个进程worker 两个进程节点注册hdfs dfsadmin -reportLive datanodes 3全部 In Service副本生效hdfs fsck /input -files -blocks每个块 3 个副本无 corruptYARN 资源yarn node -list三个节点 RUNNING内存数字合理计算正确wordcount 输出词频与输入一致对象存储连通hadoop fs -ls obs://bucket/正常列出无异常堆栈交互查询spark-sql 建外表后 count返回行数与源数据一致三个技巧都是被坑出来的。第一个是「小数据先通管道」。不管是 wordcount 还是 Spark SQL先用几十字节的输入跑通全链路再换真实数据。大数据任务失败时你很难分清是数据有问题、资源不够、还是配置错了小数据能跑通就排除了配置问题剩下的范围会小很多。我一般会准备一个三行的文本文件放在 /tmp任何时候怀疑链路有问题先拿它跑一遍。第二个是「日志先看 application再看 container」。YARN 上的任务失败yarn logs -applicationId application_xxx能一次性把 AM 和所有容器的日志拉下来比挨个节点翻目录快得多。如果集群没开日志聚合那就得去$HADOOP_HOME/logs/userlogs/下面找按 application 和 container 的编号逐层进。养成先定位 application 再往里钻的习惯能省掉大量「在错误的地方看错误的日志」的时间。第三个是「关键节点做快照」。四台机器全部配好、验证通过之后趁着干净状态给每台做个镜像或者快照。后面不管怎么折腾坏了回滚回来十分钟就能重来。这个习惯在实验环境里尤其值你总会在某个下午想试试改副本数或者换调度器改完起不来没有快照就得从头再来一遍两小时的搭建流程。最后说一个教训。我第一次做这套东西的时候图省事只在一台机器上改了配置启动脚本一跑三个 worker 用的还是旧参数报错信息完全指不到配置不同步这个方向我盯着 NameNode 日志看了快两个小时。从那以后我每次改完配置都强制走一遍for h in node1 node2 node3 node4; do ssh $h md5sum $HADOOP_HOME/etc/hadoop/core-site.xml; done四个哈希一致才继续下一步。多花十秒省下两小时这笔账怎么算都值。希望帮到你。本文还有配套的精品资源点击获取