1. 从单机硬盘到跨机房集群HDFS到底在解决什么问题很多人第一次接触HDFS脑子里冒出来的第一个疑问就是我本地硬盘好好的文件系统用NTFS或者ext4也没出过什么大问题为什么非要搞一个分布式文件系统出来这个问题如果不先想明白后面学NameNode、DataNode、副本机制、机架感知这些概念的时候就很容易变成死记硬背考完就忘。我当初复习这一章的时候也走过弯路一开始就是把HDFS当成一个“网络硬盘”来理解觉得无非就是把文件存到别的机器上。后来真正动手搭了一个小集群跑了一次WordCount又故意把其中一台DataNode的进程杀掉看着文件依然能完整读出来才真正体会到HDFS的设计出发点根本不是为了“把文件放到远端”而是为了解决单机存储容量上限、硬件故障常态化、大规模数据顺序读写这三个核心矛盾。1.1 单机文件系统撞上的三堵墙第一堵墙是容量墙。一块商用硬盘的容量是有物理极限的就算你堆磁盘阵列单台机器的扩展槽位和控制器带宽也是有限的。当数据量从GB级别涨到TB甚至PB级别单机纵向扩展的成本会急剧上升而且存在明显的天花板。第二堵墙是故障墙。这里有一个反直觉的结论在大规模集群里硬件故障不是“异常”而是“常态”。你有一台机器可能一年都不坏但你有一千台机器几乎每天都会有磁盘损坏、内存故障、网卡掉线的情况发生。所以分布式文件系统的设计哲学不是“防止故障”而是“假设故障一定会发生并且让系统在故障发生时依然可用”。第三堵墙是吞吐墙。注意这里说的是吞吐量不是延迟。HDFS的设计目标不是让你像访问本地文件那样毫秒级响应而是让大量数据能够以流式的方式被顺序读取和写入。这一点非常关键它直接决定了HDFS适合做什么、不适合做什么。提示考试里经常考的一道辨析题就是“HDFS适合存储海量小文件吗”答案是不适合。原因就和这三堵墙直接相关后面我会专门展开讲。1.2 HDFS的核心设计取舍理解了上面三个矛盾HDFS的一系列设计选择就变得顺理成章了。它做了几个非常明确的取舍一次写入、多次读取文件一旦写入完成就很少再修改。这个假设让HDFS可以简化一致性模型不需要处理复杂的随机写并发控制。移动计算而非移动数据与其把TB级的数据通过网络搬到计算节点不如把计算程序分发到数据所在的节点上执行。这是Hadoop整个生态的核心理念。用副本换可靠性通过多副本冗余来容忍节点故障而不是依赖昂贵的硬件。面向大文件优化默认块大小从早期的64MB演进到现在的128MB甚至256MB就是为了减少NameNode的元数据压力和寻址开销。这些取舍不是拍脑袋决定的每一个背后都有明确的工程考量。复习的时候如果能把这些“为什么”串起来比单纯背概念要牢固得多。2. 拆开HDFS的骨架NameNode、DataNode与Client的分工HDFS采用的是经典的主从架构这个架构里三个角色各司其职缺一不可。很多人复习的时候能把三个角色的定义背下来但一旦问到“NameNode挂了会怎样”“DataNode挂了会怎样”“Client读文件时到底跟谁打交道”就容易卡壳。根本原因是没有把三者的交互流程在脑子里跑通。2.1 NameNode集群的“目录大脑”NameNode是整个HDFS集群的大脑它负责管理文件系统的命名空间和元数据。所谓命名空间就是目录树结构比如/user/data/input/file.txt这样一条路径所谓元数据主要包括文件的属性权限、所有者、修改时间、文件被切分成了哪些块、每个块存储在哪些DataNode上。这里有一个特别容易混淆的点NameNode并不存储实际的文件数据它只存元数据。真正的数据块是存在DataNode上的。你可以把NameNode想象成一个图书馆的索引卡片柜它告诉你某本书在哪个书架上但书本身不在卡片柜里。NameNode的元数据在内存中维护同时通过两种机制持久化到磁盘FsImage镜像文件是元数据在某个时间点的完整快照。EditLog编辑日志记录自上次快照以来所有的元数据变更操作。如果只有FsImage那么每次重启都要重新加载全量元数据而且中间的操作会丢失如果只有EditLog那么日志会无限增长重启时回放耗时过长。所以HDFS引入了SecondaryNameNode注意它不是NameNode的备份这个误解非常普遍来定期合并FsImage和EditLog生成新的FsImage从而控制EditLog的大小。注意SecondaryNameNode不是热备节点。NameNode挂掉之后SecondaryNameNode不能直接顶替它对外提供服务。这个点在选择题和判断题里出现的频率极高。2.2 DataNode真正扛数据的“苦力”DataNode是实际存储数据块的节点。每个DataNode会定期向NameNode发送心跳默认3秒一次告诉NameNode“我还活着”同时通过块报告默认6小时一次汇报自己持有哪些数据块。DataNode的工作逻辑其实很朴素它把数据块存到本地文件系统上每个块对应一个数据文件和一个元数据文件记录块的校验和等信息。当Client要读数据时NameNode告诉它块在哪些DataNode上Client直接去DataNode读取数据流不经过NameNode。这个设计非常巧妙NameNode只负责“指路”不负责“搬数据”从而避免了NameNode成为整个集群的带宽瓶颈。这也是为什么HDFS能支撑起成百上千个节点的大集群。2.3 Client串起整个流程的“调度者”Client是用户和HDFS交互的入口。当你执行hdfs dfs -put或者用Java API写文件时Client做的事情远比想象中复杂。它需要先跟NameNode通信获取元数据信息然后直接跟DataNode建立连接传输数据还要处理副本的流水线复制。我整理了一张表把三个角色的核心职责和故障影响对比清楚复习的时候看这张表比翻书快角色核心职责存储内容故障后的影响NameNode管理命名空间和元数据FsImage、EditLog整个集群不可用单点故障DataNode存储实际数据块数据块文件、校验文件该节点上的数据暂时不可读副本可恢复Client发起读写请求、协调数据传输无单个客户端操作失败不影响集群2.4 一次完整的写文件流程光看角色定义还不够真正理解HDFS要把写文件的流程走一遍。假设Client要写入一个200MB的文件默认块大小128MBClient向NameNode发起创建文件的请求NameNode检查权限和路径是否存在然后在命名空间中创建文件条目。Client开始写数据文件被切分成两个块128MB和72MB。对于第一个块Client向NameNode请求分配DataNode。NameNode根据机架感知策略返回一组DataNode默认3副本。Client向第一个DataNode建立连接第一个DataNode再向第二个建立连接第二个向第三个建立连接形成一条流水线。数据以Packet为单位默认64KB沿着流水线传输每个DataNode收到后先存本地再转发给下一个。三个副本都写完后ACK沿流水线反向传回Client。第一个块写完后重复步骤3-6写第二个块。所有块写完后Client通知NameNode关闭文件写入完成。这个流程里有两个细节值得注意一是流水线复制数据不是Client分别发给三个DataNode而是串行转发这样能充分利用每个节点的带宽二是ACK确认机制保证数据真正落盘后才算写入成功。3. 块、副本与机架感知HDFS可靠性的三根支柱如果让我从第三章里挑出三个最核心的概念我会选数据块、副本机制和机架感知。这三个概念是HDFS可靠性和性能的基石也是考试的重灾区。很多同学能把定义背出来但一问到“为什么默认副本数是3而不是2或者5”“机架感知到底怎么影响性能”就答不上来了。3.1 数据块不只是“切一刀”那么简单HDFS的块Block概念和传统文件系统的块有本质区别。传统文件系统的块是磁盘读写的最小单位通常只有几KB而HDFS的块是一个逻辑概念默认大小128MB它是数据切分和存储的基本单位。为什么块要设这么大这里有一个计算过程值得搞清楚。假设块大小是128MB一个1TB的文件会被切成大约8192个块。如果块大小只有4KB同样的文件会被切成2.6亿多个块NameNode需要维护的元数据条目会爆炸式增长内存根本扛不住。所以大块的核心目的是降低NameNode的元数据压力。但块也不是越大越好。块太大会导致MapReduce任务的数量减少并行度下降而且如果某个块正在被读取时节点故障需要重传的数据量也更大。所以128MB是一个经过权衡的经验值实际生产中会根据集群规模和数据特征调整。提示HDFS的块和MapReduce的切片Split是两个不同的概念虽然它们经常被放在一起讨论。块是存储单位切片是计算单位一个切片可能对应一个或多个块。3.2 副本机制用冗余换可靠HDFS默认每个块存3份副本。这个“3”不是随便定的它背后有一套权衡逻辑副本数为1没有冗余任何节点故障都会导致数据丢失不可接受。副本数为2能容忍1个节点故障但如果在副本复制期间又坏了一个节点仍然有风险。而且2副本在读写性能上的提升有限。副本数为3能容忍2个节点同时故障可靠性显著提升。同时3副本可以支持更多的并发读提升读吞吐。副本数大于3可靠性提升的边际效益递减但存储成本线性增长。对于绝大多数场景3副本是性价比最高的选择。副本的放置策略是HDFS可靠性的关键。默认策略是第1个副本放在Client所在的节点如果Client在集群内。第2个副本放在与第1个不同机架的某个节点上。第3个副本放在与第2个相同机架、但不同节点的位置上。这个策略同时兼顾了可靠性和带宽跨机架放置保证了即使整个机架断电数据依然有副本存活同机架内的副本则可以利用机架内的高带宽进行数据读取。3.3 机架感知看不见的性能之手机架感知Rack Awareness是HDFS里最容易被忽视、但在生产环境中极其重要的机制。在默认情况下HDFS并不知道网络拓扑结构它假设所有节点都在同一个机架内。但在真实的数据中心里节点分布在多个机架跨机架的通信要经过交换机带宽和延迟都远不如机架内。NameNode通过一个可配置的脚本或类来获取每个DataNode的机架信息。有了机架信息之后HDFS在副本放置、数据读取、任务调度时都会做出更优的决策。举个例子当Client读取一个块时如果Client本身就在某个DataNode上它会优先读取本地副本短路读速度最快如果没有本地副本它会优先读取同机架的副本最后才考虑跨机架读取。这个优先级顺序直接决定了读性能。我踩过的一个坑是在测试环境搭集群时所有节点都配在同一个机架下机架感知形同虚设。后来把节点分散到两个机架重新跑读写测试发现跨机架读取的延迟明显上升这才真正理解了机架感知的价值。副本序号放置位置设计意图第1副本Client所在节点就近写入减少网络传输第2副本不同机架的节点容忍机架级故障第3副本与第2副本同机架的不同节点平衡可靠性与机架内带宽4. 读写流程全链路拆解从API调用到磁盘落盘复习HDFS如果只停留在概念层面考试遇到流程题就容易丢分。这一节我把读文件和写文件的完整链路拆开讲尽量把每一步“为什么这么做”说清楚。理解了流程很多概念题也就迎刃而解了。4.1 读文件Client如何找到并拉取数据读文件的流程相对简单但有几个关键点容易出错。假设Client要读取/user/data/bigfile.txtClient调用FileSystem的open方法向NameNode发起请求获取文件的元数据。NameNode返回文件的所有块信息以及每个块所在的DataNode列表按网络距离排序。Client拿到这些信息后会创建一个FSDataInputStream然后开始逐个读取块。对于每个块Client选择距离最近的DataNode建立连接调用read方法读取数据。数据以流的方式返回给ClientClient边读边处理。如果某个DataNode在读取过程中故障Client会自动切换到下一个持有该块副本的DataNode对用户透明。所有块读完后Client关闭输入流。这里有一个细节Client并不是一次性把所有块的信息都拉取下来而是按需向NameNode请求。这样可以避免元数据信息过大也支持了流式读取。注意读文件时如果遇到DataNode故障Client会向NameNode报告这个坏块NameNode会安排从其他副本重新复制一份保证副本数恢复到设定值。4.2 写文件流水线复制与ACK确认写文件的流程比读文件复杂得多核心在于流水线复制和ACK确认。我在2.4节已经概述了流程这里再深入几个关键机制。Packet传输Client不是一次性把整个块发给DataNode而是把数据切分成一个个Packet默认64KB逐个发送。每个Packet包含数据部分和校验和。这样做的好处是即使某个Packet传输失败也只需要重传这一个Packet而不是整个块。流水线建立Client向第一个DataNode发送写请求第一个DataNode收到后向第二个发送第二个向第三个发送。每个DataNode在收到请求后会向上游返回一个ACK表示“我准备好了”。当Client收到第一个DataNode的ACK时说明整条流水线已经建立完成。ACK确认数据Packet沿着流水线传输每个DataNode收到后先写入本地然后把Packet转发给下游。当最后一个DataNode写完并返回ACK后ACK会沿着流水线反向传回最终到达Client。只有Client收到ACK才认为这个Packet写入成功。故障处理如果流水线中某个DataNode故障Client会收到ACK超时然后采取以下措施关闭当前流水线将故障节点从流水线中移除用剩余的DataNode重新建立流水线继续写入。同时向NameNode报告故障节点NameNode会安排副本复制。这个机制保证了即使写入过程中有节点故障写入操作依然能完成只是副本数可能暂时不足后续会自动补齐。4.3 副本复制数据均衡的幕后工作副本复制是HDFS后台自动进行的工作主要发生在两种场景一是某个DataNode故障导致副本数不足二是集群中新增了DataNode需要把部分数据迁移过去以均衡负载。副本复制的触发条件是NameNode发现某个块的副本数小于设定值就会将该块加入复制队列选择一个合适的源DataNode和目标DataNode启动复制。复制过程是直接DataNode到DataNode的传输不经过Client。这里有一个经验副本复制会占用网络带宽如果集群负载很高复制可能会影响正常读写。所以生产环境中通常会配置复制带宽上限避免复制任务把带宽吃满。5. 安全模式与高可用NameNode的软肋与补强NameNode是HDFS的单点一旦它挂了整个集群就瘫痪了。这个问题的严重性不言而喻所以HDFS在演进过程中引入了安全模式和高可用HA架构来缓解。这一节的内容在考试中经常以简答题的形式出现值得重点复习。5.1 安全模式集群启动时的自我保护安全模式Safe Mode是NameNode在启动时进入的一种特殊状态。在这个状态下HDFS只接受读请求不接受写请求包括创建、删除、修改文件。为什么要有安全模式因为NameNode启动时需要从FsImage和EditLog中恢复元数据然后等待各个DataNode上报自己持有的块信息。只有收集到足够多的块报告NameNode才能确认哪些块的副本是足够的哪些块需要复制。在确认之前如果允许写操作可能会导致数据不一致。退出安全模式的条件是达到最小副本条件的块比例超过阈值默认99.9%。也就是说当99.9%的块都满足了最小副本数要求NameNode才会自动退出安全模式。提示可以用hdfs dfsadmin -safemode get查看安全模式状态用hdfs dfsadmin -safemode leave手动退出。但手动退出要谨慎如果块副本不足就强行退出可能导致数据丢失。5.2 HA架构让NameNode不再孤单HDFS HAHigh Availability架构的核心是引入两个NameNode一个处于Active状态对外提供服务另一个处于Standby状态实时同步Active的元数据。当Active故障时Standby可以快速切换为Active实现故障转移。HA架构的关键组件包括Active NameNode处理所有客户端请求写入EditLog。Standby NameNode实时同步EditLog保持元数据与Active一致随时准备接管。JournalNode集群用于在Active和Standby之间共享EditLog。Active写入EditLog到JournalNodeStandby从JournalNode读取并应用从而保持同步。通常部署3个JournalNode容忍1个故障。ZKFCZooKeeper Failover Controller监控NameNode的健康状态在故障时触发自动切换。HA架构解决了NameNode的单点故障问题但并没有解决元数据规模的问题。如果元数据太大单个NameNode的内存依然会成为瓶颈。这就是HDFS Federation要解决的问题不过那属于更高级的内容期末复习阶段了解即可。架构模式NameNode数量故障切换适用场景单NameNode1不支持需手动恢复测试环境、小规模集群HA架构2ActiveStandby自动切换生产环境、大规模集群Federation多个独立NameNode各自独立超大规模、元数据压力大6. 期末复习的实战策略从背概念到真理解复习到这一步概念和流程应该都过了一遍。但期末考试的题目往往不会直接问你“什么是NameNode”而是会拐几个弯比如“当DataNode故障时NameNode会做什么”“为什么HDFS不适合小文件”“安全模式下能否删除文件”。这些题目考的是对机制的理解而不是记忆。6.1 高频考点与易错点梳理我把自己复习时整理的高频考点和易错点列出来供参考高频考点HDFS的架构组成和各自职责数据块的概念、默认大小、与MapReduce切片的关系副本机制、默认副本数、副本放置策略机架感知的原理和作用读写文件的完整流程安全模式的作用和退出条件SecondaryNameNode的作用不是备份HA架构的组成和故障切换流程易错点把SecondaryNameNode当成NameNode的备份认为HDFS适合存储大量小文件混淆数据块和MapReduce切片认为NameNode存储实际数据认为安全模式下完全不能访问HDFS其实可以读认为副本数越多越好6.2 用“故障推演法”检验理解程度我复习时用了一个方法觉得特别有效叫故障推演法。就是假设集群中某个组件出故障然后推演HDFS会怎么反应。比如如果某个DataNode挂了会发生什么——心跳超时NameNode标记该节点为dead将其上的块标记为副本不足启动副本复制。如果NameNode挂了会发生什么——单NameNode架构下整个集群不可用HA架构下Standby接管。如果某个块的所有副本都丢了会发生什么——NameNode检测到副本数为0但无法恢复该块永久丢失读取时会报错。如果Client写入过程中某个DataNode故障会发生什么——流水线重建故障节点被移除写入继续。这种推演能帮你把零散的知识点串成一张网考试时遇到变形题也能应对。6.3 动手实验让知识真正落地如果条件允许强烈建议动手搭一个伪分布式或者完全分布式的HDFS环境。哪怕只是在一台机器上跑伪分布式也能帮你理解很多概念。比如用hdfs dfs -put上传一个文件然后用hdfs fsck /path -files -blocks -locations查看块信息和副本位置。故意杀掉一个DataNode进程观察NameNode的Web UI上节点状态的变化。用hdfs dfsadmin -report查看集群状态。尝试进入和退出安全模式观察读写操作的变化。这些实验不需要复杂的配置但能让你对HDFS的行为有直观的感受。我当初就是通过杀掉DataNode进程看到副本数从3变成2再看到NameNode自动复制恢复到3才真正理解了副本机制。提示伪分布式环境下副本数通常设置为1因为只有一个DataNode。如果要观察副本复制需要至少3个DataNode。6.4 答题技巧把“为什么”写进答案里最后分享一个答题技巧。期末考试的简答题如果只写“是什么”通常只能拿一半分。阅卷老师更想看到的是“为什么”。比如问“HDFS为什么不适合小文件”不要只写“因为NameNode内存有限”而要展开每个文件、每个块都会在NameNode内存中占用元数据条目小文件数量多会导致元数据爆炸同时小文件的读取需要频繁与NameNode交互违背了HDFS面向大文件顺序读的设计初衷。再比如问“副本放置策略”不要只写“一个在本机架一个在别的机架”而要解释这样设计是为了兼顾可靠性和带宽跨机架保证机架级故障容忍同机架利用高带宽。把“为什么”写清楚答案的深度就上来了分数自然也不会低。复习HDFS这一章我的体会是不要把它当成一堆孤立的概念去背而是把它当成一个工程师面对“海量数据怎么存”这个问题时一步步做出的设计决策。理解了决策背后的权衡概念自然就记住了考试也就没那么可怕了。