搞大数据的同学几乎都绕不开Hadoop这个名字。哪怕到了今天各种新型计算引擎层出不穷Hadoop依然是整个大数据生态的地基。我接触Hadoop这么多年从最早的0.20.x版本一路用到3.x最大的感受是很多概念如果你只停留在背定义的层面真正上手排错的时候会非常痛苦。这篇博文是Hadoop系列的第一篇我把Hadoop从“它到底解决什么问题”开始讲起把HDFS、MapReduce、YARN这三驾马车的核心原理和它们之间的协作关系拆开揉碎再配合一些我在实际部署和排障过程中踩过的坑争取让零基础的读者也能建立起一套完整的认知框架。1. 内容整体设计与思路拆解1.1 为什么大数据的起点是Hadoop先从一个最朴素的问题说起数据量大了到底难在哪我自己的理解是难点不在于“存不下”而在于“存下了之后没法用”。单块硬盘现在能做到十几TB但一台服务器的存储容量撑死了几十TBCPU和内存也有物理上限。当数据量达到PB级别你根本找不到一台能装下所有数据的机器更别说在这台机器上跑计算了。Hadoop的核心思路其实特别朴素用一群廉价的普通服务器组成集群把数据切分成小块分散存储再把计算任务也拆分成小块分发到每台机器上并行执行。换句说话移动计算比移动数据更划算——数据不动计算去找数据。这个思路听起来简单但落地起来需要解决一堆问题数据怎么切、切完怎么知道每块在哪、某台机器挂了怎么办、任务失败了怎么重跑。Hadoop的整个架构设计本质上都是围绕这些问题展开的。这也是为什么我一直建议初学者不要一上来就啃源码或者背面试题而是先搞清楚“Hadoop是为了解决什么痛点才被设计出来的”。理解了痛点再看它的每一个组件你会觉得那些设计都是顺理成章的而不是一堆需要死记硬背的名词。1.2 Hadoop生态全景图它到底包含什么很多人会把Hadoop和HDFS、MapReduce划等号这其实是1.x时代留下的印象。到了2.x和3.x时代Hadoop已经是一个完整的生态体系官方发行版里至少包含四大模块模块核心作用替代/演进方向HDFS分布式文件存储系统各家云上文件存储、对象存储MapReduce分布式计算框架离线批处理Spark、FlinkYARN资源调度与管理平台Kubernetes容器化调度Hadoop Common公共工具库序列化、RPC、配置文件等随版本演进严格来说Hadoop Common不是给人直接用的功能模块而是前三个模块共同依赖的基础库。理解这一点很重要你在配置hadoop-env.sh、core-site.xml这些文件时改的其实都是Common层面的配置项。另外一个容易混淆的点是MapReduce虽然是计算框架但它在生态里的定位是“离线批处理”。什么叫离线批处理就是数据已经完整地躺在HDFS里了你发起一个计算任务经过一段时间的处理最终产出一份结果。它不擅长实时响应也不擅长流式计算。所以现在很多场景下人们会用Spark替代MapReduce来跑批处理但HDFS作为存储层依然坚挺。这也是为什么很多公司说起“大数据平台”底层必然有一套HDFS集群。1.3 学习Hadoop的正确姿势基于我自己的学习路径和带新人的经验学Hadoop最忌讳的是“贪多求快”。今天看HDFS明天看YARN后天又去捎带手看看Spark结果哪个都没吃透。正确的路径应该是第一先搭建一个单节点伪分布式环境亲手把HDFS启动起来用命令行上传下载文件。这一步能帮你把“分布式”这个概念落到实处。第二写一个最简单的MapReduce程序比如WordCount跑通整个流程然后去看日志里的map、reduce、shuffle各阶段耗时理解一个任务从提交到完成到底经历了什么。第三再去研究YARN的资源调度逻辑搞清楚Container、队列、调度器这些概念。到这一步你会发现前面跑通的MapReduce任务其实全程都在YARN的管理之下。第四回过头来系统梳理三个组件之间的协作关系这个时候你再看架构图每一根连线你都能说出它背后的通信机制。我见过太多人跳过第一步直接去啃源码结果就是越看越懵最后连集群都启动不起来。记住Hadoop的很多设计精巧之处恰恰是在你亲手操作、遇到问题、解决问题的过程中才能真正体会到的。2. HDFS核心机制深度拆解2.1 HDFS的架构角色NameNode和DataNode的分工HDFS采用了经典的主从架构。集群里的节点分成两类角色NameNode主节点和DataNode从节点。为了兼顾高可用还可能有多个NameNode组成Active/Standby模式以及一个负责协调的JournalNode集群。NameNode管什么它管元数据。也就是说它不存真正的数据内容而是记录“哪个文件在哪些DataNode上、文件被切成了多少个块、每个块分别存放在哪里、副本状态如何”这类信息。你可以把它类比成图书馆的总目录——书本身放在各个书架上但你要知道某本书在哪个书架的哪一层必须查总目录。DataNode管什么它管真正的数据块。数据写入时被切分成固定大小的Block默认128MB每个Block会被复制成多份默认3副本分散存放在不同的DataNode上。DataNode启动后会周期性向NameNode发送心跳和块报告BlockReport告诉NameNode“我这边有哪些块、状态是否健康”。这里有个特别容易踩坑的点NameNode不直接参与数据传输。当客户端要读一个文件时它先向NameNode请求元数据拿到文件各个Block所在的DataNode列表然后由客户端直接去对应的DataNode拉数据。这个设计大大减轻了NameNode的负载但也意味着NameNode一旦宕机整个集群的读写都会瘫痪——因为它是指挥中心不是数据搬运工。2.2 数据块与副本机制为什么是128MB和3副本先说说Block为什么默认是128MB。早期的Hadoop版本默认64MB后来改成128MB。Block越大意味着一个文件被切分的块数越少NameNode需要维护的元数据条目越少同时MapReduce任务处理时的“启动任务”开销也越低。但Block不是越大越好太大了会导致并行度下降因为一个Block只能被一个Map任务处理这是MapReduce的设计约束。所以128MB是在“元数据开销”和“并行度”之间折中的结果。再说说副本数为什么默认是3。3副本的初衷是同机架放一个副本另一个副本放在不同机架的某台机器上第三个副本再放在另一个不同机架的某台机器上。这样即使整个机架断电数据依然至少还有一份可以读取。当然如果你的集群只有几台机器机架感知策略是可以忽略的Hadoop会退化为随机放置。副本数量的配置项是dfs.replication可以在hdfs-site.xml里改。但我建议生产环境不要轻易调低副本数尤其不要为了省存储空间把副本数改成1。我见过有人为了节约磁盘把副本改为1结果一台DataNode磁盘损坏直接导致大量数据永久丢失。存储成本高但数据丢失的代价更高。2.3 数据写入与读取的完整流程HDFS的写入流程值得反复看因为很多面试题和实际排障都围绕它展开。客户端写入一个文件时流程大致是客户端调用FileSystem.create()向NameNode发起创建文件请求。NameNode检查权限和路径合法性在命名空间中创建文件条目此时文件长度为0返回确认信息。客户端开始写入数据先把数据按64KBdfs.client.block.write.cache.size切分成一个个chunk写入本地临时缓冲区。第一个Block写满128MB后客户端向NameNode申请新的Block分配信息NameNode返回一个DataNode管道列表比如3个DataNode。客户端将数据逐chunk推送给管道中的第一个DataNode第一个DataNode再转发给第二个依次类推。这就是所谓的“流水线复制”Pipeline Replication目的是避免客户端反复与每个副本通信。每个DataNode写完一个chunk后向管道上游返回确认ACK客户端收到所有ACK后才认为该chunk写成功。所有Block写完后客户端调用close()告知NameNode文件写入完成。这个流程中我最想提醒读者的是如果管道中某个DataNode写失败了不意味着整个写入失败。Hadoop会把失败的节点从管道中移除然后让NameNode重新分配一个新节点把剩余数据继续写入。同时这个Block的副本数会暂时低于预期值NameNode后台会启动“副本复制”机制让多余的副本重新补齐。理解了这一点你再看集群日志里某些Block处于“Under Replicated”状态就不会慌了。读取流程相对简单客户端向NameNode发送路径请求获取文件对应的Block列表和每个Block的存放位置列表然后客户端就近选择一台DataNode读取。如果客户端和某个DataNode在同一机架优先读本机架节点这样可以节省跨机架带宽。2.4 HDFS命令行操作与权限细节日常使用HDFS最常用的就是hdfs dfs命令。我列出几个高频操作# 查看根目录下的文件列表 hdfs dfs -ls / # 递归查看某个目录 hdfs dfs -ls -R /data # 从本地上传到HDFS hdfs dfs -put /local/path/file.txt /data/ # 从HDFS下载到本地 hdfs dfs -get /data/file.txt /local/path/ # 创建目录 hdfs dfs -mkdir -p /data/logs/2024 # 查看文件大小按字节显示建议加-h参数 hdfs dfs -du -h /data # 删除文件/目录注意-trash表示放入回收站 hdfs dfs -rm -r -skipTrash /tmp/old_data权限方面经常出问题的是“权限不足”。HDFS的权限模型跟Linux类似也是owner/group/other三元组加读写执行权限。但有个容易忽略的坑HDFS的超级用户可以通过dfs.permissions.superusergroup配置指定默认supergroup对应的用户是启动NameNode的用户。你在Windows上开发连Linux集群时默认用户是root或你的用户名如果跟HDFS上的文件属主不一致就会报Permission denied。我惯用的排查方法是先执行hdfs dfs -ls确认文件属主再确认当前用户身份不要一上来就chmod 777那样会让权限体系形同虚设。2.5 高可用架构与安全模式在Hadoop 2.x之前NameNode单点故障是个痛点一旦它宕机整个集群不可用。2.0之后引入HDFS HAHigh Availability通过两个NameNodeActive/Standby JournalNode共享编辑日志的方式实现故障自动切换。Active NameNode负责处理所有客户端请求和写入操作同时把操作日志EditLog实时写入JournalNode集群。Standby NameNode持续读取EditLog并重放到自己的内存中保证元数据与Active节点保持同步。一旦Active宕机Standby通过ZooKeeper协调自动切换为Active。实践中有个坑我要重点说NameNode启动时如果进入安全模式SafeMode只读不写。安全模式的本质是NameNode在启动时需要等DataNode汇报块信息确认哪些块可用、哪些需要复制。如果你在安全模式下尝试删除文件很可能失败或报错。排查时可以先执行hdfs dfsadmin -safemode get查看状态如果是ON且集群刚启动耐心等一会儿即可如果是异常进入安全模式要重点检查磁盘空间和NameNode日志。3. MapReduce计算模型与执行原理3.1 从WordCount理解Map和Reduce的本质MapReduce被称为“来自谷歌的编程模型”它的核心思想一句话就能概括把一个大任务拆成无数个小任务分给多个节点并行执行再把结果合并起来。我教新人时几乎都用WordCount举例。假设你要统计一批文本文件中每个单词出现的次数Map阶段每个Mapper读取一行文本按空格拆词对每个词输出一个键值对(word, 1)。比如输入“hello world”Mapper输出(hello, 1)和(world, 1)。Shuffle阶段框架把所有Mapper输出的结果按照键进行排序和分组把相同单词的所有value归并到一起形成(hello, [1,1,1,1])这样的结构交给对应的Reducer。Reduce阶段每个Reducer把收到的value列表求和输出(hello, 4)这样的最终结果。整个过程里业务代码只需要写Mapper和Reducer两个函数剩下的切分输入、分发任务、排序、分组、容错重跑全部由框架完成。这就是MapReduce的价值所在程序员只关注“怎么处理单条数据”和“怎么合并局部结果”而分布式系统的复杂性被隐藏了。3.2 Shuffle的四个关键阶段Shuffle是MapReduce中最复杂、也最容易出性能问题的环节。我把它拆成四个阶段方便你理解第一分区Partition。Map输出的每条记录根据key的哈希值计算该进哪个Reducer。默认分区函数是HashPartitioner如果你希望某个key固定进某个Reducer可以自定义Partitioner。第二排序Sort。Map端和Reduce端都会对key排序。排序不是可选项而是MapReduce的默认行为。这保证了相同key的记录在Reduce端是连续且有序到达的。第三溢写Spill。Map任务在输出过程中如果内存缓冲区达到阈值默认80%会溢写到本地磁盘上的临时文件。多次溢写会产生多个文件最终合并成一个分区有序文件。第四拉取Fetch。Reduce任务启动后向各个已完成Map任务的节点拉取属于自己的分区数据。注意Reduce任务必须等所有Map任务完成才能进入Shuffle的拉取阶段因为每个Reducer需要的key可能分布在任意一个Mapper的输出中。这里有句老话MapReduce的效率瓶颈九成在Shuffle。你在一篇WordCount跑得贼快但一到TB级数据就慢如蜗牛大概率就是Shuffle的中间结果落盘太多、网络传输太大。这也是后来Spark等框架试图优化的重点——把中间结果尽量留在内存里。3.3 任务提交与执行流程一个MapReduce作业从提交到完成完整流程如下客户端通过Job.submit()提交作业向ResourceManager申请一个新的Application ID。客户端把作业所需要的Jar包、配置文件和输入分片信息上传到HDFS的临时目录通常是/tmp/hadoop-yarn/staging。ResourceManager在某个NodeManager上启动一个ApplicationMaster进程中AM负责这个作业的全生命周期管理。AM根据输入分片数量向ResourceManager申请容器Container来运行Map任务Map任务全部完成后再申请容器运行Reduce任务。每个任务运行过程中AM持续监控进度。如果某个任务失败AM会在另一个节点上重新调度执行。作业完成后AM注销并释放所有资源客户端收到完成通知。注意这个架构里MapReduce里的“JobTracker/TaskTracker”已经是历史名词。1.x时代是JobTracker负责任务调度TaskTracker管任务执行它俩和HDFS的NameNode/DataNode是重叠部署的。2.x之后YARN把资源管理独立出来调度逻辑全部收归ResourceManager具体任务的执行由NodeManager管理的Container承载。3.4 数据本地性与推测执行数据本地性Data Locality是MapReduce性能的关键。因为移动计算比移动数据划算所以调度器会尽量把Map任务调度到数据所在节点上。这样Map任务直接从本地磁盘读取Block避免了网络IO。如果本地节点没有空闲资源调度器会退而求其次调度到同机架的节点只有万不得已才会跨机架调度。所以你在任务日志里经常能看到># 检查JDK版本确认已安装 java -version # 检查SSH服务状态 systemctl status sshd6.2 下载与配置核心文件去Apache官网下载hadoop-3.3.x.tar.gz解压到/opt/hadoop目录。然后进入/opt/hadoop/etc/hadoop目录修改四个配置文件第一hadoop-env.sh。设置JDK路径export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export HDFS_NAMENODE_USERroot export HDFS_DATANODE_USERroot export YARN_RESOURCEMANAGER_USERroot export YARN_NODEMANAGER_USERroot注意3.x系列对这些用户变量要求严格如果不设置启动时可能报错Cannot set priority of namenode process之类的问题。第二core-site.xml。设置默认文件系统为HDFS以及NameNode的地址configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/opt/hadoop/tmp/value /property /configurationhadoop.tmp.dir这个配置项容易被忽略它决定了NameNode和DataNode的数据存放目录的根路径。如果不设置默认是/tmp系统一清理临时目录元数据就没了后果是集群无法启动。第三hdfs-site.xml。设置副本数和NameNode的HTTP端口configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name valuefile:///opt/hadoop/tmp/dfs/name/value /property property namedfs.datanode.data.dir/name valuefile:///opt/hadoop/tmp/dfs/data/value /property /configuration伪分布式只有一台机器副本数必须设为1否则会一直出现Under replicated的告警。第四yarn-site.xml。启用YARN的关键配置configuration property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property property nameyarn.nodemanager.aux-services.mapreduce_shuffle.class/name valueorg.apache.hadoop.mapred.ShuffleHandler/value /property /configurationaux-services这个配置是MapReduce依赖YARN跑Shuffle的关键漏配的话MR作业会一直卡在提交阶段。6.3 初始化与启动验证配置文件改完后第一步必做的是格式化NameNodehdfs namenode -format格式化会清空NameNode的元数据目录并初始化文件系统。这里有个大坑我得强调格式化的结果等同于清空整个HDFS的数据生产环境误执行一次后果是灾难性的。所以生产集群的主管节点格式化前一定要确认机器上不存在已有数据。格式化完成后启动HDFS和YARN$HADOOP_HOME/sbin/start-dfs.sh $HADOOP_HOME/sbin/start-yarn.sh启动后用jps命令检查进程是否都在jps正常能看到这几个进程NameNode、DataNode、ResourceManager、NodeManager。如果缺少某一个去对应的日志目录$HADOOP_HOME/logs查看日志绝大多数启动失败的原因都写在日志里。验证HDFS可用的最简单方式是执行hdfs dfs -mkdir /test创建一个目录再执行hdfs dfs -ls /看看能否看到。6.4 提交一个MapReduce示例作业Hadoop自带示例Jar包里面有很多现成程序。用它跑一个WordCount是最直接的验证。# 准备输入数据 hdfs dfs -mkdir -p /wordcount/input echo hello world hello hadoop | hdfs dfs -put - /wordcount/input/test.txt # 运行WordCount hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.x.jar \ wordcount /wordcount/input /wordcount/output # 查看结果 hdfs dfs -cat /wordcount/output/part-r-00000注意输出目录/wordcount/output必须事先不存在否则作业会报org.apache.hadoop.mapreduce.lib.output.FileAlreadyExistsException直接退出。这是新手踩得最多的坑之一别问我怎么知道的。作业运行过程中可以打开YARN的Web界面查看进度http://localhost:8088。你会看到Application列表、活跃的NodeManager、每个Container的资源分配情况。看一遍实际运行界面比看十篇架构文章都直观。7. 常见问题与排查技巧实录7.1 集群启动失败的常见原因我把这些年遇到的启动失败问题整理成一张速查表方便对照排查症状可能原因排查方向NameNode启动即退出dfs.namenode.name.dir目录不存在或无权限检查目录是否存在属主是否是启动用户DataNode启动失败dfs.datanode.data.dir目录异常或版本不匹配清空data目录确认无业务数据重新初始化ResourceManager无法启动端口被占用默认8088执行netstat -tlnp看端口占用情况集群启动但无法写入文件磁盘空间不足执行df -h检查特别关注hadoop.tmp.dir所在分区安全模式一直不退出NameNode等待Block汇报或块数量异常hdfs dfsadmin -safemode get查看状态检查DataNode日志这里有一个我在实际运维中总结的经验启动Hadoop集群后不要立刻执行大数据操作先等30秒到一个分钟让DataNode向NameNode完成块汇报确认安全模式退出了再做事。很多新手一启动就写数据碰上安全模式报错还以为集群坏了其实只是还没就绪。7.2 空间与性能相关的经典坑磁盘空间问题是HDFS的老大难。尤其在生产环境DataNode磁盘写满时HDFS不会自动删除数据而是不断抛出异常。这里有一个大家容易忽略的点NameNode所在节点的磁盘空间不足比DataNode磁盘不足更严重。因为NameNode的元数据要写日志磁盘满了EditLog写不进去集群会直接进入安全模式进而整个集群只读。另一个常见性能问题是小文件过多。HDFS的Block最小128MB但一个1KB的文件也会占用一个Block的元数据条目同时MapReduce处理时每个小文件单独算一个分片导致Map任务数量爆炸。我曾经处理过一个业务几百万个几十KB的小文件一个作业能产生几十万个Map任务调度开销把集群活活拖垮了。解决方案通常是把小文件合并成大文件或者用HBase等专门的系统来管理。如果你还没法改业务至少可以在写入时用hdfs dfs -getmerge或压缩格式归档一下。7.3 日志分析与任务排查的实用技巧Hadoop的日志分散在多个地方新人经常不知道去哪找。我梳理一下最常用的日志路径HDFS守护进程日志$HADOOP_HOME/logs/hadoop-{user}-{daemon}-{host}.logYARN调度日志同上目录下的yarn-resourcemanager-*.log和yarn-nodemanager-*.logMapReduce作业日志YARN Web界面8088点击对应Application进去看每个任务的日志链接历史作业日志JobHistoryServer运行时的mapred-site.xml中配置的mapreduce.jobhistory.intermediate-done-dir排查一个失败的MR作业我的固定路线是先看YARN界面上Application的状态FAILED还是KILLED再点进任务列表找到失败的Task查看Container日志中的异常栈。有经验的工程师通常看一眼异常栈前几行就能定位问题ClassNotFoundException多半是Jar包没传全OutOfMemoryError多半是内存参数太小FileNotFoundException多半是输入路径写错了。7.4 数据安全相关的提醒最后强调一点数据安全。HDFS默认的hdfs dfs -rm是直接物理删除不经过回收站。虽然可以配置fs.trash.interval开启回收站但默认情况下删除是不可逆的。我在生产环境出过一次事故一条误执行的清理脚本删掉了当天所有日志数据因为没有开启回收站根本没法恢复。从那以后我给自己定了几条规矩第一所有涉及删除的命令先加-dryRun或先列出文件数量确认无误再执行。第二生产集群必须开启fs.trash.interval哪怕只保留3天也足以应对大部分误操作。第三重要数据定期做快照hdfs dfsadmin -allowSnapshot开启快照功能后对目录执行hdfs dfs -createSnapshot快照是防止误删的最后一道防线。这些习惯看起来多花了点时间但真到事故发生时能救你命。8. 学习路径建议与扩展方向如果这篇概述你完整读下来了下一步我建议按这样的顺序深入先把HDFS刷透。动手操作文件读写模仿故障场景比如手动杀掉一个DataNode进程观察块复制机制是否自动补副本这些亲身实验会让你对副本机制产生肌肉记忆。然后学习MapReduce编程。不要只看WordCount试着写一个统计日志中错误码分布的程序、一个多表关联的程序。写的过程中你会遇到分区、排序、Combiner、自定义Writable这些概念每踩一个坑就多一层理解。再往后可以了解Spark与Hadoop的关系。理解了MapReduce的Shuffle痛点你就明白Spark为什么要把数据缓存在内存里理解了YARN的资源管理你就明白Spark作业为什么也能跑在YARN上。二者不是替代关系而是生态内的协作关系。Hadoop的知识体系很庞大但它的核心骨架其实就三块存HDFS、算MapReduce、管YARN。把这个骨架理解透后面学Hive、HBase、Spark、Flink都会顺畅很多。我个人在实际带团队时有个体会凡是Hadoop基础扎实的人学新组件都快得离谱凡是基础不牢就追新框架的人遇到问题往往连排查方向都找不到。这篇概述的意义就是先帮你把地基打牢。下一篇我会专门写HDFS的架构细节和调优实践老规矩看完记得自己动手跑一遍环境光看不练等于白看。