1. Day6到底该学什么找准学习路上的关键锚点1.1 前5天走完了什么路很多刚开始接触大数据开发的人最容易犯的一个毛病就是今天翻到一篇讲Spark的文章觉得挺酷明天又看到Flink的实时计算案例又开始纠结要不要转方向。结果学了半个月连数据到底存在哪、怎么取出来都没搞明白。按照一套比较稳的学习节奏前5天应该做的事情大概是这样的Day1到Day2补齐Linux基础。因为大数据生态里的组件几乎全部跑在Linux上你至少要会用命令行操作文件、写简单的Shell脚本、配置环境变量、看懂系统日志。Day3到Day5搞定Java和必要的开发环境。Java是大数据生态的第一语言Hadoop本身是Java写的Hive、HBase这些上层工具也都跑在JVM里。不需要Java水平有多高但类、对象、集合、IO流、多线程这几个基础概念后面写MapReduce和Spark程序时全都会用到。到Day5结束的时候你应该已经具备了这样的基本能力能在Linux上装JDK、能独立写一个简单的Java程序并打包运行、对文件权限和网络端口有基本概念。这些是地基看起来不起眼但后面哪个环节出了问题往往都能回到这里找到原因。1.2 为什么第六天要死磕分布式存储很多人第一次面对HDFSHadoop Distributed File System分布式文件系统的时候心里冒出来的第一个念头是这不就是个文件系统吗跟我电脑上的文件夹有什么区别确实是文件系统但这是“一群服务器拼在一起对外提供服务”的文件系统。它的核心场景是数据量大到一台机器放不下或者单台机器坏了数据就全没了这时候需要把数据分散存放在多台机器上并且让用户感觉还是在操作一个大文件夹。Day6放在这个位置意义就在这HDFS是整个大数据技术栈里几乎一切计算的地基。你后面学的MapReduce、Hive、Spark、Flink底层数据要么直接存在HDFS上要么通过接口把HDFS当作数据源。地基不牢后面盖什么楼都心慌。而且基于云平台的大数据应用开发越来越普遍以后很多人直接用云上的对象存储或者托管Hadoop集群省去了自己搭环境的麻烦。但云平台只是把底层的分布式存储封装成了服务核心的目录结构、数据分块、副本机制、读写原理和HDFS是同一个套路。所以第六天把HDFS的原理和操作吃透后面上云也好、用别的分布式存储也好你都有一通百通的基础。提示这一天不要想着“我会用命令就行”一定要动手把环境搭起来亲手执行上传、下载、查看文件位置、体验一次节点故障后数据还能读出来。只有亲手做过原理才真正长在你身上。2. HDFS核心机制先搞懂原理再动手省下三倍调试时间2.1 从“文件怎么存”说起NameNode和DataNode的分工HDFS采用的是典型的主从架构。集群里有两类角色NameNode主节点负责管理整个文件系统的“目录和索引”。它不存具体数据只记录每个文件被切成了多少个数据块、每个数据块存放在哪些机器上。打个比方它就是图书馆的总目录你要找哪本书先查它。DataNode从节点真正存放数据块的地方。它负责处理客户端发来的读写请求定期向NameNode汇报自己手里有哪些数据块。继续用图书馆的例子它就是书架书实际摆在书架上。这个设计最核心的好处是元数据和数据分离。NameNode不需要承担海量数据的读写压力只需要维护一份轻量的元数据就能管理PB级别的数据。DataNode可以横向扩展机器不够了加几台副本数不够了自动补齐。Day6阶段最常见的困惑是我把一个文件传到HDFS上这个文件到底被切成了什么样默认情况下HDFS会按128MB旧版本是64MB的大小把文件切块每个块独立存储。举个例子一个300MB的文件会被切成3个块前两个块各128MB第三个块44MB。多副本模式下每个块还会复制出多份放到不同机器上。2.2 数据写入流程一次读写背后发生了什么理解了架构再看读写流程就不难了。以写入过程为例大致是这几步客户端向NameNode发起上传请求告诉它“我要创建某个文件”。NameNode检查权限和路径合法性允许创建并告诉客户端应该往哪些DataNode上写。客户端把文件按块切分第一个块先写入第一个DataNode。第一个DataNode写完以后会自动把数据转发给第二个DataNode第二个再转发给第三个形成一条流水线。所有副本都写完了DataNode会向NameNode汇报消息。这个流程的设计逻辑是让数据在DataNode之间“接力”传输而不是由客户端分别往每台机器传一遍。因为客户端通常在集群外部带宽有限如果每写一个副本都要客户端往外传一次性能会成倍下降。接力传输的方式充分利用了集群内部的带宽。读取过程类似客户端拿到文件块的位置信息后会优先从最近的节点读取数据。好的分布式系统设计都有一个共同点尽量让数据计算发生在数据所在的位置减少网络传输开销。这个原则到后面学MapReduce、Spark时还会反复遇到。2.3 副本机制默认3副本背后的权衡逻辑副本机制是HDFS可靠性最直接的保障。默认情况下每份数据存3个副本放置策略大概是第1个副本放在客户端所在的机器上如果客户端不在集群内就随机挑一台负载不高的节点。第2个副本放在与第1个副本不同机架的某台机器上。第3个副本与第2个副本同机架但是不同机器。这样设计是为了同时兼顾“容灾”和“性能”。如果整个机架断电了集群还有其他机架上的副本可供读取如果某个副本参与计算同机架内的网络传输速度又比跨机架快。有人会问那我是不是可以把副本数设置成1省点磁盘可以。在测试环境、伪分布式环境下我经常就把副本数改成1因为就一台机器你让它把3份副本放到哪去但生产环境请老老实实保留至少3副本宁可多花点磁盘也不要赌运气。注意副本数不是写死的可以在配置里改也可以在命令行里动态修改。但副本数越多磁盘占用越高写入时数据同步的开销也越大它是个典型的“用空间和性能换安全”的权衡。学习阶段了解这些后面设计存储方案时你才能跟别人讲清楚为什么这么定。3. 环境搭建实操从零开始跑起一个能用的HDFS3.1 环境规划和版本选型分布式存储听起来很高大上但学习阶段完全没必要搭一个5台甚至10台机器的集群一台普通的电脑就够了。我建议用伪分布式模式一台机器上同时运行NameNode和DataNode进程完整的分布式架构一个不缺只是所有角色都挤在同一台机器上。系统方面优先选CentOS 7或者Ubuntu Server这类Linux发行版也可以用虚拟机也可以用云服务器。如果本机就是Windows/Mac更省事的方案是装一个带Hadoop的Docker镜像。但我的建议是虚拟机或者云服务器老老实实走一遍原生安装流程这对理解配置项和目录结构更有帮助。版本选择上Apache Hadoop 3.x是目前主流我用的3.3.x系列。Java版本要注意Hadoop 3.3需要JDK 8以上配JDK 8最稳配JDK 11也可以但没必要给自己添麻烦。下载时可以去Apache官网或者国内镜像站压缩包大概几百MB解压即用不需要编译。3.2 核心配置三个文件改完就能启动安装好JDK和Hadoop、配置好环境变量之后真正要改的配置主要是三个文件它们都在Hadoop安装目录的etc/hadoop下第一个是hadoop-env.sh里面要指定JAVA_HOME让Hadoop能找到Java环境。这一步不做启动脚本会直接报错。第二个是core-site.xml核心配置主要设置默认文件系统和临时目录configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/opt/hadoop/tmp/value /property /configurationfs.defaultFS指定了HDFS的访问入口后面所有HDFS路径都会基于这个地址解析。hadoop.tmp.dir是Hadoop存放临时文件和数据的地方默认值在/tmp下系统一清理就出问题所以一定要自己指定一个持久化目录。第三个是hdfs-site.xml核心是设置副本数configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name valuefile:///opt/hadoop/namenode/value /property property namedfs.datanode.data.dir/name valuefile:///opt/hadoop/datanode/value /property /configuration伪分布式模式下副本数必须设为1因为只有一台DataNode3副本永远无法满足集群会一直警告副本缺失。NameNode的元数据目录和DataNode的数据存储目录也建议显式指定避免默认路径不稳定。3.3 启动、验证和格式化那点事配置写好后第一次启动HDFS前需要先执行格式化命令hdfs namenode -format格式化的作用是为NameNode创建初始的元数据存储结构。很多人会在启动报错时傻眼明明配置都对为什么起不来十有八九是重复格式化或者格式化后改了目录地址导致NameNode和DataNode的集群ID对不上。注意hdfs namenode -format只在第一次使用或需要重置集群时执行别养成每次启动前都格式化一下的习惯那会导致元数据全部丢失。格式化完成后用一条命令启动所有进程start-dfs.sh启动后输入jps查看Java进程正常情况下能看到NameNode、DataNode、SecondaryNameNode三个进程。看到这三个进程说明HDFS已经跑起来了。接着用浏览器打开http://localhost:9870可以看到一个Web界面里面有文件系统浏览、集群健康状态、DataNode列表等信息。这一步一定要做后面你排查问题时这个界面能帮大忙。4. HDFS Shell实操用命令把数据处理流程串起来4.1 高频命令过关清单HDFS的Shell命令跟Linux命令风格非常像有Linux基础的话几乎不需要刻意背。下面这些是我认为学习阶段必须过关的高频命令# 查看根目录下的文件和目录 hdfs dfs -ls / # 创建目录支持-p递归创建 hdfs dfs -mkdir -p /data/log # 把本地文件上传到HDFS hdfs dfs -put /opt/local_data.txt /data/log/ # 从HDFS下载文件到本地 hdfs dfs -get /data/log/data.txt /opt/ # 查看文件内容大文件不要用容易刷屏 hdfs dfs -cat /data/log/data.txt # 查看文件末尾部分内容 hdfs dfs -tail /data/log/data.txt # 删除文件或目录 hdfs dfs -rm -r /data/log # 查看文件块信息和副本位置 hdfs fsck /data/log/data.txt -files -blocks -locations这里特别想提一下fsck命令很多学HDFS的人都忽略它但我认为它是最能体现“分布式存储”特性的命令。执行它会告诉你每个文件被切成了几个块、每个块在哪台机器上、副本是否齐全。想象一下你亲手写个文件传上去然后用这个命令看到数据块被分布在不同节点上那种对整个系统的理解会瞬间清晰起来。4.2 一个完整的日志入库实操光罗列命令没意思我带你走一遍实际工作中很常见的“日志数据入库”流程。假设本地有一个应用日志文件app.log大小约300MB需要上传到HDFS上统一归档。第一步创建数据目录。生产环境里目录一般按业务和时间分层比如/data/app_log/2025/06/这样做的好处是后面用Hive建表做分区查询时特别方便。hdfs dfs -mkdir -p /data/app_log/2025/06第二步上传文件hdfs dfs -put /opt/app.log /data/app_log/2025/06/如果文件比较大可以加上-D dfs.replication2临时指定副本数但这是生产环境才需要考虑的调整学习阶段保持默认就行。第三步检查上传结果# 查看文件大小是否与本地一致 hdfs dfs -du -h /data/app_log/2025/06/ # 查看数据块分布 hdfs fsck /data/app_log/2025/06/app.log -files -blocks -locations这个流程练完你至少应该弄清三件事文件在HDFS里的真实存储方式、目录结构对后续数据处理的影响、以及怎么验证数据安全地落到了集群里。不要把这个当任务把它当一次“系统体检”你会发现命令行没什么神秘的。4.3 运维视角巡检时我必看的几个命令Day6虽然不要求你立刻去管理集群但有几个运维命令我强烈建议提前接触。以后你一定会感谢自己当初养成了看它们的好习惯。# 查看HDFS整体健康状态是否处于安全模式、块数量是否健康 hdfs dfsadmin -report # 查看NameNode的Web UI保存的日志排查启动和读写报错 tail -100 /opt/hadoop/logs/hadoop-hadoop-namenode.log # 查看DataNode日志 tail -100 /opt/hadoop/logs/hadoop-hadoop-datanode.log我见过太多新手集群起不来只知道在搜索引擎里复制粘贴报错其实90%的问题都能在日志里直接找到答案。Hadoop的日志写得非常直白比如“Cannot connect to NameNode”就是端口或网络不通“Insufficient permissions就是权限不够看到英文别慌大致能看懂就该知道往哪个方向查。5. Java API开发用代码操作HDFS的正确姿势5.1 开发环境准备光会用Shell命令在真实项目里是不够的。因为日志数据往往是程序产出的不可能每次都靠人去敲put命令。你得能写程序在代码里自动完成上传、下载、读取、删除这些操作。开发环境建议用IDEA Maven管理依赖。新建一个Maven项目然后引入Hadoop客户端依赖dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-client/artifactId version3.3.6/version /dependency同时要确保本机能解析hdfs://localhost:9000这个地址如果是本地Linux环境通常直接访问localhost如果Hadoop跑在虚拟机上而代码在Windows上写需要额外配置Windows下的Hadoop环境支持。这个坑不少人都踩过Windows下跑Hadoop客户端缺少winutils.exe时会报错解决办法是在Windows本地放一份Hadoop的bin目录并配置环境变量。5.2 核心代码上传和下载配置文件和依赖准备好后核心代码其实不长。首先创建FileSystem对象它是操作HDFS的入口import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.FileSystem; import org.apache.hadoop.fs.Path; import java.io.IOException; import java.net.URI; public class HdfsDemo { public static void main(String[] args) throws IOException { Configuration conf new Configuration(); // 指定HDFS的地址 conf.set(fs.defaultFS, hdfs://localhost:9000); // 获取FileSystem实例 FileSystem fs FileSystem.get(URI.create(hdfs://localhost:9000), conf, hadoop); // 路径对象 Path src new Path(D:/data/app.log); Path dst new Path(/data/app_log/2025/06/app.log); // 上传文件 fs.copyFromLocalFile(src, dst); System.out.println(上传完成); // 下载文件 Path local new Path(D:/data/download.log); fs.copyToLocalFile(dst, local); System.out.println(下载完成); fs.close(); } }这段代码的关键点在于FileSystem是线程安全的多个线程可以共享一个实例不必每次都新建但用完一定要关闭否则文件句柄和网络连接会一直泄漏。第三个参数hadoop用户名也要特别注意因为HDFS有权限控制如果当前系统用户名不在HDFS的超级用户列表里操作可能被拒绝。5.3 再深入一步目录遍历与文件状态获取学会上传下载后另一个高频需求是遍历目录批量读取文件信息。比如说你每天有一批日志文件传上来程序需要自动识别并处理新文件。这时候可以通过递归遍历目录拿到每个文件的元信息import org.apache.hadoop.fs.FileStatus; import org.apache.hadoop.fs.LocatedFileStatus; import org.apache.hadoop.fs.RemoteIterator; // 单层目录遍历 FileStatus[] statuses fs.listStatus(new Path(/data/app_log)); for (FileStatus status : statuses) { System.out.println(路径: status.getPath()); System.out.println(大小: status.getLen()); System.out.println(是否为目录: status.isDirectory()); } // 递归遍历 RemoteIteratorLocatedFileStatus iterator fs.listFiles(new Path(/data/app_log), true); while (iterator.hasNext()) { LocatedFileStatus status iterator.next(); System.out.println(文件: status.getPath() , 块大小: status.getBlockSize()); }看完这段代码你应该能理解一个关键点Java API和Shell命令本质上在做同一件事只是一个是人敲命令一个是程序自动执行。真实的大数据平台前台上点一个“上传文件”按钮后面就是这些API在干活。6. 从本地到云端基于云平台的大数据开发应该怎么学6.1 传统自建和云上托管到底差在哪现在的招聘需求和行业发展方向都越来越往“基于云平台的大数据应用开发”倾斜。很多公司招聘大数据工程师不再问你会不会手动搭建Hadoop集群而是问你有没有用过云上的EMR数据湖、对象存储、托管型数仓。所以Day6阶段很有必要把视角拉高一点看看云平台到底改变了什么。传统的方式是自己买服务器、自己搭集群、自己运维。这个过程能让你学到非常多的底层细节但代价也很明显硬件成本高、运维人力重、扩缩容麻烦。比如说公司流量涨了数据量翻倍你得提前买机器、加节点流程至少要几天。云平台的做法是把它封装成服务你只要在控制台上点几下或者在API里调一个方法就能创建出一个带NameNode和DataNode的集群。底层仍然是HDFS那套分布式存储架构但对外提供的是REST API、SDK这些更易于集成的接口。6.2 对象存储与HDFS存储计算分离的新思路基于云平台做大数据有绕不开的东西对象存储比如阿里云的OSS、腾讯云的COS、AWS的S3。对象存储和HDFS有什么异同两者都是分布式存储但设计思路有差异。HDFS的设计偏重大文件、流式读取它默认文件是切块的、顺序访问性能更好。对象存储则是“键值对”式的存储每个对象有一个唯一标识底层实现更注重高可用和跨地域冗余访问方式也变成了HTTP接口。云上的大数据架构越来越流行“存储计算分离”的模式。也就是说数据存在对象存储里计算用弹性伸缩的云上集群按需拉起用完再释放。这就意味着你今天学HDFS时养成的“存储和计算部署在一起”的思维需要拓展一下云上的存储和计算是可以各自独立伸缩的。但底层的原理相通数据分块存储的思想、副本或冗余机制保数据的思路、元数据管理的方式几乎都是从HDFS这套架构演化而来的。所以你完全不用焦虑本地把HDFS搞懂了云上的EMR、对象存储、托管数仓对你来说只是换了一层皮核心还是那套分布式存储和分布式计算的功夫。6.3 给学习者的建议本地打基础云端找视野我的建议是学习阶段不要一上来就花钱开一堆云服务先用本地的伪分布式把原理打通该踩的坑都踩一遍。然后在掌握本地操作之后找一个云厂商开通一个最基础的EMR集群或者托管Hadoop服务亲自体验一下在网页上创建集群、在页面上查看节点状态、用平台自带的数据开发IDE跑一个任务。这样做的意义有两个第一你会见识到真实的工业级大数据平台是什么样子各种监控、告警、资源调度可视化比本地自己搭的要成熟太多第二你会在简历和面试里有一个核心竞争力——既懂底层原理又懂云上实践。这两者结合起来比单会一项的人要有说服力得多。7. 常见问题与排查技巧实录7.1 端口不通、进程起不来Day6最常见的报错就是进程启动失败。如果你执行start-dfs.sh后jps看不到NameNode进程可以从这几个方向排查先看日志。日志路径在Hadoop安装目录的logs下我上面提到过。启动失败的原因99%都能在hadoop-hadoop-namenode.log里找到一句明确的报错。检查端口占用。NameNode默认用9000端口如果被别的进程占用了启动会直接失败。用netstat -tlnp | grep 9000查看。检查防火墙。云服务器尤其要注意安全组规则里要放通9000、9870端口否则浏览器访问不了Web界面。7.2 卡在安全模式HDFS启动后会自动进入安全模式。安全模式下文件系统只读不允许写入和修改。这个机制是为了在NameNode启动时等待DataNode汇报足够的块信息直到确认数据完整后才退出。如果你执行上传文件时报错Name node is in safe mode先别慌。等一会儿是正常的但如果长时间卡着就要检查了# 查看当前安全模式状态 hdfs dfsadmin -safemode get # 手动退出安全模式仅在确保集群健康时使用 hdfs dfsadmin -safemode leave如果你在伪分布式里把副本数设置成3安全模式也会迟迟不退出因为DataNode永远凑不够副本集群会一直觉得“数据不健康”。这也是我反复强调伪分布式要把副本数改成1的原因。7.3 磁盘与副本异常还有一种很典型的坑跑着跑着DataNode进程挂了或者本地磁盘满了。检查方法很简单# 查看集群状态看DataNode是否是活的 hdfs dfsadmin -report # 查看磁盘使用情况 df -h如果DataNode显示为“Dead”大概率是磁盘空间不足或者网络不通。如果副本数不健康会有Under-replicated block提示这时候HDFS会自动从其他节点复制数据来补齐副本前提是还有别的节点有这份数据。所以平时没事多看看dfsadmin -report的输出数据副本指数、节点存活状态都一目了然。7.4 操作HDFS时的几个好习惯最后分享几个我自己用下来觉得特别值得养成的操作习惯。这些不是教科书上写的都是实操踩坑换来的。第一上传大文件时不要开着终端干等可以在命令后面加让它后台运行或者用nohup结合日志输出做记录。否则某个会话一断整个上传任务就被中断了。第二删除目录前养成先看再删的习惯。用-ls确认路径没写错再看一眼文件内容确认没问题再删。生产环境删除数据是不可逆的操作HDFS没有回收站删了就真的没了。第三顺手用-du -h关注磁盘空间。HDFS的数据是分散在多台机器上的单看某台机器的df -h不一定能看到全貌一定要用HDFS自己的命令来查看整个集群的存储使用量。第四学会看Web UI。NameNode的9870端口页面里DataNode列表、集群存储容量、块数、健康状态都有比我用命令还直观。没事翻翻它对集群的整体状态会有很直观的感受。Day6学到这里你已经不再是那个只会写Java程序的“单机玩家”了。当你亲手把一个文件传到分布式文件系统上又亲眼看到它在不同节点上的副本分布再回头看那些云计算平台上的大数据产品就会觉得它们没那么神秘。我个人的体会是分布式存储是整个大数据开发的“定盘星”哪天你觉得Spark、Hive学得晕头转向随时可以回到HDFS的底层原理来重新锚定自己。接下来你要做的就是在Day6的基础上把数据查询和计算分析的工具一个个加进来这条路会越走越宽的。