1. 为什么我要从HDFS开始聊大数据刚接触大数据那会儿我跟很多人一样被一堆名词砸得晕头转向Hadoop、Spark、Flink、Hive、HBase……每个都像是另一个维度的东西。后来踩了不少坑才明白这些花里胡哨的计算框架底下都踩着一块共同的基石——分布式文件系统。而在开源大数据生态里这块基石最典型、最绕不开的就是HDFS。HDFS全称Hadoop Distributed File System翻译过来就是Hadoop分布式文件系统。它要解决的问题特别朴素一台机器的硬盘装不下了怎么办答案是拆成很多块分散存到一堆机器上然后让这些机器协同工作对外表现得像一块超大硬盘。听起来简单但真要做到像一块硬盘那样好用背后要处理的问题一大堆某台机器突然挂了数据会不会丢几百台机器怎么协调文件怎么切、怎么放、怎么找这些就是HDFS要回答的核心问题。这篇文章适合谁看如果你是刚转行大数据、或者在校学生想搞明白HDFS到底怎么回事那这篇就是写给你的。我会从它为什么长这样讲起把架构、读写流程、副本机制、实操命令、常见故障排查都过一遍尽量用大白话把原理讲透同时给出可以直接抄作业的命令和配置。如果你已经用过HDFS但总觉得会用不会讲这篇也能帮你把脑子里那些零散的点串成一条线。我个人的判断是HDFS不是大数据里最难的但一定是最该先啃透的。因为后面你学MapReduce、Spark、Hive数据从哪来、往哪存全都绕不开它。把HDFS搞明白了后面很多玄学问题其实都能找到根。2. HDFS的整体设计与思路拆解2.1 它到底想解决什么问题先说清楚HDFS的设计目标这决定了它长成什么样。HDFS诞生的场景非常具体一次写入、多次读取的超大文件存储。注意这几个关键词——一次写入、多次读取、超大文件。这三个词几乎决定了HDFS所有的设计取舍。为什么是一次写入多次读取因为HDFS最初是为批处理场景设计的比如日志分析、离线统计。数据写进去之后基本不改就是反复地读、反复地算。这个前提非常重要它意味着HDFS不需要支持随机写、不需要支持频繁修改文件中间某一段内容。你如果拿HDFS当网盘用天天改文件那体验会很差这不是它不行是你用错了地方。为什么是超大文件因为HDFS的默认数据块block大小是128MB老版本是64MB。也就是说一个1KB的小文件在HDFS里也会占用一个block的元数据开销。如果你存几百万个小文件NameNode后面会讲会被元数据压垮。所以HDFS天生不擅长海量小文件这是它的软肋。2.2 主从架构一个大脑加一群苦力HDFS采用的是经典的主从Master-Slave架构核心角色就两个NameNode名字节点整个集群的大脑负责管理文件系统的命名空间目录树、文件名、权限和每个文件被切成了哪些block、这些block分别存在哪些DataNode上。它不存实际数据只存元数据。DataNode数据节点干活的苦力负责实际存储数据块并定期向NameNode汇报自己存了哪些块。这个分工的逻辑很清晰把管理和存储分开。NameNode的元数据量相对小可以全部放在内存里所以响应快DataNode负责海量数据的实际读写可以横向扩展加机器就能扩容量。但这里有个关键问题NameNode是单点。如果它挂了整个集群就瘫痪了。所以生产环境一定要配HAHigh Availability高可用用两个NameNodeActive和Standby加一个JournalNode集群来同步元数据。这个后面会细讲。2.3 为什么块要设成128MB这是新手最容易困惑的点之一。传统文件系统的块一般是4KB为什么HDFS要搞到128MB这么大核心原因是降低寻址开销占比。磁盘读数据分两部分时间寻址时间找到数据在哪和传输时间把数据读出来。如果块很小读一个块大部分时间都花在寻址上传输时间占比低效率就低。块设大之后一次寻址能连续传输大量数据传输时间占比大幅提升整体吞吐就上去了。那为什么不设成1GB、10GB因为块太大也有问题一是MapReduce等计算框架通常一个block对应一个map任务块太大任务数就少并行度不够二是如果某个块损坏重传的代价太大。128MB是实践中权衡出来的经验值当然这个值可以调比如有些场景会调到256MB。提示块大小是可以在创建文件时按文件指定的不一定非要用全局默认值。但大多数情况下用默认值就够了别乱调。2.4 副本机制用冗余换可靠HDFS默认每个block存3份副本replication factor 3。为什么是3这是可靠性和存储成本之间的平衡点。1份太危险2份在极端情况下也可能同时坏3份基本能保证在单机甚至单机架故障时数据不丢。当然如果你的数据没那么重要或者存储成本敏感可以调成2反过来核心数据可以调成4或5。副本的放置策略也很有讲究默认策略叫机架感知Rack Awareness第1份放在写入端所在节点如果写入端在集群内。第2份放在另一个机架的某个节点上。第3份放在第2份所在机架的另一个节点上。这个策略的目的是既要防止单节点故障也要防止整个机架断电或网络故障。把副本分散到不同机架即使一个机架全挂了数据还在。这个设计思路值得记住很多分布式系统都在用类似的故障域隔离思想。3. 核心细节解析与实操要点3.1 NameNode的元数据到底存了什么NameNode的元数据主要分两部分fsimage文件系统的镜像是某一时刻元数据的完整快照。它存在磁盘上。edits log编辑日志记录自上次fsimage之后所有的写操作。它也存在磁盘上。NameNode启动时会加载fsimage到内存然后重放edits log把内存中的元数据恢复到最新状态。之后所有新的写操作都先写edits log再更新内存。这样即使宕机重启后也能通过fsimage edits log恢复。但edits log会越来越大重启时重放很慢。所以有个叫SecondaryNameNode的角色注意它不是NameNode的备份定期做checkpoint把fsimage和edits log合并生成新的fsimage清空edits log。这个合并过程叫checkpoint。注意SecondaryNameNode不是热备它不能接管NameNode的工作。很多人被这个名字误导以为它是备用的NameNode这是大错特错。真正的高可用要靠NameNode HA。3.2 数据块和副本的实操查看理论讲完来点实操。假设你已经有一个HDFS集群怎么查看一个文件被切成了哪些块、副本在哪# 查看文件的块信息 hdfs fsck /path/to/your/file -files -blocks -locations这条命令会列出文件的所有block每个block的ID、大小以及每个副本所在的DataNode。输出里你会看到类似BP-xxx的块池ID和DatanodeInfoWithStorage的节点信息。再比如查看整个文件系统的健康状态hdfs fsck / -files -blocks如果输出里有Status: HEALTHY说明没问题如果有MISSING或CORRUPT就要警惕了。3.3 副本系数怎么改改副本系数分两种情况改单个文件已存在的文件hdfs dfs -setrep -w 2 /path/to/file-w表示等待副本调整完成再返回。这个操作会触发NameNode调度DataNode复制或删除副本。改目录默认值对新建文件生效这个要改hdfs-site.xml里的dfs.replication然后重启相关服务。注意改配置只影响之后新建的文件已存在的文件副本数不会自动变。实操心得调低副本数比如从3调到2会释放存储空间但会降低可靠性。调高副本数会占用更多空间但更安全。生产环境改副本数前一定先评估存储余量和数据重要性别拍脑袋。3.4 安全模式是怎么回事NameNode启动时会进入安全模式Safe Mode。在这个模式下文件系统只读不接受写操作。为什么要有这个模式因为NameNode刚启动时内存里的元数据还没恢复完整它需要等各个DataNode来汇报自己存了哪些block确认副本数达标后才退出安全模式开始接受写请求。查看是否在安全模式hdfs dfsadmin -safemode get手动进入/退出一般只在维护时用hdfs dfsadmin -safemode enter hdfs dfsadmin -safemode leave注意如果集群启动后长时间卡在安全模式通常是某些block的副本数不达标。可以用hdfs fsck /查一下看是不是有大量副本丢失。别急着强制退出安全模式先搞清楚原因。4. 实操过程与核心环节实现4.1 从零搭建一个单机伪分布式HDFS先说明这里讲的是伪分布式也就是所有角色跑在一台机器上适合学习和测试。生产环境是多台机器的完全分布式配置更复杂但原理一样。第一步环境准备一台Linux机器虚拟机也行建议4GB内存以上。安装JDK 8Hadoop 3.x对JDK 8兼容最好。下载Hadoop 3.x安装包解压到某个目录比如/opt/hadoop。第二步配置环境变量编辑~/.bashrc加上export HADOOP_HOME/opt/hadoop export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64然后source ~/.bashrc生效。第三步改配置文件核心配置文件在$HADOOP_HOME/etc/hadoop/下。core-site.xmlconfiguration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/opt/hadoop/tmp/value /property /configurationhdfs-site.xmlconfiguration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/opt/hadoop/data/namenode/value /property property namedfs.datanode.data.dir/name value/opt/hadoop/data/datanode/value /property /configuration注意伪分布式下副本数设成1就行因为只有一台DataNode设3也放不下。第四步格式化NameNodehdfs namenode -format这一步会创建dfs.namenode.name.dir目录并初始化fsimage。格式化只能做一次重复格式化会导致集群ID不一致DataNode认不出NameNode。如果非要重来得把所有data目录清空再格式化。第五步启动start-dfs.sh启动后用jps命令应该能看到NameNode、DataNode、SecondaryNameNode三个进程。第六步验证浏览器访问http://localhost:9870Hadoop 3.x的Web UI端口2.x是50070能看到NameNode的界面就成功了。4.2 常用命令实操HDFS的命令和Linux很像但前缀是hdfs dfs。# 创建目录 hdfs dfs -mkdir -p /user/test/input # 上传本地文件 hdfs dfs -put localfile.txt /user/test/input/ # 查看目录 hdfs dfs -ls /user/test/input/ # 查看文件内容 hdfs dfs -cat /user/test/input/localfile.txt # 下载到本地 hdfs dfs -get /user/test/input/localfile.txt ./ # 删除 hdfs dfs -rm -r /user/test/input/ # 查看磁盘使用 hdfs dfs -df -h实操心得hdfs dfs -put和hdfs dfs -copyFromLocal基本等价但-put可以从标准输入读更灵活。另外上传大文件时如果中途断了HDFS会留下一个.COPYING后缀的临时文件需要手动清理否则会占空间。4.3 读写流程拆解写流程客户端上传文件客户端向NameNode请求创建文件。NameNode检查权限、路径是否存在然后在edits log里记录返回可写的DataNode列表。客户端把文件切成block开始写第一个block。它先写第一个DataNode第一个DataNode再转发给第二个第二个转发给第三个形成管道pipeline。每个DataNode写完一个packet数据包后会反向发ack确认。所有block写完客户端通知NameNode关闭文件。这个管道机制的好处是客户端只需要和第一个DataNode通信带宽压力分散到多个节点。坏处是管道中任何一个节点慢整个写入都会慢。读流程客户端下载文件客户端向NameNode请求读取文件。NameNode返回该文件所有block的位置信息按距离排序优先返回近的。客户端直接连到最近的DataNode读取block。读完一个block再读下一个。注意读的时候NameNode只告诉客户端去哪读实际数据传输不经过NameNode。这就是为什么NameNode不会成为读性能瓶颈。4.4 参数计算block大小和副本数怎么定假设你要存一个1TB的数据集默认block 128MB副本3份需要多少存储数据块数1TB / 128MB 1024 * 1024 / 128 8192个block。总存储需求1TB * 3 3TB不考虑元数据和冗余开销。如果改成block 256MB块数减半到4096个NameNode的元数据压力减半但单个map任务处理的数据量翻倍可能影响并行度。所以block大小要根据你的计算框架和集群规模来权衡。副本数从3降到2存储需求从3TB降到2TB省了1/3但可靠性下降。这个取舍没有标准答案看你的数据重要性和预算。5. 常见问题与排查技巧实录5.1 常见问题速查表问题现象可能原因排查思路解决方法NameNode启动失败重复格式化导致clusterID不一致看NameNode日志清空data目录重新格式化集群卡在安全模式副本数不达标hdfs fsck /等DataNode汇报或手动修复副本上传文件报Could not obtain blockDataNode磁盘满或宕机看DataNode日志和磁盘清理磁盘或重启DataNode读取文件很慢副本分布不均或网络问题hdfs fsck看副本位置触发副本均衡hdfs balancerNameNode内存溢出小文件太多看NameNode堆内存和文件数合并小文件调大堆内存DataNode无法连接NameNode网络或端口问题telnet测试端口检查防火墙和配置5.2 小文件问题HDFS最大的坑前面提过HDFS不擅长小文件。为什么因为每个文件、每个block在NameNode内存里都要占一份元数据大约150字节。如果你有1亿个小文件光元数据就要15GB内存NameNode直接爆掉。解决办法有几个合并小文件用hadoop archiveHAR把多个小文件打包成一个大文件。用SequenceFile或ORC/Parquet把多个小文件的内容写进一个大文件里用key-value形式组织。在采集端就合并比如Flume配置成按大小或时间滚动别一个事件一个文件。实操心得我见过一个集群因为上游每5分钟生成几千个小文件NameNode内存天天告警。后来在采集端加了合并逻辑文件数降了90%问题直接消失。所以小文件问题最好在源头解决别等进了HDFS再补救。5.3 副本丢失怎么处理如果hdfs fsck /显示有block副本数不足先别慌。NameNode会自动调度复制只要还有至少一个副本存活数据就不会丢。你可以等它自动恢复也可以手动触发hdfs dfsadmin -triggerBlockReport如果所有副本都丢了那这个block就真的没了文件会损坏。这时候只能从备份恢复。所以定期备份重要数据是铁律HDFS的副本机制不是备份它防的是硬件故障防不了误删。5.4 性能调优的几个关键参数dfs.blocksize块大小默认128MB。大文件多可以调大。dfs.replication副本数默认3。存储紧张可以调2。dfs.namenode.handler.countNameNode处理RPC的线程数默认10。集群大、并发高可以调大。dfs.datanode.max.transfer.threadsDataNode处理传输的线程数默认4096。高并发读写可以调大。dfs.balance.bandwidthPerSecbalancer的带宽限制默认1MB/s。想快点均衡可以调大但别影响正常业务。调参的原则是先定位瓶颈再调对应参数。别一上来就把所有参数拉满那样只会让问题更难排查。6. 我个人踩过的几个坑第一个坑是格式化NameNode。刚学的时候集群起不来我就反复hdfs namenode -format结果越格越乱。后来才知道格式化会生成新的clusterID而DataNode还记着旧的两边对不上。正确做法是格式化前先停掉所有进程清空所有data目录再格式化。第二个坑是把SecondaryNameNode当备份。有次NameNode挂了我以为SecondaryNameNode能顶上结果发现它根本不能接管。后来老老实实配了NameNode HA用两个NameNode加JournalNode才算真正解决了单点问题。第三个坑是小文件。前面讲过不重复了。总之记住HDFS喜欢大文件讨厌小文件。第四个坑是磁盘满。DataNode磁盘满了之后写入会失败但NameNode可能还不知道继续往那个节点调度写请求。所以一定要配磁盘监控快满的时候及时清理或扩容。7. 后续可以怎么扩展HDFS搞明白之后下一步可以往几个方向走NameNode HA配两个NameNode用ZooKeeper做自动故障转移。这是生产环境必备。Federation如果元数据量太大单个NameNode扛不住可以用Federation把命名空间拆成多个每个NameNode管一部分。和计算框架结合学MapReduce或Spark看它们怎么读HDFS的数据怎么把计算任务调度到数据所在的节点数据本地性。存储格式学Parquet、ORC这些列式存储格式它们和HDFS配合能大幅提升查询效率。HDFS本身不复杂但它是整个大数据生态的地基。地基打牢了上面盖什么楼都稳。我个人的体会是别急着追新框架先把HDFS这种基础组件吃透后面学什么都快。
