简介:这是一份面向大数据初学者的Linux与Hadoop实验讲义,以单个Word文档形式呈现完整实验指导,适合高校课程实训、毕业设计准备或个人自学。文档围绕三大核心模块展开:一是Linux虚拟机安装,推荐在Windows下使用VirtualBox部署Ubuntu 18.04;二是常用Linux命令训练,覆盖cd、ls、mkdir、rmdir、cp、mv、rm、cat、tac、more、head、tail、touch、chown、find、tar、grep等近20个高频命令,并包含vim配置Java环境变量的细节;三是Hadoop 3.1.3伪分布式环境搭建,涉及启动服务、创建HDFS用户目录、上传下载文件以及运行WordCount实例验证。每个操作步骤都给出了具体指令和预期结果,方便边看边练,减少环境搭建和命令使用中的常见困惑。资源包内仅含1个docx文件,压缩后大小289KB,轻量易用,可以直接在Word中打开阅读或打印。目前已有977人学习下载,对希望快速入门大数据环境操作的学习者来说,是一份高性价比的参考资料。
1. 伪分布式 Hadoop 实验:最容易翻车在“格式化”这一步
大数据实验的第一关,几乎都是同一个动作:先在 Windows 上装一台 Linux 虚拟机,再把 Hadoop 跑起来。这个流程看起来简单,实际走一遍你会发现,真正卡住你的往往不是 Linux 命令记不熟,而是 Hadoop 伪分布式环境里那些“玄学”问题——比如明明跟着教程一步一步配好了,jps 一看 Datanode 没启动,打开 9870 端口页面,LiveNode 数量显示为 0。这个坑我当年踩过,一度以为是网络问题,查了一晚上才发现是多次执行 hadoop namenode -format 导致 Datanode 的 Cluster-Id 和 NameNode 对不上。这篇文章就是要把 Linux 虚拟机、常用命令、Hadoop 3.1.3 伪分布式安装和 HDFS 操作串成一条能走通的路,新手照着做能落地,熟手也能看到版本差异和参数取舍。
2. 装虚拟机:VirtualBox 6.1.4 与 Ubuntu 18.04 的组合
2.1 为什么默认选 VirtualBox 而不是 VMware
实验平台部分明确推荐 VirtualBox,理由很实在:免费、开源、跨平台,在 Windows 上安装 VirtualBox 之后,可以虚拟 Windows、macOS、Linux 甚至 Android 系统。我在做这个实验的时候用的是 VirtualBox 6.1.4,配合 Ubuntu 18.04 桌面版镜像,整体稳定性不错。如果你之前已经装好了 VMware Workstation,也不必卸载重装——后面所有操作在 VMware 里同样成立,只是创建虚拟机那一步的界面选项略有不同。
选 Ubuntu 18.04 而不是最新版本,倒不是新版本不好,而是大数据生态的兼容节奏通常慢半拍。实验原文给的是 Ubuntu 18.04 或 16.04,Hadoop 3.1.3 在这两个版本上跑得最稳。如果你机器配置一般,16.04 更省内存;如果你希望桌面环境顺手一点,18.04 的 GNOME 用起来更现代。我的建议是 18.04,教程覆盖多,遇到问题搜解决方案最容易命中。
2.2 Windows 上安装 VirtualBox 6.1.4 的要点
VirtualBox 的安装包在官网可以直接下载到 6.1.4 的 Windows 版本,文件名形如 VirtualBox-6.1.4-136177-Win.exe。安装过程基本是下一步到底,但有两个位置需要手动确认一下。
注意:安装路径不要带中文或空格,默认的 C:\Program Files\Oracle\VirtualBox 可以用,但如果你习惯把软件装在 D 盘,请建一个纯英文目录,比如 D:\VirtualBox。
安装过程中会提示安装网络驱动和 USB 驱动,这里务必允许安装。VirtualBox 的网络功能依赖这些驱动,如果跳过,后面虚拟机可能无法联网,你会误以为是自己网络配置出了问题。安装完打开 VirtualBox,主界面能看到左侧的虚拟机列表和右侧的详细设置区域,到这里虚拟机软件就算就位了。
2.3 创建虚拟机和安装 Ubuntu 18.04
打开 VirtualBox,点击“新建”,名称填 ubuntu1804,类型选 Linux,版本选 Ubuntu (64-bit)。内存我直接给 4096 MB,如果你的宿主机是 8 GB 内存,最低也要分 2 GB 给虚拟机,否则 Hadoop 跑起来会非常吃力。虚拟硬盘选择“现在创建虚拟硬盘”,类型选 VDI,大小建议 25 GB 起步,动态分配即可,实际用多少占多少。
虚拟机创建好之后,点击“设置 → 存储”,在光驱里挂载下载好的 Ubuntu 18.04 桌面版 ISO 镜像,然后启动虚拟机。Ubuntu 安装界面里选“Install Ubuntu”,语言默认 English 或中文都行,键盘布局选 English (US),安装类型直接选“Erase disk and install Ubuntu”,这里擦除的是虚拟磁盘,不影响 Windows 宿主机。安装过程中会让你创建用户名和密码,记住这个用户,后面所有 Hadoop 操作都会用到。
安装完成后重启,虚拟机会从虚拟硬盘启动进入 Ubuntu 桌面。到这里 Linux 虚拟机已经可以用了。但如果你想用宿主机直接 SSH 到虚拟机操作,还需要处理网络和 SSH 服务。
2.4 配置网络与安装增强工具
默认情况下,VirtualBox 给虚拟机分配的是 NAT 网络,虚拟机可以访问外网,但宿主机访问不到虚拟机。我的做法是加一张“仅主机网络”网卡:虚拟机设置 → 网络 → 启用第二块网卡,连接方式选“仅主机网络”。这样虚拟机会多分配一个 192.168.56.x 网段的 IP,宿主机和虚拟机之间互通,既不影响 NAT 上网,又能直接 SSH。
进入虚拟机后,先更新软件源并安装 SSH 服务:
sudo apt update sudo apt install -y openssh-server ip addr show第一行命令刷新软件包索引,第二行安装 SSH 服务端,第三行查看虚拟机当前的 IP 地址。如果 ip addr 显示两个网卡,找到 192.168.56.x 那个地址,宿主机上就能用 ssh 用户名@192.168.56.xxx 连过去了。
增强工具的作用是让虚拟机支持共享剪贴板、拖拽文件、自适应分辨率。在 VirtualBox 菜单栏点“设备 → 安装增强功能”,Ubuntu 桌面会弹出光盘,打开光盘目录后执行:
sudo ./VBoxLinuxAdditions.run执行完重启虚拟机,分辨率就能跟随窗口自动缩放了。装增强工具这一步建议不要跳,否则命令行操作和复制粘贴都很难受。
2.5 装完先存个快照
这是我最想强调的一点:在干净的 Ubuntu 18.04 系统里,VirtualBox 菜单栏“控制 → 生成快照”,起个名字叫“fresh-ubuntu”。快照相当于后悔药,后面配置 Hadoop 改坏文件、格式化出错、环境变量写废了,一键回到这个干净状态,比重新装系统快得多。我做实验的习惯是每完成一个阶段就生成一个新快照,比如“jdk-installed”“hadoop-configured”,这样每一步都有退路,排查问题也方便定位是哪一步引入的故障。
3. 熟悉 Linux 命令:把 bash 操作练成肌肉记忆
3.1 目录切换与查看:cd、ls、mkdir
实验要求的第一批命令是 cd、ls、mkdir,看起来简单,但它们是后续所有 Hadoop 操作的基础。我建议你不要挨个命令孤立练习,而是跟着一个完整场景走一遍,比如把自己想象成在 /usr/local 下面建设一个实验目录。
cd /usr/local ls -l mkdir -p /tmp/a1/a2/a3/a4 ls /tmp第一条命令切到 /usr/local,第二条命令用 -l 参数查看详细文件列表,第三行的 -p 参数会自动创建多级目录,一次性建出 a1/a2/a3/a4 四层结构,第四行确认 /tmp 下的目录。cd 命令后面不跟路径时回到当前用户主目录,cd .. 回到上一级;ls 命令最常用的参数是 -l 显示权限和所有者、-a 显示隐藏文件。练习时你先在 /tmp 下建一个 a 目录,再删除它,体会 mkdir 和 rmdir 的配合——rmdir 只能删除空目录,如果目录里有内容会报错,这时候就需要 rm -r 出场了。
3.2 复制、移动和删除:cp、mv、rm
cp、mv、rm 是日常操作里最容易误伤三连,尤其是 rm -rf,无数人栽在上面。实验里的练习是把主目录下的 .bashrc 复制到 /usr 下并改名 bashrc1,再把 test 目录复制到 /usr 下。对应的命令是:
cp ~/.bashrc /usr/bashrc1 mkdir -p /tmp/test cp -r /tmp/test /usr/test mv /usr/bashrc1 /usr/test/bashrc1 mv /usr/test /usr/test2 rm /usr/test2/bashrc1 rm -r /usr/test2cp 复制单文件不需要额外参数,复制目录必须加 -r;mv 既可以移动也可以重命名,移动时如果目标路径存在同名目录,文件会进入该目录;最后 rm 删文件和 rm -r 删目录,实验报告里还提到用 rm -rf 删除 Hadoop 的数据缓存目录,那个 -f 表示强制删除不询问。-rf 组合威力很大,用之前一定确认当前路径和目录名没写错,我在生产环境养成的习惯是删除前先 ls 一下目标路径,确认它确实是要删的东西。
3.3 查看文件:cat、tac、more、head、tail
查看文件内容这组命令,实验要求对 ~/.bashrc 反复操作。cat 正向看全文,tac 反向看全文(实际是从最后一行开始输出),more 适合长文件一页一页翻,head 和 tail 分别取头部和尾部。
cat ~/.bashrc tac ~/.bashrc more ~/.bashrc head -n 20 ~/.bashrc tail -n 20 ~/.bashrchead -n 20 只看前 20 行,tail -n 20 只看最后 20 行。实验里还有一个需求是“不显示后面 50 行,只显示前面几行”,这个用 head 加行数实现,比如 head -n 50 取前 50 行,超过的部分自然不显示。tail 有个延伸用法是 tail -f 实时跟踪日志文件,后面排查 Hadoop 启动问题时你会频繁用到它。
3.4 时间修改、属主变更、查找与压缩:touch、chown、find、tar、grep
这组命令里有个很容易被忽略的细节:touch 不只是创建空文件,它真正的功能是修改文件时间戳。实验要求在 /tmp 下创建空文件 hello,再把它的时间改成 5 天前,命令是:
touch /tmp/hello touch -d "5 days ago" /tmp/hello ls -l /tmp/hello chown root:root /tmp/hello find ~ -name ".bashrc" tar -zcvf /test.tar.gz /test tar -zxvf /test.tar.gz -C /tmp grep "examples" ~/.bashrctouch -d 后面接时间字符串,可以把文件时间改成指定日期;chown 修改文件所有者为 root,这在你以后给 Hadoop 指定数据目录、调整目录归属时经常用到;find 用 -name 按文件名精确查找;tar 的 -zcvf 是打包并 gzip 压缩,-zxvf 是解压,-C 指定解压目标目录。grep 是字符串搜索的核心工具,实验里从 .bashrc 中查找 examples 这个单词,返回的是包含关键字的整行内容,这个命令在排查日志时非常好用。
3.5 配置 Java 环境变量:vim 编辑与 source 生效
实验要求用 vim 编辑 ~/.bashrc 配置 JAVA_HOME,这一步早配晚配都要配,因为 Hadoop 启动时必须找到 Java。
vim ~/.bashrc export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export PATH=$PATH:$JAVA_HOME/bin source ~/.bashrc echo $JAVA_HOMEvim 打开文件后,按 i 进入插入模式,光标移到文件末尾添加两行 export,按 Esc 退出插入模式,输入 :wq 保存退出。source 命令让配置立即生效,然后 echo $JAVA_HOME 验证变量值是否正确。注意 JAVA_HOME 的路径要以你实际安装的 JDK 路径为准,如果记不清,可以用 readlink -f $(which java) 反查真实路径。这段配置很多人写错的地方是 PATH 那一行没有把 $JAVA_HOME/bin 加到原有 PATH 前面或后面,导致 java 命令找不到,检查时优先看这个变量是否完整。
4. Hadoop 3.1.3 伪分布式安装:JDK、SSH 与三个核心配置
4.1 版本选择与前置依赖清单
Hadoop 3.1.3 是实验指定的版本,我建议你严格按这个版本来,不要随手装 3.3.x 或 2.7.x。一是教程和实验步骤都基于 3.1.3,二是 3.x 系列的端口和 2.x 不同——比如 NameNode Web UI 从 50070 换成了 9870,如果你装 2.x,访问 9870 端口必然打不开页面。伪分布式模式意味着用一台机器模拟一个最小集群,所有守护进程都在本机运行,数据块副本数必须设置成 1,这些配置在 hdfs-site.xml 里体现。
前置依赖有三个:JDK 8、SSH 免密登录、hadoop 用户。JDK 用 OpenJDK 8 即可,Linux 下执行 apt install openjdk-8-jdk 安装;SSH 免密是为了让本机启动 DataNode 时不需要反复输密码。我在实验中用了一个名为 hadoop 的专用用户,避免用 root 直接跑 Hadoop,root 跑 Hadoop 容易因为文件权限问题出现各种怪异的启动失败,而且实验第四部分明确要求“使用 hadoop 用户登录 Linux 系统”。
4.2 创建 hadoop 用户并配置免密 SSH
sudo useradd -m hadoop sudo passwd hadoop sudo usermod -aG sudo hadoop su - hadoop ssh-keygen -t rsa -P "" -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ssh localhostuseradd -m 创建用户并同时生成主目录,passwd 设置密码,usermod -aG sudo 把用户加入 sudo 组。ssh-keygen 生成 RSA 密钥对,-P "" 表示私钥不设置口令,-f 指定密钥文件路径。把公钥追加到 authorized_keys 之后,ssh localhost 测试免密是否生效——第一次连接会提示确认主机指纹,输入 yes,第二次连接就不再要密码了。这一步如果失败,后续 start-dfs.sh 启动时会在本机 ssh 环节卡很久甚至报错。
4.3 下载解压 Hadoop 并处理安装目录
Hadoop 3.1.3 的 tar.gz 包从 Hadoop 官网下载,文件大约 400 MB,解压后我放在 /opt/module/hadoop-3.1.3。实验正文里写的安装目录是 /usr/local/hadoop,两种路径习惯都可以,关键是所有配置文件里的路径要和实际一致,不要混用。
sudo tar -zxvf hadoop-3.1.3.tar.gz -C /opt/module sudo chown -R hadoop:hadoop /opt/module/hadoop-3.1.3 cd /opt/module/hadoop-3.1.3 mkdir -p data/tmp data/namenode data/datanodetar 解压到 /opt/module 后,chown 把整个目录的属主改成 hadoop 用户,否则启动时写入临时文件会权限不足。data 目录是我自己手动创建的,用来承接 NameNode 元数据、DataNode 数据块和临时目录,这里的路径在 core-site.xml 和 hdfs-site.xml 里会被引用。你完全可以用 Hadoop 默认的 /tmp 和 /var 路径,但默认路径容易被系统清理,实验做到一半数据丢了很难判断是配置问题还是清理问题,显式指定一个独立数据目录更省心。
4.4 配置 hadoop-env.sh:告诉 Hadoop Java 在哪
Hadoop 自身不感知系统里装了哪个 Java,必须在 etc/hadoop/hadoop-env.sh 里显式声明 JAVA_HOME。用 vim 打开文件,找到 export JAVA_HOME 那一行,把它改成实际路径:
vim /opt/module/hadoop-3.1.3/etc/hadoop/hadoop-env.sh export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64这一步最隐蔽的坑是,有人图省事只配了 ~/.bashrc 里的 JAVA_HOME,没改 hadoop-env.sh,结果执行 hadoop 命令时终端里明明能 echo 出 JAVA_HOME,Hadoop 脚本却依然报错找不到 Java。原因是 Hadoop 的启动脚本加载的是自己环境变量文件,不会自动读取你用户的 .bashrc,两个位置都需要配置。配完可以用 hadoop version 验证,能输出版本信息就说明 Java 解析成功。
4.5 配置 core-site.xml:默认文件系统与临时目录
core-site.xml 是 Hadoop 的核心配置,最重要的是指定默认文件系统和临时数据目录。打开 etc/hadoop/core-site.xml,在 configuration 标签内加入:
<property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/module/hadoop-3.1.3/data/tmp</value> </property>fs.defaultFS 决定了 Hadoop 默认操作的文件系统是 HDFS,9000 是 NameNode 的 RPC 通信端口;hadoop.tmp.dir 是 NameNode 和 DataNode 存放数据的根目录,我统一指到刚才创建的 data/tmp 下。这个路径在第 5 章的排错中会再次出现——多个实验者遇到的 Cluster-Id 不一致问题,最后就是删除这个目录下的数据并重新格式化解决的。
4.6 配置 hdfs-site.xml:副本数必须设成 1
伪分布式没有多个节点,HDFS 默认的副本数为 3,在单节点上跑会因为找不到第二个、第三个 DataNode 而一直处于 under-replicated 状态。hdfs-site.xml 里第一件事就是把副本数改成 1:
<property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/opt/module/hadoop-3.1.3/data/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/opt/module/hadoop-3.1.3/data/datanode</value> </property>dfs.replication 设为 1 表示每个数据块只存一份;dfs.namenode.name.dir 和 dfs.datanode.data.dir 分别指定元数据和数据块的物理存放位置。如果你不显式配置后两项,NameNode 和 DataNode 会基于 hadoop.tmp.dir 的默认子目录存放数据,但显式写出来之后,第 5 章排查 Cluster-Id 时会更清楚该删哪些目录。
4.7 格式化 NameNode 并启动 HDFS
配置完成后,首次启动前必须执行格式化,这个动作会初始化 HDFS 的文件系统元数据,同时生成 NameNode 和 DataNode 共享的 Cluster-Id。格式化只需要执行一次:
cd /opt/module/hadoop-3.1.3 bin/hdfs namenode -format sbin/start-dfs.sh jps格式化时注意看终端输出里是否有 “successfully formatted” 字样。start-dfs.sh 会依次启动 NameNode、DataNode 和 SecondaryNameNode,启动后立刻执行 jps 查看 Java 进程。正常情况下你应该看到 NameNode、DataNode、SecondaryNameNode 三个进程,如果你之前也配置了 YARN,再执行 sbin/start-yarn.sh 会多出 ResourceManager 和 NodeManager,完整就是 5 个进程。如果 jps 里只有 NameNode 和 SecondaryNameNode,DataNode 没出现,说明这个 4.7 节之后的步骤出了问题,直接跳到第 5 章排查。
启动完成之后,用浏览器打开 http://localhost:9870,这是 Hadoop 3.x 的 NameNode Web 界面,能看到集群状态、DataNode 列表、文件系统使用情况。页面里 LiveNode 的数量是你判断 HDFS 是否真正健康的第一指标。
5. 排查与避坑:Datanode 起不来、9870 端口 Livenode 为 0
5.1 现象:jps 看不到 Datanode 进程
执行 jps 之后,输出里只有 NameNode 和 SecondaryNameNode,Datanode 没有启动。很多人的第一反应是重新执行 start-dfs.sh,结果还是会发现 Datanode 进程刚起来就退出了,甚至压根没起来。
原因绝大多数时候出在数据目录的元数据不一致上。DataNode 启动时会读取自己的数据目录里的 version 文件,里面有 clusterId 字段,它必须和 NameNode 元数据里的 clusterId 一致,不一致时 DataNode 会主动退出并报错。日志会在 /opt/module/hadoop-3.1.3/logs 下生成,文件名形如 hadoop-hadoop-datanode-机器名.log。
解决方法是先停止所有服务,删除数据目录,重新格式化:
sbin/stop-all.sh rm -rf /opt/module/hadoop-3.1.3/data mkdir -p /opt/module/hadoop-3.1.3/data/tmp /opt/module/hadoop-3.1.3/data/namenode /opt/module/hadoop-3.1.3/data/datanode bin/hdfs namenode -format sbin/start-all.sh jps这里 rm -rf 删除的是 core-site.xml 里 hadoop.tmp.dir 指向的整个 data 目录,以及 hdfs-site.xml 里显式配置的 namenode 和 datanode 数据目录。删完之后重新格式化并重启,DataNode 就会带着新的 Cluster-Id 正常加入。这个操作的代价是 HDFS 里之前存储的数据全部丢失,所以只适合实验环境,生产环境绝对不能用这种粗暴方式。
5.2 现象:9870 端口页面打不开,或 Livenode 数量为 0
9870 页面能打开但 LiveNode 显示 0,和页面完全打不开是两种不同的问题。页面打不开,先确认 NameNode 进程还在不在,再确认访问的是 9870 而不是旧的 50070;虚拟机里跑的话,检查浏览器访问的地址是 localhost 还是虚拟机 IP,如果从宿主机访问虚拟机 Web UI,需要配置端口转发或使用桥接网络。
LiveNode 为 0 通常就是 5.1 节的问题:DataNode 没起来,或者起来了又退出。页面上的 LiveNode 列表是根据 NameNode 收到的 DataNode 心跳统计的,DataNode 每 3 秒发送一次心跳,如果进程不存在,自然不会出现在列表里。我一般会先执行 jps 确认进程,再去 logs/hadoop-hadoop-datanode-*.log 里搜 Caused by 关键字——很多时候原因就藏在异常堆栈的最后一行。
5.3 核心坑:多次执行 namenode -format 导致 Cluster-Id 不一致
这是实验记录里最经典的一个坑,也是我开篇提到的那次血泪教训。现象是:之前反复执行过 hadoop namenode -format,某次启动后发现 Datanode 启动不了,9870 页面 Livenode 为 0。查 CSDN、查日志后确认,问题是格式化太多次,NameNode 每次格式化会生成新的 Cluster-Id,如果 Datanode 的本地数据目录没被同步清除,它会保留第一次格式化时记录的旧 Cluster-Id,两边对不上,DataNode 拒绝注册。
原因就是 NameNode 和 DataNode 的 version 文件里 clusterId 不一致。格式化本质上是重建 HDFS 元数据,而 DataNode 的数据不是每次格式化都会自动清掉的。解决步骤在 5.1 节已经写了:先 stop-all.sh,再找到 core-site.xml 里 hadoop.tmp.dir 指定的数据路径删除掉,然后重新执行 namenode -format,最后用 start-all.sh 和 stop-all.sh 重启整个集群。注意顺序不能反:一定要先停止所有服务再删除数据,服务运行中删目录可能引发文件锁问题。
注意:格式化不是可以随手反复执行的操作。每次格式化之前,先想清楚 HDFS 里的数据还要不要。这个习惯救了我很多次,直到现在我给集群做元数据恢复时,仍然会先备份 namenode 目录再动手 format。
5.4 现象:格式化时报错 “NameNode is already formatted”
再次执行 hadoop namenode -format 时,系统提示目录已经初始化过,不让你重复格式化。这个提示其实是一种保护机制,防止你误操作清空已有数据。
解决方法是你在确认数据可丢的前提下,删除 namenode 数据目录里的文件之后再重新格式化。或者你也可以在格式化命令前加 -force 参数,但我不建议这么做,宁可删目录再格式化,因为删目录是显式操作,出了偏差还能从回收站或备份里找回来,-force 跳过确认直接覆盖,数据被覆写就真没了。实验环境里删除 data 目录再 format 是通用做法,也是 5.1 节里出现的那套命令。
5.5 现象:启动后进程反复自动退出
有些时候 jps 能看到 Datanode 或 NameNode,但过几秒再执行 jps,进程消失了。这种情况和元数据问题无关,大概率是资源不足或端口被占。伪分布式虽然只有一个节点,但 NameNode、DataNode、SecondaryNameNode 加在一起会占用不少内存,虚拟机如果只分了 2 GB 内存,Hadoop 进程很容易被系统 OOM 杀掉。
先用 free -h 看剩余内存,再用 tail -f /opt/module/hadoop-3.1.3/logs/hadoop-hadoop-namenode-*.log 看有没有 OutOfMemoryError 关键字。内存不足就调大虚拟机内存;端口被占用时用 netstat -anp | grep 9000 查看哪个进程占用了 9000 或 9870 端口,杀掉占用进程再重启 Hadoop。另外,伪分布式环境里启动顺序也有讲究,先 start-dfs.sh 再 start-yarn.sh,关闭时反过来先 stop-yarn.sh 再 stop-all.sh,这套收尾习惯能减少很多莫名其妙的进程残留。
6. 装完怎么验证跑通:WordCount 与 HDFS 上传下载实战
验证 Hadoop 是否真正可用,最好的方式就是跑一个实验自带的 MapReduce 实例。Hadoop 安装包内置了官方样例 JAR,路径在 share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar,里面包含 WordCount、PI 等经典程序。实际操作流程是先在本地创建一个文本文件,上传到 HDFS,然后提交 WordCount 作业:
echo "hello hadoop hadoop world" > /tmp/wordcount.txt bin/hdfs dfs -mkdir -p /user/hadoop/input bin/hdfs dfs -put /tmp/wordcount.txt /user/hadoop/input/ bin/hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar wordcount /user/hadoop/input /user/hadoop/output bin/hdfs dfs -cat /user/hadoop/output/part-r-00000前三行分别是准备输入文件、在 HDFS 上创建 input 目录、把文件上传到 HDFS。第四行的 JAR 包路径是 Hadoop 自带样例,wordcount 是程序名,后面依次是输入目录和输出目录。作业跑完后,cat 查看输出目录下的 part-r-00000,里面应该统计出每个单词的出现次数:hadoop 出现 2 次,hello 和 world 各 1 次。看到这个结果,说明 HDFS 读写、MapReduce 调度、集群心跳全部正常,你的伪分布式环境才算真正跑通。
WordCount 通过后,再把实验第四部分要求的 HDFS 操作完整走一遍作为收尾:在 HDFS 里创建 /user/hadoop/test 目录,把 Linux 本地主目录下的 .bashrc 上传到 test 文件夹,再把这个文件夹从 HDFS 复制回本地 Hadoop 安装目录。这组操作覆盖了 HDFS 的增、查、上传、下载四个最常用动作,以后做其他实验时你用的还是这套命令。
我从那次 DataNode 起不来的事故之后,养成了一个习惯:每次格式化 Hadoop 之前,先打开 core-site.xml 确认 hadoop.tmp.dir 指向哪里,再打开 namenode 数据目录下的 current/version 文件看一眼 clusterId,最后才执行格式化。这个习惯让我的集群再也没出现过 Cluster-Id 不一致的档期问题,也希望这套从虚拟机到命令、从伪分布式安装到故障恢复的流程能帮到你。
本文还有配套的精品资源,点击获取