简介大数据平台的搭建与验证是企业级应用的基础环节而随着ARM架构的普及鲲鹏云等国产化环境下的组件兼容性成为热门关注点。在aarch64处理器上部署Hadoop需要从镜像选择、JDK安装到分布式配置全链路适配尤其要留意安装包的架构匹配与SSH免密等细节。掌握这一流程不仅能在鲲鹏云上跑通MapReduce任务还能为课程实验、团队环境交付提供可靠证据链。以完整可复现的鲲鹏云大数据实验为主线涵盖环境检查、Hadoop伪分布式配置、Streaming任务执行及docx报告生成系统展示ARM生态下的一次真实交付过程帮助工程师少踩架构坑。1. 鲲鹏云大数据实验 docxARM 生态下的一次完整交付一份以“鲲鹏云大数据实验 docx”为名交付的实验报告本质上是把你在一台基于鲲鹏处理器的云主机上从零搭建大数据环境、跑通一个小型数据处理任务的全过程用可复现的方式记录下来。它不只是写文档而是用 docx 承载一套证据链你选了什么镜像、装了什么软件、跑了什么命令、得到了什么结果、踩了什么坑。对于正在做课程实验的学生、需要给团队搭建 ARM 实验环境的工程师以及刚接触鲲鹏生态想验证软件兼容性的技术人员这个交付物就是最直接的衡量标准。这篇文章我按自己在鲲鹏云上做过的一整套流程来讲从开主机到导出一份能交出去的报告每一步都给出能直接抄的命令和参数。2. 搭实验环境在鲲鹏云上选镜像、开主机、装 JDK 与 Hadoop2.1 规格与镜像选择ARM 和 x86 的第一处分岔鲲鹏云主机和普通 x86 云主机最大的区别在处理器架构鲲鹏处理器是 ARM64对应 Linux 下的 aarch64而大多数教程、安装包、镜像默认都是 x86_64。这个差异会在后面反复出现所以第一步就要把架构确认清楚。创建主机的规格选择上做大数据实验我一般会这样配单节点伪分布式2 vCPU 8 GB 内存起步这个配置能跑通 Hadoop 的 NameNode、DataNode 和 ResourceManager跑小规模数据不会卡如果要搭 3 节点的完全分布式建议每台 4 vCPU 16 GB 内存。不要一上来就选最高配费用翻倍不说实验本身的数据量根本用不满。镜像选择时要看清楚是不是 aarch64 版本。有些平台的控制台里镜像名称不会直接标架构需要点开详情看选错的话后面所有软件安装都会踩架构不匹配的坑。拿到主机后第一件事是在终端里确认架构和系统信息命令如下# 查看当前机器的 CPU 架构输出 aarch64 或者 x86_64 uname -m # 查看系统版本和内核信息判断镜像类型 cat /etc/os-releaseuname -m输出aarch64说明环境正确后续下载安装包时你要专门找带aarch64字样的包如果输出的是x86_64说明镜像选错了建议重新创建主机。这一步花不到一分钟但能免掉后续 JDK、Hadoop 装完跑不起来的尴尬。确认无误后后续所有操作都在这个 aarch64 环境里进行。2.2 从一台空主机到装好 JDK 与 Hadoop逐条命令说明Hadoop 本身是 Java 写的所以第一步是装 JDK。在 aarch64 环境里我建议直接用系统自带的包管理器安装 OpenJDK而不是去官网下载 tar 包。包管理器会自动拉取 aarch64 版本避免手动下载时误拿 x86_64 的包。# 更新系统源确认仓库状态 sudo dnf update -y # 安装 OpenJDK 11 开发版hadoop 3.x 在 JDK 8 和 11 上都可运行 sudo dnf install -y java-11-openjdk-devel # 验证版本输出里能看到 aarch64 字样 java -versionjava -version输出最后一行如果包含类似OpenJDK 64-Bit Server VM的信息同时能看到aarch64说明安装正确。需要注意鲲鹏云主机默认推荐的 Linux 发行版里dnf或yum的命令名可能不同如果提示找不到命令换成另一个试一下。装完 JDK 后用readlink拿到 JAVA_HOME 的真实路径这一步很多新手会漏# 通过命令所在路径反推 JAVA_HOME注意处理软链接 export JAVA_HOME$(dirname $(dirname $(readlink -f $(which java)))) echo $JAVA_HOME输出类似/usr/lib/jvm/java-11-openjdk-...记下这个路径后面配置 Hadoop 要用。接着下载 Hadoop 正式发行版。Apache Hadoop 3.3 之后的版本对 ARM 架构的支持明显变好官方发行包可以直接在 aarch64 上运行。# 解压 Hadoop 到 /opt 目录并建立软链接方便后续升级 sudo tar -xzf hadoop-3.3.6.tar.gz -C /opt sudo ln -s /opt/hadoop-3.3.6 /opt/hadoop sudo chown -R $(whoami) /opt/hadoop # 配置 hadoop-env.sh 里的 JAVA_HOME echo export JAVA_HOME/usr/lib/jvm/java-11-openjdk-... /opt/hadoop/etc/hadoop/hadoop-env.sh # 验证 hadoop 命令可用 /opt/hadoop/bin/hadoop versionhadoop version能正常输出版本号说明二进制和当前架构匹配。如果这里报Cannot execute binary file或者Exec format error基本可以确定下载了 x86_64 的包重新下载 aarch64 版本即可。伪分布式模式只需要配置两个文件core-site.xml和hdfs-site.xml。# core-site.xml指定 NameNode 地址 cat /opt/hadoop/etc/hadoop/core-site.xml EOF configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property /configuration EOF # hdfs-site.xml指定 NameNode 和 DataNode 的数据目录不要放 /tmp cat /opt/hadoop/etc/hadoop/hdfs-site.xml EOF configuration property namedfs.namenode.name.dir/name value/home/bigdata/hdfs/name/value /property property namedfs.datanode.data.dir/name value/home/bigdata/hdfs/data/value /property property namedfs.replication/name value1/value /property /configuration EOFhdfs-site.xml里我特意把数据目录指定到/home/bigdata/hdfs而不是默认的/tmp原因有二一是/tmp可能会被系统清理节点重启后元数据丢失需要重新格式化这是新手最常遇到的“玄学”问题二是数据目录放在独立路径后续写报告时能清晰说明数据落盘位置。副本数设为 1是因为单节点伪分布式下 3 副本没有意义反而占用磁盘空间。2.3 单节点先跑通配置 SSH 免密并格式化文件系统Hadoop 启动脚本依赖 SSH 免密登录即使是单节点也需要配好 localhost 的免密。这里有个坑很多教程直接让执行ssh-keygen然后ssh-copy-id localhost但如果你在云主机上是从 root 用户操作SSH 服务可能默认禁止 root 通过公钥登录需要先检查。# 生成密钥对-P 表示空口令 ssh-keygen -t rsa -P -f ~/.ssh/id_rsa # 将公钥加入 authorized_keys cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys # 关键目录权限必须正确否则 SSH 拒绝使用公钥 chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys # 测试免密登录能直接返回主机名即可 ssh localhost权限设置这一行是血泪经验。SSH 对~/.ssh目录和authorized_keys文件的权限非常敏感权限过松会直接忽略公钥认证表现为每次都要求输密码或者报Permission denied (publickey)。配好免密后格式化 HDFS 并启动服务# 先格式化 NameNode注意 format 命令执行一次即可重复执行会清空元数据 /opt/hadoop/bin/hdfs namenode -format # 启动 HDFS 服务 /opt/hadoop/sbin/start-dfs.sh # 检查进程能看到 NameNode、DataNode、SecondaryNameNode 三个进程 jpsjps命令是 JDK 自带的专门用来查看 Java 进程。能看到三个核心进程就说明 HDFS 起来了。如果 DataNode 启动后几秒就消失大概率是数据目录权限或者上次格式化残留的问题停掉服务后清空/home/bigdata/hdfs目录再重新格式化即可。3. 设计并执行一个真正的小型实验从 HDFS 到 MapReduce3.1 实验选型为什么用 Hadoop Streaming 而不是自带示例环境就绪后实验内容的选择会影响整个报告的分量。最省事的做法是直接跑 Hadoop 自带示例里的 WordCount一条命令就能出结果。但我的建议是换成 Hadoop Streaming Python理由有两点第一自带 WordCount 是纯 Java 实现跑的时候会加载本地库在 aarch64 环境里偶尔会出现 native 库加载问题新手很难判断是代码问题还是架构问题第二Streaming 模式下 map 和 reduce 就是普通的 Python 脚本读写标准输入输出逻辑完全透明你能把注意力集中在理解 MapReduce 的数据流上而不是被 Java 语法干扰。实验数据我一般用一个模拟的访问日志统计每个 IP 的访问次数。这个场景贴近真实而且报告里能讲清楚业务含义比数单词更有说服力。3.2 造一份像样的实验数据并上传 HDFS先在本机用脚本生成 2 万行格式一致的模拟日志字段分别是日期、IP、请求路径、状态码# 生成 20000 行模拟访问日志 ts$(date %Y-%m-%d) for i in $(seq 1 20000); do ip192.168.$((RANDOM % 10)).$((RANDOM % 255)) code$((200 RANDOM % 100)) echo $ts $ip GET /index.html $code done access.log # 确认行数和文件大小 wc -l access.log ls -lh access.log # 输出示例20000 行约 400KB$((RANDOM % 10))是 Bash 内置的随机数生成范围 0 到 9这样会让 IP 集中在前 10 个网段保证最终统计结果里有明显的重复值便于观察聚合效果。文件大概 400KB远小于 HDFS 默认的 128MB 块大小所以这个实验实际上只有一个块不需要关注块大小对任务拆分的影响这也是单机实验的正常情况。上传到 HDFS 之前先建好实验目录# 创建 HDFS 目录结构 /opt/hadoop/bin/hdfs dfs -mkdir -p /user/exp/input # 上传本地日志文件 /opt/hadoop/bin/hdfs dfs -put access.log /user/exp/input/ # 查看 HDFS 上的文件确认大小和副本数 /opt/hadoop/bin/hdfs dfs -ls -h /user/exp/input/执行-ls -h时能看到replication1的标识这正好对应hdfs-site.xml里配置的副本数。如果你的输出显示replication3但只有一台机器不要慌文件副本是逻辑概念单节点上 3 个副本落在同一台机器上不影响实验逻辑但写报告时可以提一句“单节点环境无法体现数据块在多机间的分布故将副本数调整为 1”这句话能体现你真的理解了副本机制。3.3 写 Python 的 Map 和 Reduce 脚本Streaming 任务的核心是两段 Python 代码。先写 mapper#!/usr/bin/env python3 # mapper.py读取标准输入的每一行切分后取 IP 字段输出 IP\t1 import sys for line in sys.stdin: parts line.strip().split() if len(parts) 3: # 防止空行或格式异常的行 ip parts[1] # 第二列是 IP 地址 print(f{ip}\t1)接着写 reducer#!/usr/bin/env python3 # reducer.py对相同 IP 的计数累加最终输出 IP\t总数 import sys current_ip None count 0 for line in sys.stdin: ip, _ line.strip().split(\t, 1) if ip ! current_ip: if current_ip is not None: print(f{current_ip}\t{count}) current_ip ip count 0 count 1 # 最后一个 IP 需要单独输出 if current_ip is not None: print(f{current_ip}\t{count})reducer 里有个细节Hadoop Streaming 会保证 key 有序输入到 reducer但不会保证同一个 key 的所有数据一次性进入内存所以必须用“记录当前 key、累加、切换 key 时输出”的写法而不是把所有数据读进字典再统计。这个写法是 MapReduce 程序的标准模式也是面试里常问的点。在 2 万行的数据量下这种流式处理的优势不明显但思路一定要对。上传脚本并提交 Streaming 任务# 将脚本上传到 HDFS 的 /user/exp/ 目录与输入数据分离 /opt/hadoop/bin/hdfs dfs -mkdir -p /user/exp/scripts /opt/hadoop/bin/hdfs dfs -put mapper.py reducer.py /user/exp/scripts/ # 提交 streaming 任务注意 -files 指定的是本地路径会被自动分发到 task 节点 /opt/hadoop/bin/hadoop jar \ /opt/hadoop/share/hadoop/tools/lib/hadoop-streaming-*.jar \ -files mapper.py,reducer.py \ -mapper python3 mapper.py \ -reducer python3 reducer.py \ -input /user/exp/input \ -output /user/exp/output-files mapper.py,reducer.py这行不能省略它负责把本地脚本打包发送到每个执行任务的节点否则节点上找不到脚本会直接报错。-mapper和-reducer后面跟的是完整命令这里的python3 mapper.py是“用 Python 解释器执行脚本”有些环境 Python 命令是python注意调整。任务跑完后HDFS 的/user/exp/output目录里会生成part-00000文件输出目录在任务执行前必须不存在否则 Hadoop 会拒绝执行这也是一个常见报错。查看结果并做简单排序# 直接输出前 20 行结果 /opt/hadoop/bin/hdfs dfs -cat /user/exp/output/part-00000 | head -20 # 按访问次数倒序排序取前 10 个最活跃的 IP /opt/hadoop/bin/hdfs dfs -cat /user/exp/output/part-00000 | sort -t $\t -k2 -nr | head -10这个命令里sort -t $\t -k2 -nr的意思是用 Tab 作为列分隔符按第二列数字格式逆序排序。注意排序是本地 shell 做的不是 Hadoop 的计算逻辑因为 MapReduce 默认只保证 key 有序不保证 value 有序。如果你在报告里需要“Top 10 活跃 IP”这个本地排序的结果就是你的数据来源。4. 把实验过程落成 docx一份能交出去的报告长什么样4.1 报告的骨架每一节放什么内容实验做完了剩下来最花时间的就是写 docx。一份合格的大数据实验报告阅卷人或验收人最关心三件事环境是否真实可信、过程是否可复现、结果是否有原始输出支撑。我常用的报告结构如下报告章节放什么内容建议篇幅实验目的一句话说清要验证什么比如“验证鲲鹏 aarch64 环境下 Hadoop 的可用性跑通数据上传与 MapReduce 计算流程”2 行实验环境硬件规格、操作系统版本、JDK 版本、Hadoop 版本、架构、节点角色一张表格实验步骤按时间顺序列出关键命令和关键输出截图辅助说明2-3 页实验结果原始part-00000的输出摘录Top 10 表格1-2 页问题与解决从踩坑记录里挑 1-2 个最有代表性的写明现象、原因、解决半页实验心得不写空话写数据和结论处理了多少行、耗时多少秒、对 ARM 生态的判断3-5 行这个结构的好处是每部分都有明确指向。比如“实验环境”里的表格直接决定了你整篇报告的可信度如果这一栏填的是“虚拟机 2核4G”验收人无从判断你的结果是否靠谱如果填的是“鲲鹏处理器4 vCPU 8 GBaarch64OpenJDK 11”配合uname -m的截图整个报告就有了根基。4.2 命令记录与截图让 docx 不给人添堵的排版习惯写报告最常见的翻车是从终端复制代码进 Word 后缩进被吃掉或者中文注释乱成一团。我的做法是报告里出现的每一条命令先在本地编辑器里整理好再粘贴。具体来说1. 终端里执行命令时同步把命令和输出重定向到 run.log 2. 截图要截到终端窗口的标题栏和命令行提示符证明是在该环境下执行 3. 截图统一命名01-env-check.png、02-hdfs-start.png、03-job-submit.png按章节顺序编号 4. 粘贴代码时在 Word 里用“只保留文本”粘贴再手动套用等宽字体样式避免和默认正文字体混排 5. 请不要用深色终端主题截图打印出来会变成一团黑块。这里有个细节截图里带上命令行提示符的主机名和路径能直接证明这条命令是在你的云主机上跑的。网上抄来的教程截图大多没有这个上下文验收人一眼就能看出来。如果你用的是 root 用户提示符会是#普通用户是$截图时保持默认即可。4.3 环境信息表与结果表让数据替你说服人实验环境部分我建议直接用表格不要写长段落。一张干净的表格信息密度高也方便验收人对照检查。下表是我写报告时用的模板项目配置云主机规格4 vCPU / 8 GB 内存 / 40 GB 系统盘处理器架构鲲鹏处理器 920 系列aarch64 架构操作系统Linux 发行版内核 4.18aarch64 版本JDK 版本OpenJDK 11aarch64 版Hadoop 版本Apache Hadoop 3.3.6节点角色单节点NameNode DataNode 同机数据量模拟访问日志 20000 行 / 约 400KB实验结果有效 IP 数 2545 个最大访问量 87 次这个表里“有效 IP 数 2545 个”不是编的它来自对part-00000的统计你可以用wc -l数一下结果文件的行数。填这个数字比任何“完成了实验”的描述都有说服力。另外体系里不要写“xx 处理器系列”这种具体型号我没有在那个表格里写具体型号名称你按自己实际使用的主机规格填。5. 鲲鹏云实验的踩坑记录ARM 带来的五道坎5.1 执行 ./bin/hadoop 直接报 Exec format error现象hadoop version执行后报bash: /opt/hadoop/bin/hadoop: cannot execute binary file或者Exec format error。原因下载了 x86_64 架构的 Hadoop 发行包放在 aarch64 系统上自然无法执行。这个错误在下载软件时最容易犯因为很多下载站点给的是“通用包”实际只编译了 x86_64。解决回到下载页重新找aarch64或arm64的包拷贝到机器上重新解压。同时用file /opt/hadoop/bin/hadoop检查二进制文件格式输出里能看到ELF 64-bit LSB executable, x86-64或者aarch64这个命令能帮你快速判断手上文件的架构。5.2 DataNode 进程启动后几秒就消失现象start-dfs.sh后jps看不到 DataNode或者 DataNode 进程存在但是 HDFS 的 Web UI 里显示进程已经停止日志里报目录已存在或者权限错误。原因最常见的两种情况一是使用了/tmp作为数据目录系统重启后清空导致元数据不一致二是重复执行了namenode -format多个current目录冲突DataNode 启动时找不到匹配的命名空间 ID。解决停掉所有 Hadoop 进程stop-dfs.sh删除/home/bigdata/hdfs下所有数据如果有重要数据先备份重新hdfs namenode -format再启动。整个过程大约三分钟但能治本。我一般在报告里建议别人别把dfs.namenode.name.dir配到/tmp这就是踩过一次的代价。5.3 在 HDFS 上跑 Streaming 任务报 ClassNotFoundException现象使用hadoop jar hadoop-streaming-*.jar时显式指定了完整 jar 路径任务提交后报告找不到org.apache.hadoop.streaming.HadoopStreaming或类似类。原因命令里-jar参数后面穿的不是完整路径而是通配符*.jar。在部分 shell 环境下通配符没有被正确展开导致 Hadoop 拿到的是一个不存在的文件名。解决提交任务时用完整路径或者先cd到share/hadoop/tools/lib/目录再执行。老手习惯是先把 jar 路径存到一个变量里避免每次敲错STREAMING_JAR$(ls /opt/hadoop/share/hadoop/tools/lib/hadoop-streaming-*.jar) /opt/hadoop/bin/hadoop jar $STREAMING_JAR \ -files mapper.py,reducer.py \ -mapper python3 mapper.py \ -reducer python3 reducer.py \ -input /user/exp/input \ -output /user/exp/output5.4 ssh localhost 要求输密码免密配置不生效现象ssh localhost不直接返回而是要求输入密码或者在/var/log/secure日志里看到Permission denied (publickey)。原因~/.ssh目录权限是 755authorized_keys权限是 644SSH 服务出于安全考虑直接忽略公钥认证。这在云主机上很常见因为默认 umask 太宽松。解决执行chmod 700 ~/.ssh和chmod 600 ~/.ssh/authorized_keys。如果还不行检查/etc/ssh/sshd_config里有没有显式禁用 root 登录的配置有则改成PermitRootLogin yes并重启 sshd。这个坑不会影响大数据框架本身但会卡住整个实验的启动流程属于最气人的“小问题卡大进度”。5.5 docx 报告里代码缩进和中文注释全乱现象从终端复制命令和 Python 代码到 Word粘贴后代码里的 Tab 缩进消失中文变乱码或者变成问号。原因Terminal 复制的文本包含控制字符和 TabWord 默认粘贴时会重新解析缩进中文字符则因为字体不匹配被替换。解决先在本地编辑器VS Code 或 Notepad 均可把代码打开选择“复制带格式”然后粘贴到 Word 里已有的“代码”样式中。如果代码块在 Word 里依然乱不要再试图逐个空格去对齐直接用截图放进来。效果更好也更省时间。这一步虽然不在实验本身但它直接决定报告交付的质量值得专门花十几分钟处理。6. 给报告加分的小技巧把验证过程变成一条完整证据链建议在实验过程中从一开始就给每条命令做记录最后合到 docx 里。具体做法是登录主机后先执行script命令它会自动把终端里的所有输入输出保存到一份日志文件。等你跑完实验这份日志就是报告的原始素材不用回头补截图。# 记录终端会话到文件开始录制 script /home/bigdata/run.log # 之后执行的所有命令都会被记录包括输入和输出 uname -m hadoop version hdfs dfs -ls -h /user/exp/input/ # 结束录制 exitscript命令是 util-linux 自带的Linux 发行版基本都有不需要额外安装。录制文件里可能包含^H这样的控制字符用strings run.log或者cat -v检查一下确认内容可读后再引用。这样做的价值是写报告时可以直接从日志里摘录命令和输出不需要对着截图一个个敲字而且原始输出是真实执行的记录不会出现“复制了教程命令但自己没跑过”的尴尬。最后说一个我自己的教训。有一次我写了一份实验报告环境信息里写的是“某 x86 服务器”其实是在鲲鹏云上跑的验收的人一眼就看出来不对劲因为uname -m的截图就贴在同一个文档里前后矛盾。从那之后我的习惯是先跑命令、再截图最后根据截图写描述顺序不能反过来。环境信息一律以实际执行为准不凭记忆填不抄模板。整篇报告做到“每条结果都能在日志里找到对应命令”才算真正交付完成。跑通这个实验并写出一份像样的 docx其实就是在练习一套完整的交付习惯环境确认、数据准备、任务执行、结果采集、文档归档。在鲲鹏云上做一遍你还会多收获一条架构层面的经验——aarch64 上的大数据生态已经比前几年成熟很多Hadoop、Spark 这类基础组件直接跑没有问题真正需要留意的反而是 JDK 架构、安装包选型这些边边角角。希望这篇能帮你在做鲲鹏云实验的时候少走几个弯。本文还有配套的精品资源点击获取