简介南邮《大数据存储与管理》课程实验一的Redis安装与应用实验报告面向大数据、数据库方向学生及Redis入门学习者。报告完整记录了Ubuntu 16.04环境下Redis单机安装、APT源配置、主从集群搭建的全过程并基于Redis实现了一个简单的文章投票网站后端涵盖数据模型设计、投票功能与排序列表实现。全部内容整理为1个doc文档大小约933KB包含详细命令、配置截图、代码段及运行结果分析便于读者对照实操或作为课程实验参考。资源已被323人学习浏览对于需要完成同类Redis实验或快速上手Redis集群与Python客户端操作的同学具有直接的参考价值。此外报告还总结了连接失败等常见问题的解决方法能帮助规避实验中的典型坑点。1. 这个实验到底在验证什么分布式存储不是玄学如果你正在做「大数据存储与管理」课程的第一个实验大概率会遇到一个困惑明明只是往HDFS里传了个文件为什么比在本地拷文件慢那么多这恰恰是这个实验的价值所在——它逼着你从「会用一条Linux命令」升级到「能说清楚一个文件在分布式文件系统里到底经历了什么」。这个实验的核心对象是HDFS即Hadoop分布式文件系统。它要解决的是单机磁盘装不下、读写跟不上时的存储扩展问题。做完这个实验你应该能亲手搭建一个最小可用的HDFS环境能用命令行和代码完成文件的写入、读取、块信息查看并且能解释清楚数据落盘时发生了什么。它适合两类人刚接触大数据生态、想把底层存储机制搞明白的初学者以及需要在本地快速验证存储逻辑、不想被云服务黑匣子糊弄的开发者。2. 实验环境Hadoop伪分布式的最小可跑配置2.1 为什么实验一一定绕不开HDFS很多人在做实验一之前会问大数据存储为什么不用MySQL、不用Redis偏偏要跟HDFS较劲原因在于这些传统存储解决的是「单机内的存取」而大数据场景的第一道门槛是「数据多到一台机器放不下」。HDFS的设计目标很纯粹把大文件切块分散到多台机器上同时对外暴露一个统一的文件系统视图。在实验一中你不需要真的搭一个几十台机器的集群。常见的做法是使用伪分布式模式也就是在一台机器上同时运行NameNode和DataNode进程。它和真集群的差别只有节点数量核心机制——命名空间管理、块存储、副本复制、数据流管道——全部保留。这意味着你在实验里观察到的块分布、副本策略、读写流程和生产环境里的行为是一致的只是规模缩小了。伪分布式还有一个好处排错门槛低。进程全在本机日志集中在一个目录出了问题用jps和日志就能定位不需要跨节点排查网络。对于第一次接触HDFS的人来说这是成本最低但信息量最完整的实验形态。2.2 单机伪分布式搭建的配置要点以Hadoop 3.x为例搭建伪分布式环境分为三步安装Java、配置SSH免密、修改四个配置文件。Java版本建议选8或11Hadoop 3.x对这两个版本支持最稳定。配置文件位于$HADOOP_HOME/etc/hadoop目录下核心改动如下。core-site.xml中指定NameNode的地址configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property /configurationhdfs-site.xml中设置副本数和NameNode/DataNode的数据目录configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/home/bigdata/hadoop_data/namenode/value /property property namedfs.datanode.data.dir/name value/home/bigdata/hadoop_data/datanode/value /property /configuration这里有两个参数值得细说。dfs.replication默认值是3在真集群里表示每个块存3份伪分布式只有1个DataNode设成1即可设成3会导致DataNode启动时报错或一直处于副本等待状态。dfs.namenode.name.dir和dfs.datanode.data.dir是核心元数据和数据块的物理存储路径建议手动指定到独立目录不要让Hadoop用默认的/tmp否则系统重启后数据被清空你就得重新格式化。配置完成后第一次启动前必须执行格式化命令hdfs namenode -format格式化会生成namespaceID和clusterID这两个ID是NameNode和DataNode互相识别的凭证。格式化只在首次启动前执行一次之后每次重启都不需要这点后面避坑章节还会展开。2.3 启动与健康检查怎么判断NameNode真的起来了启动HDFS进程的命令是start-dfs.sh启动后第一件事不是急着上传文件而是确认进程全部在线。用jps查看Java进程jps正常情况下应该看到NameNode、DataNode、SecondaryNameNode三个进程。如果少了DataNode说明配置或格式化有问题直接进入排查流程而不是继续往下做。进程在线的同时建议打开HDFS的Web界面验证。默认地址是http://localhost:9870在浏览器里能看到NameNode的存储概况、DataNode列表、文件系统健康状态。页面能打开且显示Live Nodes数量为1才算真正起来。这里有个经常被忽略的点Web界面显示的是「存储概览」它不刷新文件内容所以上传文件后不要指望立刻在页面上看到文件列表变动需要刷新或进入Browse目录查看。3. HDFS命令行操作实验一核心实验步骤3.1 目录与文件操作mkdir、put、get、catHDFS的命令行接口是hdfs dfs后面的参数风格跟Linux命令很像但语义上是操作分布式文件系统而不是本地文件系统。实验一最常考察的第一步是创建目录并上传文件# 在HDFS根目录下创建input目录 hdfs dfs -mkdir -p /input # 将本地的test.txt上传到HDFS的/input目录 hdfs dfs -put /home/bigdata/test.txt /input/ # 查看HDFS中的文件列表 hdfs dfs -ls /input # 查看文件内容 hdfs dfs -cat /input/test.txt这里需要注意-put的语义源路径是本地路径目标路径是HDFS路径。反过来从HDFS下载到本地用-get。有些初学者会把顺序搞反写出的命令变成hdfs dfs -put /input/test.txt /home/bigdata/这实际上是尝试把HDFS中的路径当作本地源文件来读取结果必然是FileNotFoundException。-cat命令用来查看文本文件内容适合小文件。如果文件很大直接-cat会把全部内容刷到终端让终端卡死。此时用hdfs dfs -tail /input/test.txt只查看末尾几KB或者用-get下载后分批查看更稳。3.2 块大小与副本数用fsck看存储真相HDFS把文件切分成块block存储这个机制是实验一的核心考点。默认块大小是128MBHadoop 2.x之后也就是说一个200MB的文件会被切成两个块每个块独立存储、独立管理副本。要直观验证这个行为需要用fsck命令hdfs fsck /input/test.txt -files -blocks -locations执行后能看到类似这样的输出文件被拆成几个block每个block的ID、所在DataNode的主机名、副本数量。这正是理解分布式存储的钥匙——文件不是一个整体躺在某台机器的磁盘上而是被切成若干块分散存储由NameNode记录「哪个块在哪个DataNode上」的映射关系。这个命令的输出里有几个信息值得注意。-files显示文件的基本信息-blocks显示块列表-locations显示块所在节点。如果文件小于128MB你会看到它占用了1个block这个block的size是文件的实际大小。修改块大小需要在hdfs-site.xml中设置dfs.blocksize但实验一一般不要求改这个参数知道如何用fsck观察就好。3.3 权限与回收站Trash的后悔药HDFS的权限模型跟Linux类似有owner、group、others三组权限。实验里不同同学共用同一个集群时最典型的问题是别人的文件你删不掉。实际操作中HDFS默认开启了回收站机制删除文件不会立即物理删除而是先移动到/user/用户名/.Trash目录。# 删除HDFS中的文件实际是移入回收站 hdfs dfs -rm /input/test.txt # 从回收站恢复文件 hdfs dfs -mv /user/bigdata/.Trash/Current/input/test.txt /input/test.txt很多人不知道-rm之后文件还能救回来我一般会建议在实验开始前先确认回收站功能是否开启。检查方法是删除一个测试文件后用hdfs dfs -ls /user/用户名/.Trash/Current查看回收站目录是否存在。如果没有这个目录需要在core-site.xml中设置fs.trash.interval参数单位是分钟property namefs.trash.interval/name value1440/value /property设置成1440表示回收站里的文件保留1天。这是实验环境里非常实用的「后悔药」——比直接物理删除安全得多。4. 从命令行到API用Python写一个最小上传程序4.1 API选型走WebHDFS还是走Java API实验做到这里命令行操作已经能覆盖大部分考察点。但如果你想把「存储与管理」这层做实建议用代码操作一次HDFS这会让你对「客户端与NameNode、DataNode之间的通信流程」有具体认识。选型上有两条路Java API是Hadoop原生接口功能最全但maven依赖和Java代码模板比较重Python走WebHDFS的REST接口更轻适合实验场景快速验证。我一般推荐用Python的hdfs库。它封装了WebHDFS协议底层通过HTTP与NameNode通信不需要安装额外的Hadoop客户端。这也更贴近真实场景如今很多离线任务都是通过API操作HDFS而不是在终端敲命令。4.2 Python版本代码连接、上传、读取先用pip安装依赖pip install hdfs然后写一个最小客户端from hdfs import InsecureClient # 连接HDFS指向NameNode的WebHDFS端口 client InsecureClient(http://localhost:9870, userbigdata) # 在HDFS上创建目录exist_okTrue表示目录已存在时不报错 client.makedirs(/api_test, exist_okTrue) # 上传本地文件到HDFS client.upload(/api_test/sample.txt, /home/bigdata/sample.txt, overwriteTrue) # 读取HDFS文件内容 with client.read(/api_test/sample.txt) as reader: content reader.read() print(content.decode(utf-8))这段代码的流程是先创建客户端连接这里只有一个必要参数url指向NameNode的WebHDFS地址。注意Hadoop 3.x中WebHDFS的默认端口是9870跟Web界面端口一致。upload方法的参数依次是HDFS目标路径、本地源路径和是否覆盖同名文件。这里有个关键点InsecureClient这个类名里的Insecure不是指不安全而是表示走HTTP明文协议。如果集群开启了Kerberos认证需要改用HdfsKerberosClient并提供认证配置。实验环境一般没有认证用InsecureClient即可。4.3 参数说明与运行逻辑运行上面的Python脚本前先确认本机能访问NameNode的9870端口。如果用虚拟机或远程服务器注意端口映射或防火墙设置否则会报ConnectionError。脚本运行成功后可以用hdfs dfs -ls /api_test在终端验证文件确实存在。一个容易被忽略的细节是用户参数。InsecureClient里的userbigdata会在创建文件和目录时作为owner写入NameNode的元数据。如果本机用户名和HDFS用户不一致比如本机叫ubuntu但HDFS用户是bigdata文件的所有者会显示为bigdata这在多人共用实验集群时会影响后续他人能否读取。写代码时显式指定用户能减少很多权限方面的干扰。5. 实验一避坑最常见的5个翻车现场5.1 DataNode进程启动后立刻消失现象start-dfs.sh执行完jps显示NameNode和SecondaryNameNode都在唯独没有DataNode。原因最常见的情况是NameNode和DataNode的clusterID不一致。格式化NameNode后NameNode数据目录里有一个current/VERSION文件记录了clusterID而DataNode数据目录如果是旧的比如之前格式化过一次它的clusterID是另外一台「虚拟NameNode」的两边对不上DataNode就会拒绝启动。解决先停掉所有HDFS进程然后删除NameNode和DataNode的数据目录重新创建并重新执行hdfs namenode -format。注意这个操作会清空HDFS中的所有数据所以只适合实验环境不要在生产环境模仿。另一个办法是手动修改DataNode的VERSION文件把clusterID改成NameNode的但实验环境图省事直接清空重来更稳妥。5.2 9870端口打不开Web界面无响应现象jps正常、进程都在但浏览器访问http://localhost:9870一直转圈或连接失败。原因三种情况比较常见。第一种是防火墙拦截了9870端口第二种是Hadoop 2.x用户访问的是50070端口配置和文档用的是3.x的9870端口看错第三种是core-site.xml里fs.defaultFS写成了其它主机名导致NameNode绑定的地址不是本机。解决先检查防火墙systemctl status firewalld或临时执行systemctl stop firewalld排除干扰。再检查core-site.xml的fs.defaultFS确认是hdfs://localhost:9000而不是hdfs://某个主机名:9000后者会导致绑定到主机名解析出的IP上浏览器访问localhost反而找不到。最后确认Hadoop版本3.x用98702.x用50070。5.3 上传大文件巨慢进度条卡住现象向HDFS上传一个几百MB的文件速度只有几MB/s甚至卡在同一进度百分比上不动。原因伪分布式只有1个DataNode副本数如果仍为默认的3NameNode会一直等待另外两个DataNode上报心跳写入流程被阻塞。另一个原因是磁盘空间不足DataNode写入一半发现空间不够反复重试。解决先确认dfs.replication为1。在hdfs-site.xml检查并修改后重启HDFS。如果副本数正常用hdfs dfsadmin -report查看每个DataNode的存储空间确认剩余容量大于文件大小。实验机上这两种原因占比最高。5.4 回收站没有生效rm删掉的文件找不回来现象执行hdfs dfs -rm删除了重要实验文件终端提示删除成功但去.Trash目录里看不到文件。原因fs.trash.interval默认值是0表示回收站功能关闭-rm直接物理删除。很多教程环境默认不开启这个参数实验时才猛然发现没有后悔药。解决在core-site.xml中添加fs.trash.interval为1440分钟保存后执行hdfs dfsadmin -refreshSuperUserGroupsConfiguration或直接重启HDFS服务。重启后删除文件再用hdfs dfs -ls /user/用户名/.Trash/Current验证回收站目录已生成。5.5 权限不足无法写入报AccessControlException现象用API或命令行向/目录写入文件时报错提示Permission denied: userxxx, accessWRITE。原因HDFS根目录/的owner默认是当前执行格式化的用户。如果代码里指定的user和格式化用户不一致其它位置没有写权限。解决两种思路。实验环境图省事可以直接给根目录开宽权限hdfs dfs -chmod -R 777 /。更规范的做法是把当前用户设为超级用户在hdfs-site.xml中配置dfs.permissions.superusergroup。对实验来说前者够用后者更接近生产环境的管理思路。6. 验证方法如何证明你确实把存储这件事做懂了实验做完不等于任务结束要验证你是否真正理解了HDFS的存储机制建议用三个递进式的小测试自检。第一个测试是「块切分验证」生成一个200MB的随机文件上传到HDFS执行hdfs fsck查看块数量。如果块数是2说明你理解块大小与文件体积的关系如果块数是1说明你的块大小配置可能被修改过或者文件实际没传完。这个测试能暴露你对dfs.blocksize参数的理解漏洞。第二个测试是「文件语义验证」用hdfs dfs -setrep -w 1 /input/test.txt把副本数动态调整为1再观察fsck输出。你会看到副本数从期望值变为实际值的过程这能帮你搞清副本数修改是异步生效的不是立刻完成。第三个测试是「跨接口验证」用Python脚本上传一个文件再用命令行读取并校验内容一致性。执行hdfs dfs -cat /api_test/sample.txt | md5sum和md5sum /home/bigdata/sample.txt两个哈希值一致说明API和命令行走的是同一个存储后端文件没有被错误截断或损坏。我自己的习惯是每次做完实验会把关键命令整理成一个脚本放到~/hdfs_lab_notes.sh下次再搭环境直接复用。第一次做这个实验时我就是因为没先看DataNode日志在clusterID不一致的问题上折腾了一晚上后来才学会「进程起不来先看$HADOOP_HOME/logs目录下的.log文件」。这个习惯帮我省了很多时间也希望帮到你。本文还有配套的精品资源点击获取
