企业官网建设流程全解析

很多人学 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 的由来：把“文件”拆成“块”的存储思路

传统文件系统里，一个文件就是一整块数据，存在某台机器的某个目录里。文件太大，单机磁盘放不下；文件太重要，机器一坏就全没。HDFS（Hadoop 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 既要负责计算逻辑，又要负责资源调度，结果是调度能力弱、扩展性差。后来社区把资源管理这块独立出来，就成了 YARN（Yet Another Resource Negotiator）。YARN 的定位很纯粹：它是一个分布式资源调度系统，管的是每台机器上有多少 CPU、多少内存，谁想用、用多少、用多久。

YARN 有两个核心角色。ResourceManager（RM）是全局的“房东”，掌握整个集群的资源总量，负责接收客户端的作业请求，把它拆成若干个需要资源的 Container，然后分配到各个节点。NodeManager（NM）是每台机器上的“二房东”，管理本节点的资源，按 RM 的指令启动和销毁 Container。一个作业跑起来，RM 负责整体调度，NM 负责实际执行，两边通过心跳保持同步。

YARN 的诞生有个重要影响：HDFS 上跑什么计算，不再只有 MapReduce 一个选择了。Spark、Flink 这些计算引擎都可以跑在 YARN 上，只要它们能按 YARN 的协议申请 Container。这就好比一间大仓库（HDFS）建好了，YARN 是一套完善的货架调度系统，谁要上架、谁要取货都按规矩来，而具体用什么工具搬运（MapReduce、Spark、Flink），那是各家的本事。理解这点很重要——Hadoop 从来不是“一个软件”，而是一套生态的底座。

3.3 MapReduce 执行引擎：一次作业从提交到落盘的完整旅程

现在把 MapReduce 的执行过程完整走一遍，这是面试高频考点，也是理解后面所有计算框架的底子。一个 MapReduce 作业的完整生命周期可以分为五个阶段：

1. 作业提交：客户端把 jar 包、输入路径、输出路径、作业配置提交给 YARN 的 ResourceManager，RM 启动一个 ApplicationMaster 来管理这个作业的生命周期。
2. 输入分片（InputSplit）：计算框架把输入目录里的文件按一定规则切成多个分片，每个分片对应一个 Map 任务。注意分片逻辑和 HDFS 的块不一定一一对应，默认情况下一个块对应一个分片。
3. Map 阶段：每个 Map 任务读取自己的分片，逐行调用用户写的map()函数，产出键值对。这里产出的结果不会直接写磁盘，而是先写在内存缓冲区，定期溢写（spill）到本地磁盘。
4. Shuffle 阶段：Map 输出的键值对需要按 key 分区、排序、合并，发送给对应的 Reduce 任务。这个阶段是 MapReduce 里最复杂、最容易成为性能瓶颈的部分，也是“为什么 MapReduce 慢”的关键原因之一——中间结果大量落地磁盘，全链路都是磁盘 IO。
5. Reduce 阶段：Reduce 任务拉取属于自己的分区数据，按键分组，调用用户写的reduce()函数，把结果写入 HDFS。

跑一个最简单的单词统计作业，核心代码其实就是两段逻辑：

public static class TokenizerMapper extends Mapper<Object, 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 Reducer<Text, IntWritable, Text, IntWritable> { private IntWritable result = new IntWritable(); public void reduce(Text key, Iterable<IntWritable> 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

生态圈里还有一批“数据搬运工”，名字多且容易混，我用一张表把它们理清：

热搜词里有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 作业，让数据分析师不用写 Java
• Zookeeper：在分布式环境里做选主、协调、配置管理
• 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 装好，等下一篇出来直接跟上。