Hadoop 3.x本地模式从入门到精通：单机跑通MapReduce的完整指南

大概在两年前，我带一个刚入门大数据的朋友搭环境。他照着网上的教程，一路配置core-site.xml、hdfs-site.xml，搞完还要折腾SSH免密登录，折腾到半夜最后栽在datanode起不来。我过去一看，问他：你只是想跑一下WordCount学MapReduce，干嘛不直接用本地模式？他愣了一下，问了我一句：Hadoop还有本地模式？

这个场景之后我遇到过很多次。大部分新手学Hadoop，上来就被各种"分布式集群搭建教程"带偏，以为不用三台服务器就学不了Hadoop。实际上Hadoop 3.x最基础也最容易被忽略的本地模式（Local Mode），才是入门最快、调试最方便、踩坑最少的一条路。这篇文章我就把Hadoop 3.x单机版本地模式从版本选型、环境准备、核心配置到底层原理、常见报错，一次性讲透。

1. 本地模式到底是什么：先搞清楚它和伪分布式、完全分布式的边界

很多教程把单机版和伪分布式混着讲，搞得初学者一上来就要面对一堆守护进程和配置文件。这里先把概念掰开揉碎。

1.1 三种模式本质上区别在哪

Hadoop的运行模式划分标准很简单：看它启动了多少个Java进程，以及数据到底存在哪里。

先看最难理解的本地模式。所谓本地模式，就是Hadoop的所有组件全部跑在一个JVM进程里。MapReduce任务由LocalJobRunner负责调度执行，输入输出全部走本地文件系统，也就是和你的Windows、Linux系统文件一模一样的文件路径。换句话说，本地模式下根本没有所谓的HDFS，文件路径就是/home/user/input这种普通路径。

伪分布式模式则不同。它是在一台机器上，用多个Java进程分别模拟NameNode、DataNode、ResourceManager、NodeManager。数据已经进入HDFS了，只是这些进程恰好都挤在同一台物理机上。

完全分布式不用多说，每个角色分布在不同机器上，这是生产环境的标准形态。三者的对比如下：

1.2 本地模式能干什么、不能干什么

本地模式最核心的价值就是做MapReduce程序的开发与调试。你想验证一个MR逻辑写对了没有，本地模式几秒钟就能跑完一个任务，不用等集群调度，不用关心数据块分布。配合IDE直接打日志、断点调试，效率远超在集群上调。

但本地模式有一个天然局限：它不涉及HDFS和YARN。如果你要学HDFS的文件块机制、NameNode元数据管理、YARN的资源调度，本地模式完全看不到这些东西。这时候就该切换到伪分布式甚至完全分布式。

所以我的建议很直接：如果你是初学者，第一周老老实实把本地模式跑熟，把MapReduce的编程模型弄明白，之后再往伪分布式过渡。别一上来就搞三台虚拟机，那样你连代码都没写过，光看进程和日志就劝退了。

2. 版本选型与JDK门槛：Hadoop 3.x到底该选哪个版本

Hadoop版本选择这个事，看似简单，实际上有很多细节值得推敲。社区里很多人还在用2.x的老教程，装出来的环境在3.x上各种报错，根源就是版本和JDK不匹配。

2.1 从Apache官网下载时怎么挑版本

Hadoop 3.x目前主流的小版本有3.2.x、3.3.x、3.4.x。截止目前，3.3.x是社区里最稳妥的选择，bug修复及时，生态兼容性最好。3.4.x虽然新，但部分周边工具、第三方组件可能还没有及时适配。

下载地址有两个渠道：Apache官方镜像和国内镜像。官方地址是https://dlcdn.apache.org/hadoop/common/，国内建议用清华镜像https://mirrors.tuna.tsinghua.edu.cn/apache/hadoop/common/，速度快很多，而且版本列表清晰。

需要注意，下载的时候选二进制包，不要选源码包。文件名里带src的是源码，需要自己编译。例如hadoop-3.3.6.tar.gz就是可以直接解压使用的二进制发行包，大约600多MB。

2.2 JDK版本是最大的隐藏坑

Hadoop 3.x对JDK的要求和2.x完全不同。2.x时代一般JDK 7/8都能跑，但Hadoop 3.x推荐使用Java 8或Java 11。我实测过，Hadoop 3.3.6搭配Java 8和Java 11都没问题，但如果你装的是Java 17，那很可能会遇到各种诡异的反射异常和SecurityManager报错。

这里有个很实用的判断方法：直接看官网文档里的Compatibility页面。每个小版本对应的JDK支持列表都写得清清楚楚。比如Hadoop 3.3.x官方支持的JDK版本是8和11，Hadoop 3.4.x开始支持JDK 17。

我的建议是：用OpenJDK 8搭配Hadoop 3.3.x，这是最稳的组合。不要追求新JDK，大数据组件向来对新版本有滞后性，没必要在这上面浪费时间。

2.3 升级或共存时不踩坑的安装姿势

如果你机器上已经装了其他Java版本，比如有的Android开发机装了JDK 17，注意不要直接改系统默认的JAVA_HOME，那样会影响到其他软件的运行。更好的做法是：

在解压Hadoop之后，单独编辑hadoop-env.sh文件，在文件里指定Hadoop自己使用的JAVA_HOME。这样Hadoop启动时只认这个路径，不影响系统全局Java环境。

code复制# 在 $HADOOP_HOME/etc/hadoop/hadoop-env.sh 中设置
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export HADOOP_HOME=/opt/hadoop
export HADOOP_OPTS="-Djava.library.path=$HADOOP_HOME/lib/native:$HADOOP_OPTS"

这个习惯非常重要，尤其是你以后要在一台机器上跑多个大数据组件时，不隔离Java环境会把你坑哭。

3. 环境准备与安装步骤：Linux优先，但Windows并非完全无解

虽然很多人日常用的是Windows，但大数据生态的原生环境是Linux。对学习而言，我强烈建议在Linux或macOS上跑本地模式。Windows下虽然也能跑，但会遇到原生库、权限模型等一堆额外问题，后面专门讲。

3.1 Linux下的完整安装链路

我的环境是Ubuntu 20.04，安装步骤如下：

bash复制# 1. 更新系统并安装JDK 8
sudo apt update
sudo apt install -y openjdk-8-jdk

# 2. 验证JDK安装
java -version

# 3. 创建独立用户（强烈建议，不要用root跑Hadoop）
sudo useradd -m -s /bin/bash hadoop
sudo passwd hadoop

# 4. 下载Hadoop 3.3.6
wget https://mirrors.tuna.tsinghua.edu.cn/apache/hadoop/common/hadoop-3.3.6/hadoop-3.3.6.tar.gz

# 5. 解压到指定目录
sudo tar -zxvf hadoop-3.3.6.tar.gz -C /opt/
sudo mv /opt/hadoop-3.3.6 /opt/hadoop
sudo chown -R hadoop:hadoop /opt/hadoop

这里有个细节值得提醒：一定不要在root用户下直接跑Hadoop，尤其是以后切到伪分布式时，HDFS在root下会有一堆权限检查问题。从开始就养成用独立用户的习惯，后面会省很多事。

3.2 环境变量配置：HADOOP_HOME只是开始

很多人以为配好HADOOP_HOME就完事了，其实还需要把bin和sbin目录都加进PATH，否则后面你要敲很长的路径。编辑~/.bashrc：

bash复制# 追加以下内容
export HADOOP_HOME=/opt/hadoop
export HADOOP_INSTALL=$HADOOP_HOME
export PATH=$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$PATH
export HADOOP_MAPRED_HOME=$HADOOP_HOME
export HADOOP_COMMON_HOME=$HADOOP_HOME
export HADOOP_HDFS_HOME=$HADOOP_HOME
export YARN_HOME=$HADOOP_HOME

然后source ~/.bashrc让配置生效。其中sbin目录里存的是start-dfs.sh、start-yarn.sh这类管理脚本，本地模式用不到，但后面切换伪分布式时要用。现在一起配好，免得以后忘了。

3.3 Windows用户怎么办

如果你暂时只能在Windows上学，也不是完全没法跑本地模式。Hadoop 3.x在Windows上做本地模式的核心问题是：它依赖的winutils.exe和hadoop.dll这些Windows原生库不在发行包里，需要额外下载。

网上能找到和版本对应的winutils工具包，把它放到Hadoop解压目录下的bin文件夹中。另外还需要设置一个系统环境变量：

bash复制# 以管理员身份打开CMD，执行
set HADOOP_HOME=C:\hadoop
set PATH=%HADOOP_HOME%\bin;%PATH%

但说实话，Windows上跑本地模式，我有一次光是排查一个Failed to locate the winutils binary报错就花了一个多小时，而同样的环境在Linux下根本不会出现。我的实际建议是：用WSL（Windows Subsystem for Linux）或者虚拟机装个Ubuntu。你以后进公司，接触到的服务器大概率也是Linux，早一点适应没坏处。

4. 本地模式的配置逻辑：为什么可以一个文件都不改

很多人第一次接触Hadoop，习惯性去找配置文件。但本地模式最反直觉的一点就是：开箱即用，不需要修改任何配置文件也能跑起来。理解这一点背后的原理，比记住"要不要改配置"更有价值。

4.1 默认值才是本地模式的真相

Hadoop的核心配置集中在core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml这四个文件里。但如果你打开它们看，会发现里面基本都是空的。

这恰恰是本地模式的设计精髓：当这些配置为空时，Hadoop使用代码里写死的默认值。这些默认值组合起来，正好构成了本地模式。关键默认值如下：

换句话说，读写file:///路径的操作全部落在本地文件系统上，MR任务也交给LocalJobRunner这个类直接在线程里跑。整个过程没有网络通信、没有数据切分，所以快得离谱。

4.2 自己写一个最小配置文件看清生效机制

为了验证这个逻辑，你也可以手动创建一个mapred-site.xml，强制指定本地模式：

xml复制<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
    <property>
        <name>mapreduce.framework.name</name>
        <value>local</value>
    </property>
</configuration>

注意，mapred-site.xml这个文件名在Hadoop 3.x中已经不存在了，默认是mapred-site.xml.template。如果你手动创建，确保文件名是mapred-site.xml。

设置与默认值一致，效果也一致。但手动写一遍的好处是：你真正理解了配置文件的加载机制。以后切到伪分布式时，把这里的local改成yarn，同时把fs.defaultFS改成hdfs://localhost:9000，模式切换就完成了。

4.3 什么情况下本地模式也需要改配置

虽然本地模式"零配置"可跑，但有两个配置我还是建议你改成合适的值：

第一个是临时目录。Hadoop本地模式跑MR任务时会生成大量中间文件，默认放到/tmp下。Linux系统重启后/tmp会被清空，可能导致莫名其妙的任务失败。修改core-site.xml里的hadoop.tmp.dir，指向一个持久化目录：

xml复制<property>
    <name>hadoop.tmp.dir</name>
    <value>/opt/hadoop/tmp</value>
</property>

第二个是内存参数。如果你的机器内存只有4G，跑复杂MR作业时可能会出现堆溢出。在hadoop-env.sh里调整：

bash复制export HADOOP_HEAPSIZE=1024
export HADOOP_CLIENT_OPTS="-Xmx1024m $HADOOP_CLIENT_OPTS"

这两项改完，基本够用了。别去动那些高深莫测的调优参数，本地模式没必要。

5. 安装验证与第一个MapReduce作业：从hadoop version到WordCount

环境配好之后，第一时间验证安装是否正确。不要急着写代码，先把基础链路打通。

5.1 验证安装的三个命令

第一个命令是hadoop version。它能输出Hadoop版本号、JDK版本信息、编译时间等。看到类似如下的输出就说明安装成功：

bash复制$ hadoop version
Hadoop 3.3.6
Source code repository https://github.com/apache/hadoop -r 1be78238778da0fdafb1667b41b56e46607ad9c1
Compiled by ubuntu on 2023-02-17T16:18Z
Compiled with protoc 3.7.1

第二个命令是hadoop classpath。它会输出Hadoop运行所需的完整classpath，这个信息以后在写第三方程序时非常有用。

第三个命令是hdfs version。虽然本地模式不启动HDFS，但hdfs命令本身是存在的。它能验证HDFS客户端组件是否完整。

5.2 跑一个WordCount的全过程

WordCount是MapReduce领域的Hello World。在本地模式跑通它，就证明整个Hadoop客户端链路是通的。

Hadoop发行包自带了示例jar包，路径是share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar。执行以下命令：

bash复制# 1. 创建输入目录和文件
mkdir -p /home/hadoop/wc/input
echo "hello hadoop hello world" > /home/hadoop/wc/input/file1.txt
echo "hello mapreduce hello hadoop" > /home/hadoop/wc/input/file2.txt

# 2. 执行WordCount（注意output目录不能预先存在）
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.6.jar \
    wordcount /home/hadoop/wc/input /home/hadoop/wc/output

# 3. 查看结果
cat /home/hadoop/wc/output/part-r-00000

执行过程中，控制台会滚动输出大量日志。重点看两处：一是Map-Reduce Framework部分的计数器，二是最终输出的File System Counters。如果看到SUCCEEDED，任务就成功了。

输出结果文件part-r-00000的内容应该是类似：

code复制hadoop	3
hello	4
mapreduce	1
world	1

注意，hdfs和dfs命令在这时其实已经能用了。你试试hadoop fs -ls /home/hadoop/wc/input，会发现它直接操作的就是本地文件系统。这就是fs.defaultFS等于file:///的直接体现。

5.3 解读任务日志：LocalJobRunner到底干了什么

跑WordCount时，细心的朋友会注意到日志里频繁出现LocalJobRunner这个类名。这是本地模式的核心执行器。它的工作流程很简洁：

1. 读取mapreduce.framework.name配置，发现是local
2. 直接在本地线程池中启动Map Task
3. 通过LocalJobRunner内部逻辑完成shuffle、sort、reduce
4. 所有中间结果落盘到hadoop.tmp.dir指定的临时目录

所以本地模式下，你会在/opt/hadoop/tmp/mapred/local下看到一堆job_local*开头的临时文件。这些文件揭示了MR任务在Map和Reduce之间传递数据的机制，有探索精神的朋友可以自己翻翻看，比单纯看书理解深刻得多。

6. 单机本地模式的进阶玩法：用IDE断点调试你的MapReduce代码

前面讲的内容已经能让你把官方示例跑通。但很多人学到这就停了，直接跳到伪分布式。实际上本地模式最大的隐藏价值，是用IDE开发、调试自己的MapReduce程序。这是老手搭集群调试时羡慕不来的体验。

6.1 在IDEA中配置Hadoop开发环境

创建一个Maven项目，引入核心依赖：

xml复制<dependencies>
    <dependency>
        <groupId>org.apache.hadoop</groupId>
        <artifactId>hadoop-common</artifactId>
        <version>3.3.6</version>
    </dependency>
    <dependency>
        <groupId>org.apache.hadoop</groupId>
        <artifactId>hadoop-hdfs</artifactId>
        <version>3.3.6</version>
    </dependency>
    <dependency>
        <groupId>org.apache.hadoop</groupId>
        <artifactId>hadoop-mapreduce-client-core</artifactId>
        <version>3.3.6</version>
    </dependency>
    <dependency>
        <groupId>org.apache.hadoop</groupId>
        <artifactId>hadoop-mapreduce-client-jobclient</artifactId>
        <version>3.3.6</version>
    </dependency>
</dependencies>

注意，Maven会自动引入你本地的Hadoop配置吗？不会。本地模式跑IDE程序时，核心是设置mapreduce.framework.name=local。最简单的方式是在代码里硬编码：

java复制public static void main(String[] args) throws Exception {
    Configuration conf = new Configuration();
    conf.set("mapreduce.framework.name", "local");
    conf.set("fs.defaultFS", "file:///");
    
    Job job = Job.getInstance(conf, "MyLocalMR");
    // 设置Mapper、Reducer、输入输出路径等
}

这样你的程序就跑在本地模式的LocalJobRunner里，完全脱离集群环境。

6.2 断点调试的实际体验

本地模式调试代码有多爽？你可以在Mapper的map()方法里直接打断点，IDEA会精确停在每一条记录的调用处。你可以实时看到key和value的变化，看到Context怎么写入结果。这是实打实的单步调试，跟在分布式集群上用远程调试的痛苦完全不是一个量级。

我调试过不少生产环境上的复杂MR逻辑，很多时候最有效率的方式，就是在本地用一小份样例数据直接跑一遍，靠断点一步步观察数据流转。确认逻辑无误之后，再打jar包部署到集群。这个流程是本地模式最被低估的价值。

6.3 本地模式的坑：小数据没问题，大数据不一定

但本地模式有个思维陷阱：它把复杂性全隐藏了，让你误以为MapReduce跑得快。本地模式下没有网络开销，没有数据分布不均，JobTracker和TaskTracker之间的心跳机制也完全不存在。

所以如果你在本地跑通了100MB数据，别天真地以为集群上1TB数据也能直接成功。集群上的数据倾斜、节点宕机、reduce阶段OOM，这些在本地模式下永远不会出现。本地模式验证的是业务逻辑，不验证分布式问题。把这两者分开，你才能正确使用本地模式。

7. 从本地模式切换到伪分布式的正确姿势

本地模式玩熟练之后，下一步通常是伪分布式。这一步很多人走得很痛苦，原因在于一上来就配置各种文件，却不理解配置项和服务之间的关联。这里我从本地模式迁移的角度，把关键点讲清楚。

7.1 需要改动的配置清单

从本地切到伪分布式，核心就是把file:///改成hdfs://localhost:9000。具体涉及两个文件。

第一个是core-site.xml，把默认文件系统指向HDFS：

xml复制<configuration>
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://localhost:9000</value>
    </property>
    <property>
        <name>hadoop.tmp.dir</name>
        <value>/opt/hadoop/tmp</value>
    </property>
</configuration>

第二个是hdfs-site.xml，设置副本数为1（伪分布式只有一台DataNode，搞3个副本纯属浪费空间）：

xml复制<configuration>
    <property>
        <name>dfs.replication</name>
        <value>1</value>
    </property>
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>/opt/hadoop/tmp/dfs/name</value>
    </property>
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>/opt/hadoop/tmp/dfs/data</value>
    </property>
</configuration>

7.2 SSH免密：卡住无数人的第一道坎

伪分布式启动需要NameNode通过SSH连到本机启动DataNode。默认情况下，连接需要输密码，脚本会一直卡在你输入的交互界面，看起来像死机一样。所以要先配置localhost免密登录：

bash复制# 生成密钥对（如果还没有）
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa

# 将公钥加入授权列表
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

# 设置权限（必须严格）
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# 测试免密
ssh localhost

这里有一个权限细节我踩过坑：如果.ssh目录或authorized_keys文件的权限过宽，SSH会直接拒绝读取密钥，导致免密失败。另外，启动Hadoop一定用你配置免密的那个用户，别用root切来切去，否则又要重新配置一遍。

7.3 格式化NameNode的时机与坑

切到伪分布式后，启动前必须先格式化NameNode：

bash复制hdfs namenode -format

格式化的本质是创建NameNode的元数据目录。但它只创建元数据，不会清空DataNode的数据目录。如果你之前启动过伪分布式，再改配置后格式化，新集群的namespace ID会和旧DataNode不一致，导致DataNode无法注册。

解决方法是：格式化之前，先把/opt/hadoop/tmp下的dfs目录整个删掉。等于是让NameNode和DataNode重新从零建立关系。这个坑在初学者中极为常见，报错信息通常是Incompatible clusterIDs。

7.4 启动验证

bash复制start-dfs.sh
start-yarn.sh
jps

jps输出中如果看到NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager这5个进程，就说明伪分布式起来了。接着去http://localhost:9870看NameNode的Web界面。

此时你就会发现：之前本地模式下写好的MR代码，只要把输入输出路径从/home/hadoop/xxx改成hdfs://localhost:9000/user/hadoop/xxx，就能在HDFS上正常跑了。这也表现出本地模式作为过渡阶段的价值——代码逻辑完全通用，变动的只是执行环境。

8. 单机版部署的常见报错与排查思路

最后把我在实际操作中积累的排错经验整理成一份速查手册，每个问题都是真实遇到过的，不是从官方文档抄的。

8.1 JAVA_HOME is not set

这个报错出现在执行hadoop命令时，说明系统没找到Java环境。注意一点：hadoop命令是在用户shell环境下执行的，而hadoop-env.sh里如果没有显式指定JAVA_HOME，它就会依赖shell环境变量。如果你通过sudo执行命令，sudo会重置环境变量，导致明明java -version能正常输出，但Hadoop却报这个错。

解决方式：在hadoop-env.sh里显式写死JAVA_HOME的绝对路径，不要依赖shell继承。这个方法简单粗暴而且一劳永逸。

8.2 频繁弹出NativeCodeLoader警告

这个警告长这样：

code复制WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable

它不影响功能，只是说明Hadoop的native库没找到，导致部分组件回退到Java实现。强迫症患者可以这样处理：

bash复制# 安装native库依赖
sudo apt install -y zlib1g-dev libsnappy-dev
# 然后重新编译或使用官方自带native库

但我给你的建议是：忽略它。本地模式下这个警告对性能影响极小，为了消除它去重新编译Hadoop，投入产出完全不成比例。我在生产环境也常常直接忽略。

8.3 端口占用与9000端口冲突

本地模式不启动HDFS，一般不涉及端口问题。但切伪分布式后，fs.defaultFS配置为hdfs://localhost:9000时，如果9000端口被占用（比如你开了别的Hadoop实例或者某些数据库），NameNode就启动不了。

排查方式：

bash复制# 查看端口占用
lsof -i:9000
netstat -tunlp | grep 9000

如果是残留进程，直接kill掉，或者修改fs.defaultFS的端口号。我建议从开始就用9000，这是Hadoop的默认端口，参考资料最多，别为了标新立异去改它。

8.4 任务跑着跑着报Container exited

本地模式虽然不跑YARN，但如果你在本地模式用job.setJarByClass()时没有把jar包打出来，某些版本下会出现ClassNotFoundException或找不到Mapper类。解决方式：在代码中调用job.setJarByClass(Main.class)指定入口类，或者手动把项目打成jar包再执行。

还有一个很常见的隐藏问题：本地模式的临时目录在/tmp下，跑大量任务时把/tmp磁盘塞满了，导致任务失败。所以前面我推荐的hadoop.tmp.dir配置，在这里就能起作用。

8.5 权限相关的一系列诡异问题

本地模式在Linux下跑MR任务时，如果/home/hadoop/wc/input的属主不是当前用户，Hadoop会报Permission denied。别急着去改文件权限，先确认你用对了用户。这也是为什么我一直强调创建专用hadoop用户，所有Hadoop相关文件都让这个用户统一管理。

总结一下排查顺序：先看用户，再看权限，再看Java版本，最后看磁盘空间。90%的问题都能通过这四步定位。

9. 说在最后：关于本地模式运营环境与学习路径的一点心得

学习大数据，很多人的路径是：从搭集群开始，学着学着被分布式环境折腾得怀疑人生，反倒把大数据编程本身给扔了。我自己也经历过这个阶段。如果让我重新走一遍，我肯定会先用本地模式把MapReduce、HDFS的客户端API吃透，再考虑集群环境。

本地模式看起来"不够高级"，但它恰恰是理解Hadoop内部机制的最佳入口。你能亲眼看到mapper和reducer在同一个进程里的运行轨迹，能在IDE里一步步观察数据流转。这种底层细节的感知，是你直接用集群跑任务得不到的。

最后分享一个我的习惯：就算在正式环境里，我也保留了一套本地模式的环境。新写的MR代码、临时要验证的数据分析逻辑，我都会先用本地模式跑一遍。逻辑确认没问题，再放到集群上跑完整数据。这套工作流帮我避免了很多次因为代码低级错误而浪费集群资源的尴尬。

如果你正在学习Hadoop，先把这篇文章里的内容动手敲一遍。跑通第一个WordCount，用IDE断点调试一次自己的Mapper，再切到伪分布式。你会发现，后面那些看似复杂的集群搭建，理解起来突然变得很顺畅。毕竟，万丈高楼平地起，Hadoop这栋大楼的地基，就是那台不起眼的单机。