企业官网建设流程全解析

简介：这份《大数据原理与技术课程实验报告》完整版，面向正在学习大数据入门课程的高校学生与自学者，聚焦Hadoop与Linux基础操作能力的实战训练。报告以“熟悉常用Linux操作和Hadoop操作”为主线，完整记录了从安装Ubuntu虚拟机、配置JDK环境变量，到搭建Hadoop伪分布式集群并运行WordCount实例的全过程，覆盖cd、ls、mkdir、rmdir、cp、mv、rm、cat、tac、more、head、tail、touch、chown、find、tar、grep等高频命令的详细用法与截图式输出，步骤清晰，便于对照练习和复习备考。资源共包含1个docx文档，整体约3.29MB，排版规范、内容完整，适合作为课程实验报告模板或Hadoop环境搭建的参考手册。目前已有5244人学习下载，经多人验证，内容扎实可靠。无论是用于完成课程作业、准备实验答辩，还是自行搭建大数据开发环境，都能从中获得可直接复用的操作路径和排错思路，帮助初学者少走弯路。

1. 这份实验报告的真正价值：用一台虚拟机把大数据的第一步踩平

《大数据原理与技术》这门课的第一道坎，往往不是 HDFS 原理，也不是 MapReduce 编程模型，而是“你还没见过 Hadoop 长什么样”。这份实验报告最实在的地方在于：它把「VirtualBox 装 Ubuntu → 练熟 Linux 命令 → 搭 Hadoop 伪分布式 → 跑通 WordCount → 操作 HDFS」整条链路串成了一个可以照着抄的作业。对正在补实验学分的学生来说，它是现成的模板；对刚接触大数据、想花一个晚上把环境跑起来的开发者来说，它把最容易卡住的三个坑——虚拟机分辨率、虚拟机联网、JAVA_HOME 没设置——全部提前标记出来了。我拆完这份报告最直接的感觉是：它不是什么高深理论，而是把“动手门槛”拆成了一个个可复现的步骤。

2. 搭建 Linux 实验环境：VirtualBox 与 Ubuntu 16.04 的分辨率和联网两个坑

2.1 为什么选 Ubuntu 16.04 而不是 20.04 或 22.04

实验报告的操作系统选的是 ubuntukylin-16.04，也就是优麒麟 16.04。很多初学者会纠结：现在 Ubuntu 都出到 22.04 了，为什么还要用老版本？原因有两个。

第一，教材和实验指导书的命令、截图、配置文件都是基于 16.04 写的，Hadoop 官方文档里老版本的兼容性说明也主要覆盖这个时期的系统。用新版本不是不行，但你会遇到 systemd 服务管理方式变化、默认 Python 版本不同、JDK 版本冲突等额外问题——这些都是教材没写、老师也不一定会提前说的。

第二，Hadoop 伪分布式本身对系统版本不敏感，它真正依赖的是 Java 环境。但实验报告里给的参考路径、配置文件的写法，全部基于 16.04 的目录结构。我一般会建议：跟着报告走，先用 16.04 把流程跑通；等理解了原理，再去新系统上折腾不迟。

虚拟机的选择上，报告用的是 VirtualBox。这个选择很务实——VMware Workstation 虽然也常见，但 VirtualBox 免费、跨平台、导出 ovf 方便，而且学生机配置一般不高，VirtualBox 对资源的要求更低一些。报告里的主机是 i5-10300H + 16GB 内存，给虚拟机分配 2~4GB 就足够跑伪分布式了。

2.2 安装顺序与增强功能：先把显示和联网问题解决掉

实验报告里记录的第一个问题是“安装界面分辨率太小，导致安装程序显示不完整”。这是 VirtualBox 装 Linux 的老大难，特别是 Ubuntu 的图形安装界面在默认 800×600 分辨率下，底部按钮会被屏幕边缘截掉。

常见做法是：先用键盘 Tab 键切换焦点、用回车确认，先把系统装完；装完后在 VirtualBox 菜单栏点击「设备 → 安装增强功能」，在虚拟机里运行挂载的 VBoxLinuxAdditions.run，重启后就能在系统设置里调整分辨率了。增强功能同时会改善剪贴板共享、拖拽文件和鼠标无缝切换，属于装完必做的操作。

# 在 ubuntukylin 虚拟机终端里执行 sudo apt-get update sudo apt-get install -y build-essential dkms linux-headers-$(uname -r) # 挂载增强功能镜像后执行 sudo mount /dev/cdrom /mnt cd /mnt && sudo ./VBoxLinuxAdditions.run --nox11 sudo reboot

这段的逻辑是：先装编译工具和内核头文件，因为增强功能需要编译内核模块；然后挂载 VirtualBox 随虚拟机窗口提供的 ISO 镜像，运行安装脚本。--nox11参数可以跳过 X11 图形依赖，在终端环境下安装更稳。如果你看到 "Building the main Guest Additions module" 字样且没有报错，说明安装成功。

提示：如果sudo mount /dev/cdrom /mnt提示找不到设备，检查 VirtualBox 菜单里「设备 → 安装增强功能」是否已经点击，这会虚拟出一个光驱。

2.3 多网卡主机的网络选择：为什么虚拟机“上不了网”

报告记录的第二个问题是“Ubuntu 安装完成后不能上网”。这在笔记本上尤其常见，原因很直接：VirtualBox 默认的网络地址转换（NAT）模式不需要你选网卡，但如果你在 VirtualBox 的全局设置里改成了「桥接模式」，宿主机有多块网卡时，虚拟机就不知道该桥接到哪一块上。

排查思路很简单：先看宿主机当前用的是哪块网卡上网。报告里的主机同时有有线网卡 Realtek PCIe GbE Family Controller 和无线网卡 MediaTek Wi-Fi 6 MT7921 Wireless LAN Card。如果当前用 Wi-Fi，那么 VirtualBox 桥接模式的「界面名称」就要选 MT7921 那块；如果插了网线，就选 Realtek 那块。

选错网卡的典型表现是：虚拟机里ping不通外网，但ping宿主机 IP 能通。这是因为桥接模式下，虚拟机和宿主机共享物理网卡的二层网络，网卡选错相当于把虚拟机接到了一个没有连出线的交换机上。

# 在虚拟机里检查网络状态 ip addr show ping -c 3 8.8.8.8 # 先测外网连通性 ping -c 3 192.168.1.1 # 再测网关连通性

ip addr show是查看 IP 地址是否分配成功；ping 8.8.8.8不通而ping 网关通，说明 DNS 或路由有问题；两者都不通，优先检查 VirtualBox 的网卡桥接设置。顺带说一句，16.04 里网络管理用的是ifupdown和 NetworkManager 共存，如果你改了/etc/network/interfaces文件后重启网络失败，多半是 NetworkManager 抢占了管理权，这属于另一个经典坑。

3. 18 组 Linux 命令实战拆解：从 cd 到 tar 的参数差异与易错点

3.1 目录操作六兄弟：cd、ls、mkdir、rmdir、cp、mv、rm

实验的第一大部分是 Linux 常用命令，报告里列了 18 组。这些命令看似基础，但每一组都有几个“考试不考、实操必踩”的参数坑。

先看cd。报告里三个用法：cd /usr/local是绝对路径切换，cd ..是回上一级，cd ~是回当前用户主目录。真正容易出错的是cd -（回上次目录）和cd ~hadoop（切到指定用户的主目录），前者在长路径来回切换时很有用，后者在管理多用户时很顺手。实验报告没写这两个，但做 Hadoop 操作时，你经常需要在/usr/local/hadoop和~之间来回跑。

mkdir的核心参数是-p。报告里mkdir -p a1/a2/a3/a4创建多级目录，这个参数同时有另一个隐藏作用：如果目录已存在，不会报错。很多新手在写脚本时用mkdir不加-p，同一段脚本跑第二次就中断，这就是没理解-p的幂等性。

cd /tmp mkdir -p a1/a2/a3/a4 # 等价于逐级创建，但一条命令搞定 rmdir -p a1/a2/a3/a4

rmdir -p的设计逻辑是：删除指定目录后，如果父目录也变空了，就一并删除。它和mkdir -p正好是镜像操作。但注意，rmdir只能删空目录，目录里有文件时会报 "Directory not empty"。这时候要用rm -R，也就是报告里删除 test2 目录用的命令。rm -R里的-R是递归，删除目录必须带，否则会提示 “cannot remove 'test2': Is a directory”。我在实际使用中还会加-f强制删除，但实验环境里建议不要加，留着确认提示反而安全。

cp和mv的坑在权限和跨文件系统。报告里sudo cp ~/.bashrc /usr/bashrc1把主目录下的隐藏文件复制到/usr下并重命名，这里必须有sudo，因为/usr目录属于 root。cp -r /tmp/test /usr复制目录要加-r，这个很容易漏。

mv看起来简单，但有一个语义细节：mv /usr/bashrc1 /usr/test是把文件移动到目标目录下；如果目标路径最后不带斜杠且不是一个已存在的目录，mv会把它当成重命名。报告里第二步mv /usr/test /usr/test2就是典型的目录重命名用法。跨文件系统移动时，mv实际执行的是复制+删除，大文件会慢，这是正常现象。

最后是ls，报告里用了ls -al。这里a是显示隐藏文件（以.开头的文件），l是长格式输出权限、属主、大小、时间。还有一个组合参数ls -lh，h是 human-readable，文件大小会显示成 4.0K、12M 这样的格式，查日志文件大小的时候比裸字节数友好得多。

3.2 文件内容查看的五种姿势：cat、tac、more、head、tail 的边界差异

报告把cat、tac、more、head、tail放在一起，这一组解决的是同一个问题：怎么快速看文件内容。但它们的适用场景完全不同。

cat适合看小文件，tac是反向输出，注意是逐行反向，不是逐字符反向。more适合看长文件，但它只能向下翻，less才是能上下翻的增强版——报告没写less，我建议你直接把它加进自己的命令清单。

head和tail是日志排查的利器。报告里用了head -n 20取前 20 行，head -n -50表示“不显示最后 50 行，只显示前面几行”。注意这里的负号参数是 GNU 扩展，macOS 自带的 BSDhead不支持。tail -n 20是取最后 20 行，tail -n +50是从第 50 行开始显示到文件末尾。

实操场景里，tail还有一个杀手级参数-f（follow），实时跟踪文件追加内容。排查 Hadoop 日志时，我会开一个终端窗口执行：

# 实时跟踪 HDFS 数据节点的日志 tail -f /usr/local/hadoop/logs/hadoop-hadoop-datanode-*.log

-f参数会让终端持续输出新追加的行，按Ctrl+C退出。这是排查启动失败时最有用的工具，比反复打开文件看效率高得多。

3.3 文件时间、属主、查找与压缩：touch、chown、find、tar 的实战语义

touch报告里演示了两个功能：创建空文件和修改文件时间。touch -d "5 days ago" hello把文件时间改成 5 天前。这个功能在实验里不起眼，但在实际项目里用来触发某些依赖文件时间戳的构建工具（比如 make）时很常用。

chown修改文件属主，报告里用的是sudo chown root /tmp/hello。注意chown只能由 root 执行，所以必须配sudo。实际工作中更常用的写法是chown -R hadoop:hadoop /usr/local/hadoop，把整个 Hadoop 安装目录归给 hadoop 用户，-R是递归，冒号前后分别是属主和属组。

find报告里只演示了find ~/.bashrc，这只是按文件名精确查找。实际最常用的是find /usr -name "*.xml"按通配符找文件，或者find . -size +100M找大文件。Hadoop 排错时，我经常用：

# 查找 hadoop 安装目录下所有日志文件 find /usr/local/hadoop/logs -name "*.log" -mtime -1

-mtime -1表示最近 24 小时内修改过的文件，配合日志排查很顺手。

tar的语法报告里出现了两个方向：打包和解包。tar -zcv -f /test.tar.gz test是打包加 gzip 压缩，tar -zxv -f /test.tar.gz -C /tmp是解压到指定目录。很多人会把参数顺序搞混，我的记忆方式是：zgzip 压缩、ccreate 创建、xextract 解压、vverbose 显示过程、ffile 指定文件名，-C指定解压目标。f后面紧跟文件名，这个顺序不能乱——tar -zcv test -f /test.tar.gz会报警告，虽然能执行但不符合规范。

3.4 环境变量配置：JAVA_HOME 为什么必须写死路径

报告里最后一部分 Linux 操作是配置环境变量，在~/.bashrc末尾追加 JDK 的JAVA_HOME、JRE_HOME、CLASSPATH和PATH。这里有一个被很多人忽略的关键点：报告原样写的是：

export JAVA_HOME=/usr/lib/jvm/jdk1.7.0_60 export JRE_HOME=${JAVA_HOME}/jre export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib export PATH=${JAVA_HOME}/bin:$PATH

但后面 Hadoop 启动报错时，解决方案里又把JAVA_HOME改成了/usr/lib/jvm/jdk1.8.0_162。这说明什么？环境变量配置和实际 JDK 版本要严格对应，千万不能照抄模板路径。我一般在配置完环境变量后，会强制走一遍三重验证：

# 验证 JDK 是否可用 java -version # 验证 JAVA_HOME 是否被正确读取 echo $JAVA_HOME # 验证 PATH 是否包含 JDK 的 bin 目录 which java

source ~/.bashrc让配置立即生效，这一步很容易漏。很多人配置完环境变量后直接新开终端发现命令不存在，就是因为环境变量只在当前 shell 生效过。另外，CLASSPATH前面的.表示当前目录，这个点是 Java 类搜索路径的一部分，漏掉会导致某些程序编译时找不到自己目录下的类。

4. Hadoop 伪分布式安装：从配置 XML 到 WordCount 跑通的完整链路

4.1 伪分布式与全分布式的取舍：为什么课程实验选它

实验报告用的是 Hadoop 伪分布式模式，也就是单台机器上同时运行 NameNode、DataNode、SecondaryNameNode 三个守护进程。这个模式在真实生产中不存在，但它是理解分布式系统的最好跳板。

伪分布式的本质是“用进程模拟节点”：一台机器上 NameNode 负责元数据管理，DataNode 负责数据存储，两者通过网络协议通信，和你将来在三台、五台机器上部署的架构逻辑完全一致。区别只在于，真实集群里 NameNode 和 DataNode 跑在不同机器上，伪分布式里它们共享同一份 CPU 和内存。

报告正文使用的是 Hadoop 3.1.3，摘要里提到了 2.7.1，两个版本的配置逻辑一致，核心就两件事：指定 NameNode 地址、指定数据副本数。伪分布式下副本数必须设为 1，因为只有一个 DataNode，副本数设 3 的话，数据写入会因为找不到足够的 DataNode 而卡住或报错——这是跟真实集群差异最大的一处配置。

4.2 core-site.xml 与 hdfs-site.xml：关键参数什么意思

Hadoop 的核心配置在/usr/local/hadoop/etc/hadoop/目录下。伪分布式必须修改两个文件：core-site.xml和hdfs-site.xml。

<!-- core-site.xml --> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> </configuration>

fs.defaultFS是 Hadoop 文件系统的默认地址，这里指定了 NameNode 的 RPC 通信端口为 9000。这个参数决定了你执行hdfs dfs -ls时，命令会连接到哪里。如果配置成file:///，那么操作的其实是本地文件系统，而不是 HDFS。

<!-- hdfs-site.xml --> <configuration> <property> <name>dfs.replication</name> <value>1</value> </property> </configuration>

dfs.replication是数据块副本数，伪分布式必须设 1。还有一个参数在后续实验中会遇到——dfs.namenode.name.dir和dfs.datanode.data.dir，分别指定元数据和数据块的存储目录。报告没写这两个，但如果你之后想换数据存储位置，就需要改它们。默认情况下数据存在/tmp目录下，重启可能会丢，这是另一个隐患。

4.3 格式化、启动与 jps 验证：每一步看什么输出

配置完后第一步是格式化 NameNode：

cd /usr/local/hadoop ./bin/hdfs namenode -format

这里有一个关键提醒：格式化操作会在 NameNode 的元数据目录里生成一个current目录，里面是fsimage和edits文件。这个操作在首次安装时必须做，但以后不能随便重复执行——每次格式化都会重新生成元数据，如果旧的数据节点还连着，会导致集群报错。格式化成功的标志是日志末尾出现 "successfully formatted" 字样，并且退出状态码为 0。

启动命令是./sbin/start-dfs.sh，报告特别标注了“中间没有空格”。这个常见提醒是因为有人会在文件名的点号或斜杠前敲出空格。启动后必须用jps验证：

jps

jps是 JDK 自带的工具，专门查看 Java 进程。正常启动后你会看到三个进程：NameNode、DataNode、SecondaryNameNode。如果只有jps自身那个进程，说明启动失败。我通常会先执行jps快速判断，然后立刻用tail -f查看对应日志。

如果start-dfs.sh报错 “JAVA_HOME is not set”，这是第 3 章末尾埋的雷。解决办法在报告里写得很明确：编辑/usr/local/hadoop/etc/hadoop/hadoop-env.sh，找到export JAVA_HOME=${JAVA_HOME}这一行，把它改成写死的路径：

# hadoop-env.sh 中修改这一行 export JAVA_HOME=/usr/lib/jvm/jdk1.8.0_162

原因在于 Hadoop 的启动脚本虽然有默认的JAVA_HOME查找逻辑，但在某些系统和 shell 环境下，继承不到你在~/.bashrc里导出的环境变量。写死路径是伪分布式搭建里最稳妥的做法。

4.4 跑通 WordCount：验证安装的最终标准

Hadoop 自带的示例 JAR 包里有一个wordcount程序，它几乎被当作“Hadoop 版 Hello World”。报告里的完整命令是：

cd /usr/local/hadoop ./bin/hadoop jar ./share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount input output

拆开看：hadoop jar是提交 MapReduce 任务的入口；hadoop-mapreduce-examples-3.1.3.jar是示例程序所在的 JAR 包；wordcount是 JAR 包里的一个程序类名；input是输入目录，output是输出目录。

这里有两个参数细节。第一，input和output默认在 HDFS 上，如果直接执行会提示找不到文件和目录。报告第 5 章会演示先把本地文件put到 HDFS，这里的前提是你已经创建了对应的输入路径。第二，output目录必须不存在，MapReduce 框架会主动检查，如果输出目录已存在会直接报错FileAlreadyExistsException。跑完以后，用hdfs dfs -cat output/part-r-00000查看结果文件。

我还记得第一次跑通 wordcount 时，看着终端里滚动的一行行map 100% reduce 100%，那感觉确实不一样。但这里要泼一盆冷水：如果你在这个阶段jps显示进程正常、Web UI 能访问，Experiment 就算过了；可距离真正的“会操作 Hadoop”，还差一个 HDFS 文件操作的熟练度。

5. HDFS 文件操作与避坑自查：put/get 闭环和三起典型故障的排查

5.1 HDFS 用户目录与目录管理：为什么每个用户都有独立目录

报告第 4 部分演示了 HDFS 的常用操作，核心是hdfs dfs命令。第一步是创建用户目录：

cd /usr/local/hadoop ./bin/hdfs dfs -mkdir -p /user/hadoop

注意这里的/user/hadoop不是 Linux 本地路径，而是 HDFS 上的路径。HDFS 有自己的命名空间，和本地文件系统完全隔离。-p参数和mkdir一样，递归创建父目录。

创建 HDFS 目录后，用./bin/hdfs dfs -ls查看文件列表。你会发现 HDFS 的ls输出和 Linux 的ls -l格式非常接近，但也有差异：HDFS 输出里没有文件属主组的概念（所有文件属主都是启动 HDFS 的用户），且不像 Linux 那样区分普通文件和目录的权限位（HDFS 只有读、写、执行三个粗粒度权限）。

5.2 put/get 上传下载：一条完整的双向链路

报告演示了完整的 put/get 闭环：

# 上传：把本地文件复制到 HDFS ./bin/hdfs dfs -put ~/.bashrc test # 查看 HDFS 上 test 目录的内容 ./bin/hdfs dfs -ls test # 下载：把 HDFS 文件复制回本地 ./bin/hdfs dfs -get test ./

-put有两个参数，第一个是本地路径~/.bashrc，第二个是 HDFS 路径test。注意第二个参数是相对路径，实际位置取决于当前用户的 HDFS 家目录。因为前面已经创建了/user/hadoop，Hadoop 会解析test为/user/hadoop/test。

-get正好相反，把 HDFS 路径复制到本地。报告里./表示当前目录。这组命令的完整逻辑比看起来重要：Hadoop 分布式计算的数据入口和出口都靠这对命令打通，后续跑任何 MapReduce 任务都离不开。实际操作中，我会先-ls确认路径存在再-put，避免白等一次网络传输。

提示：hdfs dfs和hadoop fs在较新版本里等价，早期版本两者有细微差异。实验环境用hdfs dfs更规范，它明确表示操作的是 HDFS 文件系统，而hadoop fs可以对接本地文件系统等多个后端。

5.3 避坑自查：三起典型故障的现象、原因与解决

这一节集中梳理实验报告里记录的三个问题，以及我在其他环境里遇到的类似翻车，每条都按“现象 → 原因 → 解决”的排查思路写。

故障一：虚拟机安装界面分辨率太小，按钮显示不完整。

现象：Ubuntu 安装程序底部按钮（如“继续”“安装”按钮）被屏幕边缘裁掉，鼠标无法点击。

原因：VirtualBox 默认给虚拟显卡的显存和分辨率都有限，Ubuntu 安装界面的自适应分辨率没有生效。

解决：用键盘 Tab 键切换焦点、回车确认完成安装。装完后点击 VirtualBox 菜单「设备 → 安装增强功能」，在虚拟机内执行sudo ./VBoxLinuxAdditions.run，重启后即可在系统设置中调整分辨率。如果增强功能安装失败，先执行sudo apt-get install -y build-essential dkms linux-headers-$(uname -r)补编译环境。

故障二：虚拟机装完上不了网。

现象：虚拟机内 Firefox 无法打开网页，ping 8.8.8.8不通。

原因：桥接模式选错了物理网卡。笔记本同时存在有线网卡 Realtek 和无线网卡 MediaTek Wi-Fi 6 MT7921，虚拟机桥接到未激活的网卡上，相当于网线没插。

解决：在 VirtualBox 中「设置 → 网络 → 桥接模式」，界面名称选择当前宿主机实际联网的网卡。插网线选 Realtek，连 Wi-Fi 选 MT7921。如果不能确定，可以在宿主机执行ipconfig（Windows）查看有默认网关的网卡。

故障三：start-dfs.sh报错JAVA_HOME is not set。

现象：执行./sbin/start-dfs.sh后，终端输出ERROR: JAVA_HOME is not set and could not be found.，集群没有启动。

原因：hadoop-env.sh里的默认配置是export JAVA_HOME=${JAVA_HOME}，它试图继承系统环境变量，但启动脚本的 shell 环境没有正确传递该变量，导致值为空。

解决：编辑/usr/local/hadoop/etc/hadoop/hadoop-env.sh，将JAVA_HOME改为 JDK 具体路径，比如export JAVA_HOME=/usr/lib/jvm/jdk1.8.0_162，保存后重新执行start-dfs.sh。

故障四（扩展）：格式化后重启虚拟机，HDFS 数据丢失。

现象：重启虚拟机后，jps显示 NameNode 正常，但hdfs dfs -ls报错或数据目录为空。

原因：默认的dfs.name.dir和dfs.data.dir指向/tmp目录，系统重启清空了临时目录，NameNode 的元数据和 DataNode 的数据块全部丢失。

解决：在hdfs-site.xml中配置持久化目录。常见做法是：

<property> <name>dfs.namenode.name.dir</name> <value>/usr/local/hadoop/data/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/usr/local/hadoop/data/datanode</value> </property>

改完配置后需要重新格式化 NameNode。这个坑在实验阶段不容易暴露，因为你每次操作都在同一会话内完成；但只要你关掉虚拟机再打开，就会感受到什么叫“白干一场”。我后来养成的习惯是：装完 Hadoop 第一件事就是把这两个目录改出/tmp。

6. 吃透这份实验报告：三个进阶验证技巧

6.1 用 Web UI 把 HDFS 状态看明白

报告里提到“访问 Web 界面”但没展开。Hadoop 3.x 的 NameNode Web UI 默认端口是 9870（2.x 是 50070），在浏览器输入http://localhost:9870就能看到集群概览：容量、存活节点数、数据块数量。如果你在宿主机上访问虚拟机里的 Web UI，需要把地址改为虚拟机的 IP，并确保防火墙放行。

排查时我经常用 Web UI 里的「Datanodes」页签查看每个 DataNode 的状态。如果某个节点显示In Service但容量为 0，通常是数据目录权限或磁盘空间问题。顺便说一句，Web UI 的日志功能能直接看到 NameNode 的运行日志，比在终端翻文件方便。

6.2 用自定义文本验证 WordCount 的统计逻辑

跑官方的 LICENSE.txt 只能证明“任务能跑通”，验证不了你对 MapReduce 流程的理解。我建议自己造一份输入数据，比如统计一段有重复单词的中英文混合文本：

# 在本地准备输入文件 echo "hello hadoop hello world hadoop hadoop" > /tmp/input.txt # 上传到 HDFS hdfs dfs -mkdir -p /user/hadoop/wordcount-input hdfs dfs -put /tmp/input.txt /user/hadoop/wordcount-input/ # 执行 WordCount cd /usr/local/hadoop ./bin/hadoop jar ./share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount /user/hadoop/wordcount-input /user/hadoop/wordcount-output # 查看输出 hdfs dfs -cat /user/hadoop/wordcount-output/part-r-00000

预期输出应该是hadoop 3、hello 2、world 1这样的统计结果。检查输出时注意两点：一是单词的大小写被严格区分，Hello和hello会被统计成两个词；二是标点符号会影响分词，world,会被当成一个单词。理解这几点，能帮你将来调试自己的 MapReduce 作业时少走弯路。

6.3 用-du和-stat检查数据是否真的落盘

伪分布式只有一台机器，很多新手会有疑虑：“我的数据到底存到哪了？”两个命令能验证：

# 查看 HDFS 目录的磁盘占用 hdfs dfs -du -h /user/hadoop # 查看单个文件的元数据详情 hdfs dfs -stat "%b %o %r %y %n" /user/hadoop/wordcount-input/input.txt

-du -h的h是 human-readable，输出file size和directory size。-stat的参数格式里%b是文件大小（字节数）、%o是块大小、%r是副本数、%y是最后修改时间、%n是文件名。这个命令能让你直观看到replication=1的配置到底体现在哪里。你还可以对比本地文件大小和 HDFS 上的%b，验证数据是否完整传输。

复盘这份实验报告，我发现最有价值的其实不是命令本身，而是它把「排查问题」这件事提前摆到了台面上。三个官方记录的问题——分辨率、联网、JAVA_HOME——每一个都是我后来帮别人搭环境时反复遇到的。从那以后我每次装完 Hadoop，都强制走一遍三验证：jps看进程、Web UI 看状态、跑一次 WordCount 看输出。三个全绿才算安装完成。这个习惯帮我挡掉了无数个“明明装了却总感觉哪里不对”的玄学问题。希望帮到你。

本文还有配套的精品资源，点击获取