很多人学 Hadoop 的方式是先找个安装教程在虚拟机里稀里糊涂敲完一串命令看到NameNode起来了、50070端口能访问了就觉得自己“会了”。但等面试官问一句“NameNode 挂了怎么办”或者让在真实集群上排查个问题瞬间露馅。这也是“跟韩工学 Hadoop”系列想解决的痛点——韩工在内部培训时反复强调一句话先想清楚它凭什么这么设计再动手敲命令。我把他的讲义重新翻译整理成系列文章结合自己这些年部署、排障、面试候选人的经验做了补充这就是整个系列的第一篇简介。这篇会帮你把 Hadoop 的完整轮廓建立起来搞清楚它到底解决什么问题、核心组件分别干什么、生态圈里那些名字Hive、Spark、Zookeeper都是什么角色以及什么场景该用它、什么场景千万别硬上。适合所有准备入门大数据、正在备考 Hadoop 相关面试、或者装过环境但心里没底的同学。1. 这个系列想解决什么问题先懂原理再动手1.1 为什么很多人装完 Hadoop 就只会“跑通 demo”我看过太多这样的求助帖照着教程把 Hadoop 装好了伪分布式能启动然后呢不知道下一步该干什么。再遇到一点异常比如DataNode起不来、端口被占用、磁盘空间不足、safe mode卡住就只能删掉重装。根本原因是学习路径搞反了——教程教的是“按顺序敲这些命令”而不是“这些命令背后的角色和它们的关系”。热搜词里出现频率最高的几个恰恰印证了这一点hadoop伪分布式搭建、hadoop安装与配置、hadoop集群搭建、hadoop的docker镜像。全是操作层面的需求。操作当然要学但如果只停留在操作层面换个发行版、改个网络环境就抓瞎。我见过有人连fs.defaultFS和dfs.replication这两个配置项都说不清是干什么的但集群已经搭起来了。这就像车开得挺溜但不知道发动机为什么转——日常代步没问题抛锚时只能打电话叫救援。韩工这个系列最核心的主张就是不要把 Hadoop 当成一组需要背诵的命令而是把它当成一套为解决特定问题而设计出来的系统。每个组件解决一个问题每个参数背后都对应一个权衡。理解了这一层再看那些安装文档、面试题、调优文章你会觉得它们讲的其实是同一件事。1.2 从简介到实战的系列路线“跟韩工学 Hadoop”不是单篇而是一条完整的学习路径。我把韩工原版的讲解框架梳理了一下结合国内开发者常见的环境虚拟机、Docker、云服务器规划了下面的系列节奏第1篇本篇Hadoop 整体简介建立全局认知第2篇起伪分布式搭建先把单机跑通后续完全分布式集群搭建、HDFS 读写原理与 Shell 操作、MapReduce 编程模型、YARN 资源调度、Zookeeper 整合实战、Hadoop HA 高可用、数据迁移工具 DistCp 参数详解、常见面试题拆解翻译整理版做什么不是逐句翻译韩工的讲义而是保留他那种“从问题出发讲原理”的思路再补上我在中文社区和实际部署中遇到的坑。比如原版可能默认读者有干净的 Linux 环境但国内新手往往卡在虚拟机网络配置、镜像源下载、内存分配这些事上这些我都会在后续的实操篇里补齐。这套系列适合谁三种人最合适一是完全零基础、想进入大数据行业的新人需要一条不会劝退的路线二是已经能跑通环境但因为原理薄弱面试总是底气不足的同学三是工作中要用 Hadoop 但要自己维护、排障的工程师。如果你是这三种之一建议按顺序跟下来每篇动手做一遍不要只看不练。2. Hadoop 的底层逻辑三篇论文和一个开源项目的逆袭2.1 大数据到底难在哪传统方案为什么扛不住要说清楚 Hadoop 的价值得先看它出现之前的世界是什么样。2003 年前后互联网公司面临的问题非常具体网页数据量爆炸式增长搜索引擎要存储和处理的文件多到单台机器放不下。传统方案要么是买更贵的大型机垂直扩展要么是把数据分到多台机器上手动管理水平扩展。前者贵到离谱后者难在两点第一硬件故障成为常态。一台机器一年坏几次很正常100 台机器就意味着几乎每天都有硬件故障。数据分散在这么多机器上怎么保证不丢怎么在机器坏了之后还能继续读写第二并行计算的复杂度。把一个大文件分成多份放在多台机器上写一个统计程序时你得自己操心哪些任务跑在哪些机器上、任务失败怎么重试、中间结果怎么汇总。这些问题不做抽象的话每个业务方都得从头造轮子。Google 的做法是写论文GFS分布式文件系统、MapReduce分布式计算模型、BigTable分布式列存储。这三篇论文把“大规模数据如何存储”和“大规模数据如何计算”这两个问题给出了可落地的方案。Hadoop 就是 Doug Cutting 在开源世界里对这几篇论文的实现——他的 Nutch 项目需要处理海量网页于是照着论文写出了一个开源版 GFS 和 MapReduce后来独立成 Apache Hadoop 项目。所以说Hadoop 能成为大数据事实标准不是因为它的代码有多优雅而是因为它把分布式系统里的存储和计算这两件最难的事做成了普通人也能用的开源工具。2.2 HDFS 的由来把“文件”拆成“块”的存储思路传统文件系统里一个文件就是一整块数据存在某台机器的某个目录里。文件太大单机磁盘放不下文件太重要机器一坏就全没。HDFSHadoop Distributed File System解决这两个问题的思路可以总结成三句话文件拆块、块存多份、目录集中管理。具体来说HDFS 把一个大文件切成若干个固定大小的块默认 128MB可以配置每个块独立存储并且默认复制 3 份放在不同机器上。这样单块损坏不影响整个文件因为还有其他副本单个文件的大小突破了单机磁盘上限因为块可以分布在整个集群的所有机器上。这里有个值得展开的细节为什么块要设成 128MB 这么大如果还是像普通文件系统那样用 4KB 或 64KB 的块一个 1TB 的文件会拆成上亿个块而 HDFS 的元数据每个块的路径、位置、副本信息是放在内存里的块数量过多会把 NameNode 的内存撑爆。所以 HDFS 选择大块本质上是用更大的存储粒度换取更低的元数据开销。理解了这一点你再看dfs.blocksize这个参数就明白它不是一个随便拍的数值而是容量与可靠性的权衡结果。2.3 MapReduce 的由来移动计算比移动数据更划算数据存好了怎么算在分布式环境下最自然的想法是把数据汇总到一台机器上再算。但数据量大到一定程度网络传输就成了最大的瓶颈——把 1PB 数据搬到一台机器上时间长得不可接受。Google 的思路是反过来把计算程序分发到数据所在的机器上每台机器先算自己本地的那份数据再把局部结果合并。这就是 MapReduce 的雏形。做一个生活化类比大学食堂中午要给一万名学生供餐如果所有饭菜都在一个中央厨房做好再分发到各个窗口配送压力巨大实际做法是每个食堂窗口都有自己的小厨房就地备餐最后把成品摆出来。MapReduce 的Map阶段就是各个窗口就地加工Reduce阶段就是把各窗口的成品汇总起来。这里的关键洞察是移动计算的成本远低于移动数据的成本尤其是当数据规模达到 PB 级别时这个策略是唯一现实的选择。所以 Hadoop 两大核心——HDFS 管存储、MapReduce 管计算——其实是从两个不同维度回答同一个问题数据太大了单机扛不住怎么把一堆普通机器组织成一个能存、能算的“超级计算机”。这套逻辑放在今天看已经是常识但放在 2006 年 Hadoop 诞生的时候是真的划时代的。3. 四大核心组件逐一拆解名字好记职责要分清3.1 HDFS 里的“图书管理员和书架”NameNode 与 DataNode很多新手分不清 NameNode 和 DataNode其实职责非常清晰。NameNode 是管理节点负责记录文件系统的目录结构、每个文件被切成哪些块、每个块存在哪些机器上——这些统称元数据。DataNode 是工作节点真正存储数据块并定期向 NameNode 汇报自己持有哪些块。用图书馆来类比NameNode 是图书管理员脑子里有一张卡片目录知道每本书放在哪个书架的哪一排DataNode 是书架本身书就放在这里。读写流程也不复杂。客户端要读一个文件先问 NameNode 要“这个文件有哪些块、各在哪些 DataNode 上”拿到地址后直接去对应的 DataNode 读数据要写一个文件先问 NameNode 申请“我要创建文件”NameNode 返回一批 DataNode 列表客户端把数据块依次写过去写完告诉 NameNode 登记。注意数据读写都不会经过 NameNode——那只是目录查询服务真正传数据的通道是客户端和 DataNode 之间的直连。这里有一个很容易被忽略的组件SecondaryNameNode。它常被误解为 NameNode 的热备实际上不是。它的职责是定期合并 NameNode 的编辑日志edits和镜像文件fsimage目的是防止日志文件无限膨胀以及加快 NameNode 重启恢复速度。它是“检查点辅助节点”不是“备用节点”。真正确保高可用的是后面会讲的 HA 方案Active/Standby NameNode Zookeeper 选主。3.2 YARN把节点资源变成“可调度货架”Hadoop 早期的版本里MapReduce 既要负责计算逻辑又要负责资源调度结果是调度能力弱、扩展性差。后来社区把资源管理这块独立出来就成了 YARNYet Another Resource Negotiator。YARN 的定位很纯粹它是一个分布式资源调度系统管的是每台机器上有多少 CPU、多少内存谁想用、用多少、用多久。YARN 有两个核心角色。ResourceManagerRM是全局的“房东”掌握整个集群的资源总量负责接收客户端的作业请求把它拆成若干个需要资源的 Container然后分配到各个节点。NodeManagerNM是每台机器上的“二房东”管理本节点的资源按 RM 的指令启动和销毁 Container。一个作业跑起来RM 负责整体调度NM 负责实际执行两边通过心跳保持同步。YARN 的诞生有个重要影响HDFS 上跑什么计算不再只有 MapReduce 一个选择了。Spark、Flink 这些计算引擎都可以跑在 YARN 上只要它们能按 YARN 的协议申请 Container。这就好比一间大仓库HDFS建好了YARN 是一套完善的货架调度系统谁要上架、谁要取货都按规矩来而具体用什么工具搬运MapReduce、Spark、Flink那是各家的本事。理解这点很重要——Hadoop 从来不是“一个软件”而是一套生态的底座。3.3 MapReduce 执行引擎一次作业从提交到落盘的完整旅程现在把 MapReduce 的执行过程完整走一遍这是面试高频考点也是理解后面所有计算框架的底子。一个 MapReduce 作业的完整生命周期可以分为五个阶段作业提交客户端把 jar 包、输入路径、输出路径、作业配置提交给 YARN 的 ResourceManagerRM 启动一个 ApplicationMaster 来管理这个作业的生命周期。输入分片InputSplit计算框架把输入目录里的文件按一定规则切成多个分片每个分片对应一个 Map 任务。注意分片逻辑和 HDFS 的块不一定一一对应默认情况下一个块对应一个分片。Map 阶段每个 Map 任务读取自己的分片逐行调用用户写的map()函数产出键值对。这里产出的结果不会直接写磁盘而是先写在内存缓冲区定期溢写spill到本地磁盘。Shuffle 阶段Map 输出的键值对需要按 key 分区、排序、合并发送给对应的 Reduce 任务。这个阶段是 MapReduce 里最复杂、最容易成为性能瓶颈的部分也是“为什么 MapReduce 慢”的关键原因之一——中间结果大量落地磁盘全链路都是磁盘 IO。Reduce 阶段Reduce 任务拉取属于自己的分区数据按键分组调用用户写的reduce()函数把结果写入 HDFS。跑一个最简单的单词统计作业核心代码其实就是两段逻辑public static class TokenizerMapper extends MapperObject, Text, Text, IntWritable { private final static IntWritable one new IntWritable(1); private Text word new Text(); public void map(Object key, Text value, Context context ) throws IOException, InterruptedException { StringTokenizer itr new StringTokenizer(value.toString()); while (itr.hasMoreTokens()) { word.set(itr.nextToken()); context.write(word, one); } } } public static class IntSumReducer extends ReducerText, IntWritable, Text, IntWritable { private IntWritable result new IntWritable(); public void reduce(Text key, IterableIntWritable values, Context context ) throws IOException, InterruptedException { int sum 0; for (IntWritable val : values) { sum val.get(); } result.set(sum); context.write(key, result); } }逻辑本身不难难的是理解 map 输出之后到 reduce 输入之前这段时间发生了什么——partition决定哪个 key 去哪台机器、sort保证每个分区内有序、combiner做局部合并减少网络传输。面试官问 shuffle 的过程其实就是想确认你有没有真正跑过作业、有没有在作业卡住时顺着日志去定位过问题。后面讲到 MapReduce 实操篇时我会专门写一遍 Shuffle 的优化参数这里先有个整体概念。3.4 Hadoop Common最被低估的基础库很多人列 Hadoop 组件时习惯只提 HDFS、YARN、MapReduce把 Common 直接忘了。Common 提供的是最基础的工具类库和抽象接口远程过程调用框架RPC、文件系统抽象FileSystem、序列化机制Writable、配置管理Configuration等。没有 Common上面三个组件就是三座孤岛——正是因为 Common 定义了统一的文件系统接口HDFS 才能和本地文件系统、S3 这些存储无缝衔接正是因为 Common 提供了 RPC 机制NameNode 和 DataNode 之间才能高效通信。严格来说Common 不是用来“学”的但你在排障时一定会碰到它。比如ClassNotFoundException、Configuration加载顺序的问题、FileSystem实例缓存导致的连接异常这些都和 Common 有关。了解它的存在能帮你在报错日志里更快定位问题属于自己的代码还是框架内部的问题。4. 生态圈到底怎么选Hive、Zookeeper、Spark 之间的定位关系4.1 Hive用 SQL 调动 MapReduce 的“翻译官”Hadoop 生态里最常用的第一件“外挂装备”就是 Hive。它的作用一句话就能讲明白把 SQL 翻译成 MapReduce 作业。为什么要做这层翻译因为绝大多数数据分析师和开发者都会 SQL但不是所有人都能写 MapReduce 的 Java 程序。有了 Hive你就可以写SELECT dtype, COUNT(*) FROM weblog GROUP BY dtype;Hive 引擎收到这条 SQL 后会解析成执行计划翻译成一组 MapReduce 任务扔到 YARN 上去跑最终把结果返回。整个过程对用户来说就像在操作一个数据库——但实际上底层是几百台机器在并行计算。Hive 有两个关键机制要懂。一是 Metastore它保存表结构、分区信息、数据文件路径这些元数据通常存在独立的数据库MySQL 或 Derby里。二是分区分桶按日期或类别把数据划成更细的目录查询时只扫需要的分区能省下大量计算资源。实际工作中 Hive 主要是做离线数仓——每天凌晨定时把业务数据导入 Hive 表白天分析师跑 SQL 出报表。面试常问的“内部表和外部表的区别”“动态分区怎么用”“小文件过多怎么解决”都是在考你对 Hive 底层存储机制的理解。4.2 Zookeeper 为什么到处都在分布式协调的“会议主持人”Zookeeper 是 Hadoop 生态里一个容易被低估的角色热搜词里专门有hadoop和zookeeper整合实战说明大家确实搞不清它有什么用。Zookeeper 干的事可以概括为在一个分布式系统里帮大家做决定并且保证这个决定大家都能认同。举个例子Hadoop HA 模式下有两个 NameNode一个是 Active干活一个是 Standby备胎。问题来了客户端和 DataNode 怎么知道现在该连哪个如果两个 NameNode 都以为自己是 Active就会出现脑裂。Zookeeper 就是来解决这个问题的两个 NameNode 都在 Zookeeper 里注册谁抢到了临时节点谁就是 Active服务挂了临时节点消失另一个立刻接管。这个“抢临时节点”的操作本质上是利用 Zookeeper 的一致性保证——所有客户端看到的数据都来自同一个“主”的视角。Zookeeper 的核心模型很简单一个类似文件系统的树状节点结构节点类型分为持久节点、临时节点、顺序节点等。但支撑它实现“一致性”的底层协议 ZAB才是真正难啃的部分。对我等使用方来说不需要手写 ZAB但必须清楚它的能力边界——Zookeeper 擅长的是元数据级别的协调选主、分布式锁、配置发布、服务发现不是大数据量的存储和计算。把 Zookeeper 当数据库用、往里塞大量业务数据是最常见的误用。4.3 Spark 和 Hadoop 不是替代关系实时与离线的配合总有人说“Spark 要取代 Hadoop”这个说法其实很误导。Spark 取代的是 Hadoop 里的MapReduce 计算引擎不是 HDFS也不是 YARN。Spark 的核心优势在于内存计算MapReduce 每个阶段都落盘Spark 尽量把中间结果留在内存里迭代式计算能快几十倍甚至上百倍。所以做机器学习迭代、复杂多阶段数据处理时Spark 是完胜的。但 Spark 极大依赖内存内存不足时性能急剧下降MapReduce 虽然慢但稳定、能处理超大规模数据、对资源要求低。所以现实中两者是共存关系HDFS 照样存数据YARN 照样管资源离线链路用 Spark 或者 MapReduce 都可以流式场景用 Spark Streaming 或 Flink。你在博客上看到“Spark vs Hadoop”的争论十有八九是没把 HDFS/YARN 和 MapReduce 区分开——Hadoop 是底座Spark 是跑在底座上的高性能引擎之一。4.4 数据进出 Hadoop 的搬运工Flume、Sqoop、DistCp生态圈里还有一批“数据搬运工”名字多且容易混我用一张表把它们理清工具解决什么问题典型数据流向一句话类比Flume实时收集日志应用服务器 → HDFS吸尘器把分散在各处的日志吸到一个地方Sqoop关系型数据库与 HDFS 互导MySQL / Oracle ↔ HDFS / Hive摆渡车往返于数据库和大数据平台之间DistCpHDFS 集群间大规模数据复制一个集群 → 另一个集群搬家队批量迁移 HDFS 数据热搜词里有hadoop distcp 参数说明这个我确实要提醒大家注意。DistCp 最常用的参数包括-m并发度、-overwrite覆盖目标端文件、-update只复制源端新增或更新的文件、-delete删除目标端多余文件。实际使用中我常踩的坑是集群间网络带宽有限并发度开太大把带宽打满影响线上业务或者复制大目录时没有加-update任务失败重跑后数据不一致。这些我都会在后面写专门一篇按参数组合给出一套“搬迁实战手册”。5. 别把 Hadoop 当万能药该用和不该用的场景5.1 这些场景确实值得上 Hadoop很多初学者有个误区觉得 Hadoop 是“大数据标配”什么项目都想往上套。其实真正适合的场景往往具备三个特征数据量大至少 TB 级、计算是批量处理、对实时性要求不高。最常见的场景是离线数仓。企业每天产生大量业务数据、日志数据、埋点数据通过 Flume 或 Sqoop 汇入 HDFS再用 Hive/Spark 做定时任务生成报表、用户画像、经营分析。这类任务跑在凌晨跑一小时还是两小时容忍度都很高正是批处理的舒适区。另一个典型场景是海量日志的存储和检索。一台 Web 服务器一天产生几个 GB 日志一百台就是几百 GB单机文件系统根本没法保留太久。用 Flume 汇聚到 HDFS按日期分区存储配合 Hive 按需查询成本低、容量大、可靠性高。最后是机器学习的数据准备训练集往往达到几十 TB用 HDFS 做统一存储层Spark 在上面做特征工程和模型训练这也是非常主流的做法。5.2 这些场景千万别硬上 Hadoop反过来有三类场景是 Hadoop 的“重灾区”硬用只会自找麻烦。第一数据量还没到 TB 级。自己的 MySQL 里就几千万行总共几十 GB非要搭个 Hadoop 集群来“跑大数据”——纯属杀鸡用牛刀。单机 PostgreSQL、ClickHouse 甚至 Excel 都能更快地解决问题。我记得有个真实的程序员段子某人为了“练手”把公司的订单表导进 Hive 里分析结果全流程跑完用了半天同事用 SQL 查只花了三秒。第二实时在线查询。HDFS 是写一次读多次的追加写存储文件一旦写好就不能修改MapReduce 作业从提交到出结果分钟级延迟是常态。你要是拿它做用户在前端页面的即时查询体验会非常糟糕。这类场景应该用 HBase随机读写、Elasticsearch全文检索或者 Redis。第三OLTP 事务场景。Hadoop 生态没有传统数据库那种 ACID 事务支持后来有 Hive 事务表等方案但限制多、代价大。金融交易、订单扣减这种把“数据一致性”当命根子的业务别往 Hadoop 上放。Hadoop 是给人做离线和批处理分析的不是给业务系统做在线服务的。5.3 从高频搜索词看大家的真实需求热搜词其实折射出大家学 Hadoop 时的真实路径和心理。hadoop伪分布式搭建是最常见的一步——在单台机器上让 NameNode、DataNode、ResourceManager、NodeManager 都以独立进程跑起来体验完整的分布式框架又不花多台机器的钱。这是很好的学习起步方式但也埋了一个坑伪分布式下很多故障场景不会出现比如网络分区、机器宕机你学到的是“简化版”的分布式。hadoop的docker镜像则反映了一个趋势越来越多的人用 Docker 替代虚拟机来搭实验环境。这确实方便镜像拉下来就能跑宿主机配置要求低、用完即弃。但我要提醒一句Docker 里跑 Hadoop端口映射和网络模式要配置对尤其是集群多节点互通的时候建议用--network host或自定义 bridge 网络否则容易踩“容器间通信不通”的坑。hadoop ha说明很多人在往生产级架构迈进HA 涉及 Zookeeper、JournalNode、NameNode 的 Active/Standby 切换这套内容后面会专门写。hadoop面试题、hadoop课程设计、hadoop安装与配置也都在意料之中。面试题背后考的全是原理课程设计则往往需要一套能演示完整流程的环境——这恰好是这个系列想覆盖的两个方向。6. 怎么高效入门学习路线和冷启动建议6.1 先建立“最小模型”再逐步扩展韩工的方法论我帮他总结成一句话先建立最小模型再在模型上做加法。所谓最小模型就是你至少得能用一句话说清楚每个组件的职责HDFS把大文件拆成块存在多台机器上靠副本保证不丢YARN管理集群的 CPU 和内存谁要资源都得找它批MapReduce一种“先分散算、再汇总结果”的批处理编程模型Hive把 SQL 翻译成 Hadoop 作业让数据分析师不用写 JavaZookeeper在分布式环境里做选主、协调、配置管理Spark把中间结果放进内存让复杂计算跑得更快能把上面六个句子默写出来你对 Hadoop 生态的认知已经超过了一半的“装过环境但一问三不知”的人。接下来的一切学习都是在这六个句子上不断加细节——比如 HDFS 副本数怎么配、YARN 的内存参数怎么调、Shuffle 为什么慢——底层逻辑不会变变的只是复杂度和深度。6.2 环境准备是第一个关键决策点这一节给还没搭环境的读者一个明确建议。入门阶段优先选择伪分布式安装而不是一开始就折腾多节点集群。原因很简单伪分布式下所有进程都在一台机器上你既能学习完整的组件交互又能减少“网络不通”“节点间证书/SSH 免密失败”这类环境问题对学习的干扰。等你把伪分布式的读写流程、作业提交都摸熟再上三节点的完全分布式或者用 Docker 起三容器会顺畅很多。硬件配置上8GB 内存的电脑跑伪分布式比较舒服4GB 也能跑但要关掉其他应用。安装时优先选和自己系统匹配的 Hadoop 稳定版本现在企业里用 3.x 系列的很多2.x 的也还有存量JDK 版本一定要和 Hadoop 要求的匹配这里不匹配导致的UnsupportedClassVersionError是最常见的安装失败原因。关于配置核心就三个文件core-site.xml默认文件系统、hdfs-site.xml副本数、NameNode 端口等、yarn-site.xml资源调度参数。刚开始别纠结调优默认参数能跑起来就够了。还有一个我强烈建议的学习举动装完之后手动跑几个 HDFS 命令比如hdfs dfs -mkdir /test hdfs dfs -put /etc/hosts /test/ hdfs dfs -cat /test/hosts hdfs dfs -setrep -w 1 /test/hosts这比看十篇教程都有用。setrep -w 1可以把副本数降为 1用来观察副本减少时 DataNode 的行为。自己动手敲一遍你对 HDFS 是“文件系统”的理解就会落到实处。6.3 面试和实战要两条腿走最后聊聊面试。很多人刷 Hadoop 面试题时死记硬背比如“SafeMode 是什么”“block 大小为什么是 128MB”但换个问法就懵。其实面试官考察的是你有没有建立因果链为什么有这个机制、它解决什么问题、触发条件是什么。SafeMode 的本质是 NameNode 启动时从磁盘加载元数据、并等待 DataNode 上报块信息在确认副本数量达到安全阈值前集群拒绝写操作——这个机制是为了避免元数据还没就绪时被写入弄得不一致。你如果理解了这层面试题怎么变都不怕。所以在学这个系列时我建议你给自己定一个标准每学一个概念都要能回答“没有它会怎样”。NameNode 没了会怎样集群元数据丢失整个集群不可用。副本数为 3 会怎样最多容忍两台机器同时坏。YARN 的 RM 挂了会怎样新作业提交不了但已运行的任务会受影响。这种“故障推演式”的学习习惯比刷一百道题都管用。我个人在实际带人和面试中有一个体会能把 Hadoop 原理讲得清楚的人通常不是因为背得多而是真的在一台机器上从头搭过、炸过、修过。所以这个系列的每一篇我都会把“我踩过的坑”和“你可以做的练习”放在末尾。学技术没有捷径但可以少走弯路。下一篇我会写伪分布式的完整搭建过程从 JDK 环境配置开始到启动 HDFS 和 YARN到跑通第一个单词统计程序。如果你正在准备环境可以先按 6.2 节把 JDK 装好等下一篇出来直接跟上。