简介《鲲鹏云大数据实验docx》是一份面向大数据入门与云计算实践学习者的实验报告重点演示在华为云鲲鹏环境中采购ECS、OBS并搭建Hadoop集群的完整过程。内容从云主机与对象存储准备、AK/SK获取讲起延伸到节点互信、无密码登录、目录规划、Hadoop核心配置、NameNode初始化与HDFS启动并记录了Java家目录配置错误后的重新分发与修正思路便于读者理解云上大数据基础设施的部署和排错流程。压缩包共1个docx文件约2.52MB以图文实验记录为主适合按步骤复现与课程实验参考。目前已有893人学习可帮助读者建立从云资源申请到集群联调的实践认知并积累配置同步、服务启动与问题定位经验。1. 一份带着改错痕迹的实验记录比标准教程更有用鲲鹏云大数据实验报告这类文档最容易踩的坑在于中间那几行看起来像笔误的记录而不在开头。比如同一个JAVA_HOME在三个节点上改了三次namenode -format执行了两遍scp分发重做了两轮。把这些痕迹串起来其实就是一条完整的 ARM 架构 Hadoop 集群落地路径开 ECS、建对象存储桶、拿 AK/SK、配三节点互信、写四个 XML、分发、格式化、起 HDFS。它适合两类人一类是课程实验要跑通并交报告的学生另一类是第一次在云上给大数据环境做验证、不想在环境准备上耗掉一整天的后端和运维。下面我按自己复现的顺序把这份文档里能抄的配置、必须改的参数和绕不开的坑一项一项拆开。2. 云上底座与集群骨架三台 ECS、一个桶和一次双向互信集群能不能起来八成取决于开工前那半小时的准备。买机器、开桶、配 hosts、做免密这四件事任何一步偷懒后面都会以启动脚本卡住不动DataNode 起来又秒退的形式还回来。这一章按操作顺序走每一步都给出可直接执行的命令参数怎么改也一并说清楚。2.1 三台 ECS 的规格、架构与安全组节点规划上三台机器是最低配的组合一台兼作 NameNode 和 ResourceManagernode-0001两台作 DataNode 和 NodeManager。规格建议 4 核 16G 起步NameNode 那台内存可以给到 8G 以上因为hdfs namenode -format和后续的元数据操作都吃堆内存。系统盘 40G 只放系统另挂一块 100G 数据盘挂到/homeHadoop 的安装目录、临时目录、数据目录全放在这块盘上理由是集群出问题时可以直接卸载数据盘重来不动系统。架构这点必须提前想清楚。鲲鹏平台是 aarch64也就是 ARMv8所有二进制组件都要对得上OpenJDK 要装aarch64版本Hadoop 官方 tar 包本身是架构无关的 Java 字节码可以通用但它自带的libhadoop.so是 x86 编译的在 ARM 上解压后会看到一条Unable to load native-hadoop library for your platform的 WARN。这条警告不影响功能只是压缩和 CRC 校验走纯 Java 实现性能略低真要消除得自己编译 native 库实验场景没必要。安全组是另一个高频翻车点。默认只开 22 端口集群内部通信和 Web UI 全被挡在外面表现为命令行都正常浏览器打不开。按下面这张表放行源地址尽量限定在自己的出口 IP别图省事开 0.0.0.0/0。端口用途说明22SSH免密登录与start-dfs.sh远程拉起进程8020NameNode RPCfs.defaultFS里配的端口客户端靠它连50070NameNode Web UIHadoop 2.x 默认3.x 才改成 987050075DataNode Web UI排查 DataNode 存活状态用8088YARN ResourceManager UI看任务队列和容器分配8042NodeManager Web UI看单节点资源上报这里提前说一个坑很多网上教程写的是 9870那是 Hadoop 3.x 的默认端口2.8.3 上还是 50070。照着 3.x 的端口去放行页面永远打不开还会误以为是服务没起来。2.2 OBS 桶、并行文件系统与 AK/SK 的取法对象存储这块要做两件事建桶、拿凭证。建桶时选好区域区域一旦确定后面endpoint就只能填这个区域的访问域名跨区域填会报UnknownHost或者连接超时。如果打算让 Hadoop 像访问本地目录一样访问对象存储部分场景需要 POSIX 语义再建一个并行文件系统普通桶用于distcp搬运数据已经够用。桶建好后进桶概览页能看到两个访问域名一个是 IPv4 地址一个是双栈地址。文档里把两个都记下来了实际用的时候先ping或curl -I试一下哪个通就用哪个。云上网络环境不同双栈域名在纯 IPv4 出口的机器上解析会失败。AK/SK 的获取路径是控制台创建 IAM 用户勾选编程访问创建完成后浏览器会一次性下发一个credentials.csv里面就是三列User Name,Access Key Id,Secret Access Key。这里有个必须强调的点Secret Access Key 只在下发的那一次可见关掉页面就再也拿不到了只能删了重建。真实环境里绝对不要把 AK/SK 明文贴进报告或者提交到代码仓库实验报告里做脱敏处理写成YOUR_AK/YOUR_SK就行。# 把下载到的凭证文件读出来只在本机终端用不要写进任何配置文件后提交 awk -F, NR2{print AK$2\nSK$3} credentials.csv # 验证凭证和 endpoint 是否匹配能列出桶就说明通了 # 注意 endpoint 不带 https:// 前缀区域要和桶所在区域一致 obsutil ls -s上面第一行用awk按逗号切分跳过表头取第二行避免手工复制时把引号带进去。第二行是obsutil的连通性检查-s表示只列桶名。如果这一步报 403八成是 AK/SK 抄错了或者用户没有对应桶的权限报UnknownHost就是 endpoint 的区域填错了。凭证没问题再往下走否则后面 Hadoop 侧报的错会把你引到完全无关的方向。2.3 hosts 与免密互信三台机器两两通才算配完/etc/hosts必须在三个节点上写成完全一致的内容用内网 IP不要用公网 IP。公网 IP 走的是云厂商的 NAT 映射A 机器用公网 IP 连 B 机器流量会绕出去再绕回来延迟高而且部分安全组策略下根本不通。示例里我统一用 10.0.0.x 段实际以控制台里显示的内网地址为准。# 三个节点都要执行内容必须逐字一致 cat /etc/hosts EOF 10.0.0.11 node-0001 10.0.0.12 node-0002 10.0.0.13 node-0003 EOF # 验证三个名字都要能解析到地址不能有一个失败 for h in node-0001 node-0002 node-0003; do getent hosts $h; donegetent hosts比ping更适合做校验因为它只查解析不做连通性测试输出快且不受 ICMP 策略影响。三个名字必须都能回显少一个后面的start-dfs.sh就会卡在那台机器上。免密互信是这一步最容易做成半成品的地方。ssh-copy-id只把本机公钥推到目标机也就是说 A 到 B 通了B 到 A 还是需要密码。而start-dfs.sh在 NameNode 上执行时会 SSH 到slaves文件里列出的每一个节点包括它自己任何一条单向链路不通都会导致启动中断。# 在 node-0001 上生成一对无口令密钥-N 表示空 passphrase ssh-keygen -t rsa -b 2048 -N -f /root/.ssh/id_rsa # 把公钥分发到三台机器含自己实现全互联 for h in node-0001 node-0002 node-0003; do ssh-copy-id -o StrictHostKeyCheckingno -i /root/.ssh/id_rsa.pub root$h done # 三台机器上分别验证都应免密返回主机名不应出现 password 提示 ssh node-0001 hostname; ssh node-0002 hostname; ssh node-0003 hostname-t rsa -b 2048指定 RSA 算法和 2048 位长度兼容性最好-N 是空口令因为自动化脚本没法交互输密码。-o StrictHostKeyCheckingno跳过首次连接的指纹确认否则脚本会停在yes/no那里等人。分发完一定要在三个节点上分别验一遍只验 node-0001 是不够的因为start-yarn.sh和stop-dfs.sh走的可能是另一条链路。2.4 目录规划四类目录一次建齐Hadoop 的目录混乱是后期排查困难的主要原因。按用途分成四类统一放在/home下data/buf放hadoop.tmp.dir临时文件data/name放 NameNode 元数据data/data放 DataNode 块数据nm/localdir放 YARN 容器本地化文件。前三个目录是 HDFS 的最后一个属于 YARN混在一起会导致格式化时误删容器日志。# 三个节点都执行目录属主都是 root因为服务以 root 启动 mkdir -p /home/modules/data/buf \ /home/modules/data/name \ /home/modules/data/data \ /home/nm/localdir # 确认目录已建好且磁盘挂载在 /home 上 df -h /home ls -ld /home/modules/data/*df -h /home这一步别省。如果数据盘没挂上这些目录会悄悄建在系统盘上等到 DataNode 写入几十 G 数据把根分区撑满机器直接 SSH 不上去那时候再救就麻烦了。3. 配置文件逐项拆解core-site、hdfs-site、yarn-site 与 slaves 怎么填配置目录在$HADOOP_HOME/etc/hadoop下。四个 XML 加一个slaves看似不多但每一项填错都会在启动阶段以完全不同的报错形式出现。这一章按文件逐个过把每项参数的作用、取值范围和常见误填讲透最后单独说JAVA_HOME因为它是这份实验记录里翻车最多的一处。3.1 core-site.xmlNameNode 地址、tmp 目录与 OBS 四要素core-site.xml是整个集群的入口配置最先被加载。核心是三个东西默认文件系统指向哪、临时目录放哪、对象存储怎么接。?xml version1.0? configuration !-- 客户端默认访问的 HDFS 入口端口要和安全组放行的一致 -- property namefs.defaultFS/name valuehdfs://node-0001:8020/value /property !-- 所有临时文件的根目录格式化前必须为空 -- property namehadoop.tmp.dir/name value/home/modules/data/buf/value /property !-- OBS 接入实现类、AK、SK、endpoint 四项缺一不可 -- property namefs.obs.impl/name valueorg.apache.hadoop.fs.obs.OBSFileSystem/value /property property namefs.obs.access.key/name valueYOUR_AK/value /property property namefs.obs.secret.key/name valueYOUR_SK/value /property property namefs.obs.endpoint/name valueobs.region-id.your-cloud-domain/value /property /configurationfs.defaultFS里的主机名必须是/etc/hosts里能解析的名字写 IP 也能跑但改了机器就很难维护。hadoop.tmp.dir建议指向数据盘因为它会承载dfs.namenode.name.dir未显式指定时的默认值格式化失败重来时第一个要清的就是它。OBS 那四项里fs.obs.impl是最容易被漏掉的。只配 AK/SK 和 endpoint 而不配实现类执行hadoop fs -ls obs://bucket会报No FileSystem for scheme obs因为 Hadoop 根本不知道该用哪个类去解析obs://协议。另外这四项要生效hadoop-huaweicloud的 jar 包必须出现在$HADOOP_HOME/share/hadoop/tools/lib或common/lib下并且三个节点都要有否则只有 NameNode 能访问 OBSDataNode 读写时会报类找不到。验证办法是hadoop classpath | tr : \n | grep huaweicloud能打出来就说明加载路径没问题。3.2 hdfs-site.xml副本数、元数据目录与数据目录HDFS 侧的配置集中在三件事冗余几份、元数据写哪、数据块写哪。?xml version1.0? configuration !-- 三节点集群建议 2设 3 会要求三个 DataNode 同时在线才允许写 -- property namedfs.replication/name value2/value /property !-- NameNode 元数据目录format 后生成 VERSION 和 fsimage -- property namedfs.namenode.name.dir/name valuefile:///home/modules/data/name/value /property !-- DataNode 块数据目录块文件直接落在这里 -- property namedfs.datanode.data.dir/name valuefile:///home/modules/data/data/value /property !-- SecondaryNameNode 放在非 NameNode 节点避免抢同一台的内存 -- property namedfs.namenode.secondary.http-address/name valuenode-0002:50090/value /property /configurationdfs.replication设 2 而不是 3是个实用取舍。三台机器里 node-0001 主要承担 NameNode 角色如果副本数设 3任何一台 DataNode 掉线集群就进入副本不足状态写入会被阻塞。设 2 意味着容忍一台机器故障实验场景够用。真做生产再往上调。dfs.namenode.name.dir和dfs.datanode.data.dir都要带file://前缀。不带前缀在某些版本上会被当成相对路径解析到当前工作目录格式化出来的元数据散落在不知道哪里hdfs dfsadmin -report一查 DataNode 数量是 0排查半天找不到原因。这个细节比想象中更常见。3.3 yarn-site.xmlResourceManager、shuffle 服务与内存上限YARN 负责资源调度配置不当的典型症状是任务一直停在 ACCEPTED 状态不进入 RUNNING或者报Container is running beyond physical memory limits。?xml version1.0? configuration !-- ResourceManager 所在主机名 -- property nameyarn.resourcemanager.hostname/name valuenode-0001/value /property !-- MapReduce 必需的 shuffle 服务漏配则任务卡在 shuffle 阶段 -- property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property !-- 容器本地化目录和 HDFS 目录分开 -- property nameyarn.nodemanager.local-dirs/name value/home/nm/localdir/value /property !-- 单节点可供 YARN 分配的总内存单位 MB留 2~4G 给系统 -- property nameyarn.nodemanager.resource.memory-mb/name value8192/value /property !-- 单个容器能申请的内存上限不能超过上面那项 -- property nameyarn.scheduler.maximum-allocation-mb/name value8192/value /property /configurationyarn.nodemanager.aux-services只能配mapreduce_shuffle拼错一个下划线整个 MapReduce 就跑不起来日志里报的是Invalid shuffle port很容易被误判成端口冲突。resource.memory-mb要按机器实际内存减掉系统占用算16G 的机器给 8192 是保守值给满 16000 会导致 NodeManager 启动时 OOM。还有一点maximum-allocation-mb不能大于resource.memory-mb否则提交大内存任务时调度器直接拒绝报错信息里只有一句Invalid resource request不说原因。3.4 mapred-site.xml 与 slaves执行引擎和节点清单Hadoop 2.8.3 的安装包解压后mapred-site.xml是不存在的只有一个mapred-site.xml.template必须先复制再改。这是新手最常问的为什么目录里没有这个文件。# 先复制模板再编辑 cd /home/modules/hadoop-2.8.3/etc/hadoop cp mapred-site.xml.template mapred-site.xml?xml version1.0? configuration !-- 指定 MapReduce 跑在 YARN 上不配则默认走本地模式 -- property namemapreduce.framework.name/name valueyarn/value /property !-- 告诉 YARN 去哪里找 MapReduce 的依赖包 -- property nameyarn.app.mapreduce.am.env/name valueHADOOP_MAPRED_HOME/home/modules/hadoop-2.8.3/value /property property namemapreduce.map.env/name valueHADOOP_MAPRED_HOME/home/modules/hadoop-2.8.3/value /property property namemapreduce.reduce.env/name valueHADOOP_MAPRED_HOME/home/modules/hadoop-2.8.3/value /property /configuration后面三个*.env是 2.x 上跑 YARN 模式的关键。不加的话任务提交后能进入 RUNNING但容器里起不来 JVM日志报Could not find or load main class org.apache.hadoop.mapreduce.v2.app.MRAppMaster。这三个环境变量的值必须和实际安装路径一字不差换目录要同步改。slaves文件写的是 DataNode 和 NodeManager 的节点列表一行一个主机名不要写 IP不要写端口也不要把localhost混进去。# slaves 内容三行用主机名和 /etc/hosts 对应 cat /home/modules/hadoop-2.8.3/etc/hadoop/slaves EOF node-0001 node-0002 node-0003 EOF把 node-0001 也写进slaves是有意为之这样单机也能承担 DataNode 角色三副本之外的场景都能跑。代价是 node-0001 必须能免密 SSH 到自己这一点在配互信时已经覆盖了。3.5 /etc/profileJAVA_HOME 必须用 readlink 反查整个实验记录里反复出错的就这一处。ARM 上装的 OpenJDK 目录名带aarch64后缀完整路径形如/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64和 x86 教程里的java-1.8.0-openjdk完全不是一回事。照着老教程抄JAVA_HOME指向一个不存在的目录start-dfs.sh报JAVA_HOME is not set但echo $JAVA_HOME明明有值非常迷惑。# 反查 java 的真实路径这是唯一可靠的方式 readlink -f $(which java) # 输出示例/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64/jre/bin/java # 去掉末尾的 /jre/bin/java 三层剩下的就是 JAVA_HOME# 追加到 /etc/profile 末尾三个节点都要改 export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64 export HADOOP_HOME/home/modules/hadoop-2.8.3 export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop export PATH$PATH:$JAVA_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbin # 立即生效并验证两个命令都要有输出 source /etc/profile java -version echo $JAVA_HOMEreadlink -f会一路解析软链接到最终的真实路径比echo $JAVA_HOME可靠得多。改完一定要source之后再验java -version只 source 不验证很可能在另一个 shell 里还是老环境。三个节点都要改且路径完全一致不一致的话start-dfs.sh会在一部分机器上成功、另一部分失败日志分散在三个地方排查成本翻倍。4. 分发与启动从 tar 包到 Live DataNode 的四步落地配置写完只完成了一半真正的落地动作是分发、格式化、启动、验证。这四步里格式化是唯一带破坏性的操作做错要推倒重来启动顺序错了进程看着起来了其实互相连不上。这一章按执行顺序走每一步都给出可回滚的做法。4.1 分发前自检先把 JAVA_HOME 和 hosts 对齐分发之前必须先确认两件事在三台机器上完全一致/etc/hosts的内容和/etc/profile里的JAVA_HOME。这两项不一致分发过去再多次也白搭因为问题根本不在 Hadoop 安装包上。# 在 node-0001 上执行逐台比对 hosts 和 JAVA_HOME for h in node-0001 node-0002 node-0003; do echo $h ssh $h md5sum /etc/hosts; grep ^export JAVA_HOME /etc/profile done用md5sum比对/etc/hosts比肉眼 diff 快得多三个哈希值必须相同。JAVA_HOME那行输出也要一模一样路径差一个字符都要先改过来再往下走。这份实验记录里因为 javahome 错误重新分发出现了两次本质就是这一步没做直接进了分发环节。4.2 rsync 分发与 jar 包同步分发的对象有三样Hadoop 安装目录、/etc/profile、OBS 相关的 jar 包。rsync比scp好在支持增量改了一个配置文件再分发只传差异部分。# 在 node-0001 上执行把安装目录同步到另外两台 for h in node-0002 node-0003; do rsync -av --delete /home/modules/hadoop-2.8.3/ $h:/home/modules/hadoop-2.8.3/ scp /etc/profile $h:/etc/profile done # 目标节点上重新加载环境变量并确认版本 ssh node-0002 source /etc/profile hadoop version | head -n 1-a保留权限和时间戳-v打印过程--delete让目标端与源端严格一致。最后这个--delete要慎用如果目标节点上有人手工加过东西会被直接删掉。实验环境里这么用最省事多人共用的机器上建议去掉。同步完在 node-0002 上跑一次hadoop version能打出Hadoop 2.8.3就说明安装目录和JAVA_HOME都对了。这一步不过后面所有启动命令都不用试。4.3 NameNode 格式化只能做一次的破坏性操作格式化会重建元数据目录把里面的VERSION、fsimage全部覆盖。已经跑起来的集群再格式化一次DataNode 上的块数据全部对不上只能连数据一起清掉重来。所以执行前先确认两件事dfs.namenode.name.dir指向的目录是空的hadoop.tmp.dir也是空的。# 确认目录为空有内容先备份再清 ls -A /home/modules/data/name /home/modules/data/buf # 在 node-0001 上执行格式化指定集群 ID 便于后续排查 hdfs namenode -format -clusterId cluster-lab-01-clusterId是可选参数不指定会自动生成一个随机 ID。手工指定的好处是万一 DataNode 报ClusterId mismatch你能立刻看出是格式化时集群 ID 变了还是某个节点用了旧的元数据。格式化成功的标志是日志里出现Storage directory ... has been successfully formatted和Exiting with status 0。4.4 启动顺序与 jps 对表启动顺序是先 HDFS 后 YARN因为 YARN 的容器本地化依赖 HDFS 可用。两个脚本都会通过 SSH 到slaves里的每个节点拉起对应进程所以卡住不动的时候第一个要查的就是免密互信。# 在 node-0001 上执行 start-dfs.sh # 拉起 NameNode、DataNode、SecondaryNameNode start-yarn.sh # 拉起 ResourceManager、NodeManager # 三台机器分别执行对照进程清单 jpsjps的输出是判断集群状态最快的方式。node-0001 上应该看到NameNode、DataNode、ResourceManager、NodeManager、SecondaryNameNode如果 SecondaryNameNode 配在 node-0002 就在那台看node-0002 和 node-0003 上应该有DataNode和NodeManager。少任何一个先去看对应节点$HADOOP_HOME/logs/下最新的那个.log不要凭感觉猜。5. 排查清单JAVA_HOME 连环翻车与五类高频报错下面这五条都是从实验记录里那些执行失败—改配置—重新执行的痕迹中还原出来的。每条按现象、原因、解决三段写照着对号入座能省掉大半的排查时间。5.1 现象start-dfs.sh 报 JAVA_HOME is not set但 echo 有值现象是脚本开头几行就退出提示JAVA_HOME is not set或者Error: JAVA_HOME is not set and could not be found可你echo $JAVA_HOME明明打印了一个路径。原因是那个路径不存在。start-dfs.sh会去$JAVA_HOME/bin/java找可执行文件路径不对就直接判失败它不关心环境变量本身有没有值。ARM 机器上装的是java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64照着 x86 教程写成java-1.8.0-openjdk就会踩这个。解决办法是readlink -f $(which java)反查真实路径取到jre/bin/java之前的部分写进/etc/profile三个节点统一改完source后再验java -version。改完一定要在每台机器上单独跑一次start-dfs.sh的前置检查hadoop version能打出版本号就说明环境对了。5.2 现象ssh 到 node-0002 仍然要输密码现象是ssh node-0001 hostname直接返回ssh node-0002 hostname却提示rootnode-0002s password:。原因是ssh-copy-id只做了单向授权。从 node-0001 推公钥到 node-0002只代表 0001 能免密连 0002反过来 0002 连 0001 或者 0002 连 0003仍然是密码认证。start-yarn.sh在某些流程下会从非 NameNode 节点发起连接单向互信就会卡住。解决办法是把 node-0001 的公钥分发到全部三台机器包括它自己或者更彻底一点用同一对密钥覆盖三台的/root/.ssh/authorized_keys。验证方式是在三台机器上分别执行ssh node-0001 hostname、ssh node-0002 hostname、ssh node-0003 hostname九个组合都不能出现密码提示。5.3 现象DataNode 起来了又秒退日志写 ClusterId mismatch现象是jps里刚看到 DataNode几秒后再查就没了。日志里有一句java.io.IOException: Incompatible clusterIDs后面跟着两个不同的 ID。原因是 DataNode 的VERSION文件里记录的集群 ID 和 NameNode 格式化后生成的不一致。常见于两种情况一是在已有数据的节点上重新执行了hdfs namenode -format二是某个节点是从别的集群复制过来的安装目录data/data/current/VERSION里还留着旧 ID。解决办法是停掉所有进程清空 node-0002、node-0003 上的dfs.datanode.data.dir目录注意是 DataNode 数据目录不是 NameNode 元数据目录然后重启start-dfs.sh。如果start-dfs.sh仍然起不来就在 NameNode 上单独执行一次hdfs namenode -format重新生成 ID再分发一次配置。以后集群只要格式化过所有 DataNode 的数据目录必须同步清空这条要记牢。5.4 现象集群进程全在50070 页面打不开现象是jps显示 NameNode 正常运行命令行hdfs dfs -ls /也能执行但浏览器访问http://公网IP:50070一直转圈直到超时。原因有两个按概率排序一是安全组没放行 50070二是端口搞错了。Hadoop 2.8.3 的 NameNode Web UI 默认端口是 500709870 是 3.x 才改的。照着新版教程放行 9870页面永远打不开。解决办法是先在本机curl -I http://127.0.0.1:50070确认服务确实在监听再ss -lntp | grep 50070看绑定地址。本机通、外网不通就是安全组问题本机也不通就是服务没起或者端口被改过去core-site.xml和hdfs-site.xml里搜http-address确认。5.5 现象访问 obs:// 报 403 或 UnknownHost现象是hadoop fs -ls obs://your-bucket/直接失败报Forbidden、Access Denied或者UnknownHostException。原因分三类403 一般是 AK/SK 抄错、用户没有该桶的读权限或者桶的策略没放开UnknownHost是 endpoint 填错了区域或者机器 DNS 解析不了还有一类是报No FileSystem for scheme obs那是hadoop-huaweicloud的 jar 没放进 classpath。解决办法是分层验证先用ping确认 endpoint 域名能解析再用凭证文件里的 AK/SK 在命令行工具上跑一次ls确认权限最后用hadoop classpath | tr : \n | grep huaweicloud确认 jar 已加载。三层都过了还不行去看 NameNode 日志里完整的异常堆栈那里会写清楚是认证失败还是连接超时。6. 验收与进阶三条命令确认集群真能用进程起来不等于集群可用。真正的验收要看 DataNode 是否注册成功、能不能写入、跨存储系统能不能搬运数据。下面三个动作按顺序做全过一遍这个集群才算落地。6.1 三条命令走完验收# 1. 看注册情况Live datanodes 必须是 3Under replicated blocks 必须是 0 hdfs dfsadmin -report # 2. 走一次真实写入建目录、传文件、读回来 hdfs dfs -mkdir -p /lab/check hdfs dfs -put /etc/hosts /lab/check/ hdfs dfs -cat /lab/check/hosts | head -n 3 # 3. 跨存储搬运把 HDFS 里的文件推到对象存储桶 hadoop distcp /lab/check/hosts obs://your-bucket/lab/check/第一条命令的输出里Live datanodes (3)这个数字不对就说明有节点没注册上先回去查 5.3。第二条命令验证的是完整读写链路-put成功但-cat失败通常是 DataNode 的块数据目录权限问题。第三条distcp是最有价值的验收它同时走通了 HDFS 读、OBS 写和 MapReduce 调度三条路径任何一环配置错了都会在这一步暴露。验收项命令合格线DataNode 注册hdfs dfsadmin -reportLive datanodes 为 3HDFS 读写hdfs dfs -put-cat内容与源文件一致YARN 调度yarn node -list三个节点状态为 RUNNING对象存储连通hadoop distcp hdfs:///... obs://...无异常退出退出码 06.2 一个容易被忽略的进阶技巧distcp默认会起 MapReduce 任务来搬数据小文件场景下调度开销比传输本身还大。文件总量在几百 MB 以内时加-direct参数绕开 MapReduce直接在客户端起线程池拷贝速度反而更快也不占 YARN 队列。命令改成hadoop distcp -direct /lab/check/hosts obs://your-bucket/lab/check/就行。这个参数在排查到底是网络慢还是 YARN 调度慢的时候特别有用加-direct快、不加慢问题就在调度侧不在存储侧。我自己的习惯是每次重建集群都强制走一遍这三条验收命令不管前面配置看着多顺。有一次jps显示三个 DataNode 全在dfsadmin -report却只有两个 Live第三个因为磁盘挂载点没生效一直在反复注册和退出日志里刷了几百行我没注意。从那以后Live datanodes的数字不凑够三个我绝不去动任何业务数据。希望这些能帮到你少在环境上耗时间。本文还有配套的精品资源点击获取