★ FEATURED ARTICLE 简介这是一份基于鲲鹏云平台的大数据实验报告面向高校学生、云计算与大数据初学者系统记录了在华为云ECS与OBS环境下从零搭建Hadoop集群的完整流程。报告为docx格式压缩包内共1个文档文件大小2.52MB已有892人学习下载。实验内容涵盖华为云环境准备、OBS桶创建与AK/SK密钥获取、节点互信与SSH免密登录、Hadoop安装包分发、core-site.xml等核心配置文件的逐一修改以及NameNode初始化和HDFS启动等关键环节。针对部署中频繁出现的Java home路径错误报告专门记录了重新分发软件包、修正/etc/profile并同步各节点环境变量的排错过程真实还原了云上集群调试的第一手经验。读者可借这份报告快速把握鲲鹏云大数据平台的搭建要点也可作为课程实验、毕业设计或企业预研时的操作参考。1. JAVA_HOME 连环报错搭建 Hadoop 集群最折腾人的一个开头“Error: JAVA_HOME is not set and could not be found.” 这句话我在这份鲲鹏云大数据实验报告里反复看到每一轮几乎都跟着一句“执行失败更改 javahome 的目录”。从解压 Hadoop、向 /etc/profile 写入环境变量到 NameNode 初始化、启动 HDFS、执行 hdfs 命令一连串操作全部被同一个原因卡住。java -version 明明能打印版本号OpenJDK 也确实装好了可 Hadoop 的脚本就是找不到 JDK这种黑匣子一样的表现最让人抓狂。如果你也在搭自己的大数据实验环境也被这种环境变量改来改去依然报错的情况折磨下面这套复盘值得看完JAVA_HOME 是怎么让整条链路连环翻车的节点互信和配置分发里还藏着哪些坑以及下一次如何快速定位。2. 环境准备阶段的三个隐性坑ECS 连通、OBS 鉴权与 AK/SK 保管在正式碰 Hadoop 之前这套实验花了不少篇幅准备云环境购买弹性云服务器 ECS、开通对象存储服务 OBS、创建并行文件系统、下载 credentials.csv 拿到 AK/SK。这一步看起来都是控制台点选但恰恰是后面所有报错的“前哨”。我见过不少人在 Hadoop 配置里折腾了半天最后发现是 OBS 的 endpoint 区域不匹配或者 AK/SK 里混进了换行符。环境没准备好后面每一条报错都会让你误判成 Hadoop 的问题。2.1 ECS 购买后 SSH 连不上安全组规则比你想的更严格现象是购买完成后本地终端 ssh root公网IP 直接超时ping 也不通。第一次操作云环境的人通常会怀疑是密码错了、镜像坏了实际上绝大多数情况是安全组没放行 ICMP 和 22 端口。云厂商默认安全组往往只放行部分端口或者创建 ECS 时选了“不放行任何端口”的模板公网流量根本进不来。我一般会先在控制台用 VNC 登录进去确认系统本身是好的再回头查网络# 本机依次执行确认哪一层不通 ping -c 3 ECS公网IP nc -zv ECS公网IP 22 ssh rootECS公网IP参数说明-c 3 表示只发三个 ICMP 包避免一直 ping 下去nc -zv 用来检测 22 端口是否开放-z 是扫描模式-v 输出详细信息。如果 ping 通而 nc 不通基本可以断定是安全组入方向规则漏了 22如果两者都不通还要检查弹性公网 IP 是否已经绑定到实例上。这个坑在实验里不太起眼但它是后面所有 ssh 操作的前提。节点之间要配置互信、分发安装包第一步就是三台 ECS 能互相连通。实验记录里后续每台节点都要执行 vim /etc/hosts 和 ssh 公钥复制如果安全组把内网端口也挡了免密登录会表现得“时好时坏”非常像玄学。2.2 OBS 报 403 AccessDenied桶名、Endpoint 与 AK/SK 三项要同时匹配实验在 core-site.xml 里要写入 OBS 的认证信息包括访问密钥、私有密钥和 endpoint。它明确区分了两种地址IPv4 地址适用于普通 IPv4 网络双栈地址适用于 IPv6 双栈环境。很多人在这里翻车是把双栈地址填进了纯 IPv4 的集群结果 Hadoop 访问 OBS 时连接超时或直接 403。报错 403 的排查顺序我建议是先确认 AK/SK 没复制错再确认桶名只填桶名而不是整个 URL最后确认 endpoint 和桶所在区域一致。实验里的桶是在 cn-north-4 区域创建的core-site.xml 里却配了别的区域 endpoint就会走错机房鉴权自然失败。下面的配置是实验里核心站点文件的 OBS 部分参数我按通用写法给出property namefs.obs.access.key/name value你的AK/value /property property namefs.obs.secret.key/name value你的SK/value /property property namefs.obs.endpoint/name valueobs.cn-north-4.example.com/value /property property namefs.obs.bucket/name value并行文件系统名称/value /property说明endpoint 的值不要带 https:// 前缀Hadoop 的 OBS 插件会自动拼协议IPv4 环境不要填 dualstack 地址。桶名那一项如果有人图省事把控制台里的“桶访问域名”整段搬进来也会因为多出了区域后缀而报错。改完这些配置记得要 scp 到所有节点只改 node-0001 是没有意义的。2.3 credentials.csv 里的 AK/SK只下载一次泄露等于裸奔实验里有个关键动作操作完成后得到文件 credentials.csv打开就能拿到 AK/SK。这个文件云厂商只会让你下载一次之后控制台不再提供完整密钥只能重置。很多人把 csv 放在下载目录里过几个月清理文件时发现备份没了或者截图发出去等于把云账户的钥匙交了出去。我处理密钥的习惯是三步第一时间移出下载目录、收紧文件权限、用环境变量注入而不是写死在配置里。mkdir -p ~/.credentials mv ~/Downloads/credentials.csv ~/.credentials/obs-key.csv chmod 600 ~/.credentials/obs-key.csv export OBS_ACCESS_KEY_ID$(awk -F, NR2{print $2} ~/.credentials/obs-key.csv) export OBS_SECRET_ACCESS_KEY$(awk -F, NR2{print $3} ~/.credentials/obs-key.csv)说明csv 第一行是表头 User Name,Access Key Id,Secret Access Key第二行才是真实值所以 awk 用 NR2 取第二行-F, 按逗号分列后取第 2、3 列。chmod 600 保证只有 root 能读。这样做的另一个好处是Hadoop 的 core-site.xml 里不需要明文出现密钥后续把配置文件打包分发时不用担心密钥被一起带出去。注意密钥一旦泄露删除文件没有用必须到控制台重置 SK旧密钥会立即作废。3. 同一个 JAVA_HOME 错误为什么让 namenode 初始化、HDFS 启动、hdfs 命令连环翻车这一章是整份实验记录里最值得复盘的部分。回顾原文几乎每个关键节点都会出现同一个短语更改 javahome 的目录。第一次是配置环境变量后执行报错第二次是分发 hadoop 包之后第三次是初始化 namenode第四次是启动 HDFS、执行 hdfs 命令。同一个错表面上是“这次失败了改一下再试”实际上背后有一个共同的根因链。3.1 现象复盘java -version 正常Hadoop 却说找不到 JAVA_HOME先看现象。执行 java -version 时OpenJDK 正常输出版本号执行 hadoop version 时却报出类似下面的错误Error: JAVA_HOME is not set and could not be found.或者在 hadoop-env.sh 里配了路径但配错时报Error: JAVA_HOME is not defined correctly. We cannot execute /usr/lib/jvm/java-1.8.0/bin/java这种割裂感是新手最容易误判的地方。bash 能执行 java是因为 PATH 环境变量里有 /usr/bin而 /usr/bin/java 是指向真实 JDK 的软链接Hadoop 的启动脚本不读 PATH只读 $JAVA_HOMEJAVA_HOME 一旦为空或指向不存在的目录脚本就直接退出。所以 java -version 正常恰恰证明不了 JAVA_HOME 是对的。实验的报错轨迹也说明了这一点先改 /etc/profile 后忘了 source当前 shell 里 JAVA_HOME 还是旧的namenode 初始化失败重新 source 之后 hdfs 命令仍然失败是因为 hadoop-env.sh 里的 JAVA_HOME 写死成了一个不存在的目录。脚本优先级问题我放在下一节讲。3.2 根因定位aarch64 架构下 OpenJDK 的真实目录与脚本查找顺序用系统包管理器装 openjdk 后真实目录形如 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64。注意最后一段aarch64。这套实验的节点是鲲鹏架构的 ARM 云主机JDK 也是 ARM 版路径里会带体系结构标识。常见的错误配置是照抄别人的路径比如把 x86_64 或干脆把 /usr/lib/jvm/java-1.8.0 写进去。问题在于 /usr/lib/jvm/java-1.8.0 在部分系统上是一个软链接指向某个默认版本。Hadoop 的脚本拿到软链接路径后会再去解析 jre/lib 目录一旦解析结果和真实 JDK 结构不一致就报 “JAVA_HOME is not defined correctly”。所以实验里反复“更改 javahome 的目录”本质是把路径从“看起来对”改成“实测存在”。Hadoop 脚本的查找顺序值得说清楚它先看 hadoop-env.sh 里的 JAVA_HOME再看系统环境变量 JAVA_HOME最后尝试用 which java 兜底。与我们直觉相反最后一步兜底用的也是软链接路径如果 /usr/bin/java 本身是指向 /etc/alternatives/java 的再软链接整条链很容易断。解决方向上我会推荐一个“消解软链接”的做法而不是去猜真实目录。3.3 解决动作锁定真实目录、建软链接固定入口、全节点统一第一步先在节点上找到 JDK 真实安装目录ls -d /usr/lib/jvm/java-1.8.0-openjdk-*这一步会列出该节点上实际存在的 OpenJDK 目录拿到的路径就是唯一的可信答案。第二步把 JAVA_HOME 写入 /etc/profile并顺手做一个固定软链接ln -sfn /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64 /usr/lib/jvm/java-8 export JAVA_HOME/usr/lib/jvm/java-8 export PATH$JAVA_HOME/bin:$PATH说明ln -sfn 的 -s 表示软链接-f 表示覆盖已有链接-n 表示目标已存在时不递归。以后 JDK 小版本升级只需要把源头路径换成新目录三台机器的 /etc/profile 不用动这是我在多节点环境里比较推荐的做法。第三步也是最容易被忽略的source /etc/profile 只对当前 shell 生效重新登录的会话没问题但当前终端里的旧值还在。实验里“上图执行失败更改 javahome 的目录”反复出现一半是路径问题一半是改了没 source。检查命令要一连串执行source /etc/profile echo $JAVA_HOME ls -d $JAVA_HOME $JAVA_HOME/bin/java -version三条输出都能对上才能认为这个节点的 Java 环境真正修好。然后才是把 /etc/profile 同步到 node-0002、node-0003。如果同步完不 source子节点依旧报错这就是实验里说的“分发 0002 由于 javahome 错误重新分发”的真实原因。4. 节点互信与配置分发集群一半的“玄学报错”来自这里三台 ECS 都在同一套实验流程里重复执行了 vim /etc/hosts、复制 ssh 公钥、配置免密登录、创建目录、解压包、改 profile。这些动作单独看都很简单但放到集群层面“每台机器都做了”和“每台机器都做对了”是两回事。Hadoop 的报错经常是跨节点的最典型的是 namenode 起来了datanode 却一直掉线。4.1 SSH 免密登录失败authorized_keys 权限与 yes/no 确认实验里在复制公钥后写了“执行后选 yes 无密码跳转”。这个 yes 是第一次 ssh 时的主机指纹确认很多人第一次看到 “Are you sure you want to continue connecting (yes/no)?” 会不知所措。选 yes 之后指纹会写入 ~/.ssh/known_hosts下次不再询问。但免密登录失败最常见的原因不是 known_hosts而是权限。sshd 对 .ssh 目录和 authorized_keys 文件的权限非常敏感目录超过 700、文件超过 600它会直接忽略这个公钥文件表现就是仍然提示输入密码。手动 cat 追加公钥时如果公钥被折行或者复制时丢了末尾的注释也会静默失败。我一般这样收敛操作# 在 node-0001 生成密钥-N 表示空口令 ssh-keygen -t rsa -b 4096 -N -f /root/.ssh/id_rsa # 用 ssh-copy-id 分发到两台子节点 ssh-copy-id rootnode-0002 ssh-copy-id rootnode-0003 # 统一修正权限 chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys # 验证跳转 ssh node-0002 hostname说明ssh-copy-id 会自动把公钥追加到对方的 authorized_keys 并修正权限比自己 cat 追加稳妥。参数 -b 4096 是密钥长度-N 跳过 passphrase集群场景必须为空口令否则每次 ssh 都要输密码。排错时如果仍然失败加 ssh -vvv 看输出重点看 “Authentication refused” 之前有没有权限告警。4.2 配置分发不完整node-0002 的 JAVA_HOME 是怎么“带病上岗”的实验里出现了一段很有代表性的记录“因为 javahome 错误重新分发”“分发 0002 由于 javahome 错误重新分发”。这说明分发动作本身做了但分发的“内容”不完整。常见情况是把解压好的 hadoop 目录用 tar 或 scp 发过去了但 /etc/profile 里新加的 JAVA_HOME 没跟着过去或者 profile 发过去了子节点没有执行 source。另一个隐蔽问题只分发了解压目录没分发配置文件。Hadoop 的 etc/hadoop 下的 core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml、slaves 是集群行为的全部来源node-0001 改完子节点必须拿到同一份。我的建议是把配置文件和 profile 分开分发并且每条命令后面都要跟验证# 统一 profile 后分发 scp /etc/profile rootnode-0002:/etc/profile scp /etc/profile rootnode-0003:/etc/profile # 分发 hadoop 配置目录 scp -r /home/modules/hadoop-2.8.3/etc/hadoop rootnode-0002:/home/modules/hadoop-2.8.3/etc/ scp -r /home/modules/hadoop-2.8.3/etc/hadoop rootnode-0003:/home/modules/hadoop-2.8.3/etc/ # 子节点立即生效并验证 ssh node-0002 source /etc/profile hadoop version ssh node-0003 source /etc/profile hadoop version说明scp -r 会递归复制整个 etc/hadoop 目录覆盖子节点上的同名文件。验证命令写成一条 ssh 远程执行可以立刻暴露“profile 没生效”或“配置文件版本不一致”的问题不用再登录进去手动敲。这个习惯帮我排掉了大量“为什么我改了没用”的疑案。4.3 /etc/hosts 不一致与 slaves 文件DataNode 掉线的隐蔽原因HDFS 启动后最典型的故障是jps 能看到 node-0001 上 namenode 进程但 node-0002、node-0003 的 datanode 起来几秒就退去 logs 里翻十有八九是 UnknownHostException 或者注册失败。根因通常是 /etc/hosts 没有全局统一。实验里三台节点都执行了 vim /etc/hosts如果只把本机 IP 映射写进自己那台互相解析不了主机名datanode 就无法向 namenode 注册。slaves 文件同样有讲究它应该写子节点的主机名而不是写 IP 或 localhost。写成 localhost 的后果是集群只会在本机启动一个 datanode另外两台永远是个“幽灵节点”。这里给出一个统一 hosts 的写法IP 部分用内网地址做示例实际地址以你自己的环境为准# 三台节点写入完全相同的 hosts 内容 cat /etc/hosts EOF 192.168.1.11 node-0001 192.168.1.12 node-0002 192.168.1.13 node-0003 EOF# slaves 文件只写主机名不写 IP不写 localhost cat /home/modules/hadoop-2.8.3/etc/hadoop/slaves EOF node-0002 node-0003 EOF说明cat 追加 hosts 时注意不要重复追加导致旧映射残留最稳妥的做法是先用 sed 删除旧记录再写入。集群节点间通信用内网 IP比公网 IP 稳定安全组也更容易收敛。改完 hosts 后每台机器都执行 hostname 和相互 ping 一遍确认解析无误再启动 HDFS。5. 避坑记录Hadoop 集群搭建中反复出现的 5 个配置错误这一章把上面几章里容易反复踩的位置单独拎出来每条都是“现象 → 原因 → 解决”的固定结构方便对照自己的报错现场。这些都是我在多套集群上实际遇到过的不是从文档里抄来的理论。5.1 改了 JAVA_HOME 还在报错当前 shell 没 source现象node-0001 上修改了 /etc/profile重新执行 hadoop version 依旧报 JAVA_HOME 找不到。原因/etc/profile 只在登录 shell 初始化时读取当前终端早就启动完了不会自动感知文件变化。解决每次改完必须 source /etc/profile而且验证要在同一个 shell 里连续执行 echo $JAVA_HOME 和 $JAVA_HOME/bin/java -version。多节点操作时用 ssh node-0002 source /etc/profile hadoop version 这种远程命令验证避免“以为生效了”。5.2 endpoint 填了双栈地址IPv4 网络一直连接超时现象core-site.xml 配置了 obs.dualstack 开头的地址集群访问 OBS 时长时间卡住最后超时。原因双栈地址面向 IPv4/IPv6 双栈网络纯 IPv4 环境解析或握手异常。解决确认自己的网络和 VPC 是否开了 IPv6。没开就老实用 IPv4 地址开了 IPv6 才考虑 dualstack。填 endpoint 时不带协议头桶名不要带域名后缀。验证方式在节点上 curl 一下 endpoint能通再改配置别让 Hadoop 替你背锅。5.3 密钥泄露从 csv 到日志AK/SK 最容易在没有防备时暴露现象有同事把 credentials.csv 放在共享目录或者把 export 命令写进 .bash_history 后日志被拖走结果 OBS 桶被恶意读写。原因AK/SK 等同于云账户密码csv 文件权限过宽任何能登录这台机器的人都能读走。解决csv 下载后立刻 mv 到 ~/.credentials 并 chmod 600export 语句用 read 从文件读取避免留在 history 里。密钥泄露后不要只删文件要到控制台重置 SK旧 SK 作废。5.4 分发只发解压目录配置文件和 profile 没跟上现象node-0002 上 hadoop 命令能跑但访问的 core-site.xml 还是默认配置连不上 node-0001 的 namenode。原因分发时只 tar 或 scp 了 hadoop 主目录etc/hadoop 下的修改后配置被覆盖或根本没发。解决把 etc/hadoop 整个目录单独分发再把 /etc/profile 也分发并 source。分发完立刻跑一条远程 hadoop version 和 hdfs dfs -ls 验证别急着启动全部服务。5.5 在 ARM 节点下载了 x86_64 的 JDK 或 Hadoop 包现象解压后执行 java -version 报 Exec format error或者 Hadoop 脚本启动到一半进程消失。原因鲲鹏节点是 aarch64 架构下载了 x86_64 架构的 OpenJDK 或二进制包内核直接拒绝执行。解决下载前确认包名里带 aarch64。实验里的 JDK 路径 java-1.8.0-openjdk-1.8.0.242.b08-1.h5.oe1.aarch64 就是 ARM 版。下载后用 file /路径/java 看 ELF 信息出现 “aarch64” 才是正确架构。6. 快速定位这类故障的三板斧日志、diff、一键校验三台节点的 Hadoop 集群故障定位最忌讳逐台登录、逐条命令试。我的做法是固定三件事先看日志缩小范围再 diff 配置找差异最后用一条循环命令把三台机器的关键环境一次性打出来。这份鲲鹏云大数据实验报告的资源完整保留了这条链路每一步的操作和修正记录放在手边对照能省很多时间。先看日志。HDFS 和 YARN 的日志都在 hadoop 安装目录的 logs 子目录下namenode 日志文件名形如 hadoop-root-namenode-node-0001.logdatanode 对应 hadoop-root-datanode-node-0002.log。遇到进程起来又退直接执行grep -E ERROR|Exception /home/modules/hadoop-2.8.3/logs/*.log | tail -20看到 UnknownHostException 就去查 hosts看到 AccessDenied 就去查 OBS 的 AK/SK 和 endpoint看到 JAVA_HOME 相关直接去查 profile。报错信息会自己指路。再 diff 配置。三台机器配置漂移是集群故障的最大来源把子节点的 profile 拉回来和 node-0001 对比scp rootnode-0002:/etc/profile /tmp/profile-node-0002 diff /etc/profile /tmp/profile-node-0002diff 无输出说明两边一致有输出就看差异在哪一行。这个动作比登录三台机器肉眼检查快得多也适合对 etc/hadoop 目录整体做差异对比。最后是一键校验环境。我习惯把下面这条循环存成一个脚本每次启动集群前跑一遍for node in node-0001 node-0002 node-0003; do echo $node ssh $node echo JAVA_HOME$JAVA_HOME; ls -d $JAVA_HOME; $JAVA_HOME/bin/java -version 21 | head -1 done如果三台输出的 JAVA_HOME 路径完全一致java -version 都能打印版本就可以放心初始化或启动服务。输出不一致的节点直接对照第 3 章的处理流程单独修。从那次连续翻车之后我每搭一套集群都会强制走一遍“同 profile、同配置目录、同架构”的预检流程再没有任何一个晚上耗在环境变量上。希望这次复盘能帮你把同样的坑一次填平希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
