1.3 Hadoop的部署模式

1.3 Hadoop 的部署模式

本节摘要：Hadoop 支持单机模式、伪分布式、完全分布式三种部署形态。本节对比三种模式在进程拓扑、数据流动路径与故障表现上的差异，给出选择依据，并完整走一遍伪分布式环境的搭建与验证，为后续所有动手环节准备实验台。

三种模式是同一台戏的三种舞台

Hadoop 的代码只有一套，部署模式决定"角色分给几个演员演"。理解三种模式的最佳方式不是背定义，而是看同一条数据流动路径在每种模式下怎么走。

单机模式（Local / Standalone）。没有守护进程——不起 NameNode、不起 ResourceManager，HDFS 根本不存在，本地文件系统直接当输入输出。MapReduce 跑在单个 JVM 里。它适合调试程序逻辑：你在写一个复杂的 Reduce 函数，关心的是代码对不对，不是分布式的调度行为。数据流动路径被压缩成"本地读 → 本地算 → 本地写"，一条直线。

伪分布式（Pseudo-Distributed）。一台机器上把全部角色演完：NameNode、DataNode、ResourceManager、NodeManager 各占一个 JVM 同时运行。HDFS 是真的，数据真的被切块、真的存了三副本（只是三副本都在本机的不同目录语义下），YARN 也是真的，任务真的经过容器分配。它保留了完整的数据流动路径，只是每一段都被压缩到同一台机器上。学习和单元级验证用它最合适，也是本教程后续动手环节的默认环境。

完全分布式（Fully-Distributed）。角色的标准配置：NameNode 独占一台（生产上还有 Standby）、若干 DataNode、ResourceManager 独占一台、若干 NodeManager。数据真正跨网络流动，机架感知、副本放置、本地性调度全部真实生效。只有这种模式才能暴露"网络是稀缺资源"带来的所有问题——Shuffle 慢、机架带宽打满、心跳超时——这些在伪分布式上永远看不到。

图 1-3 三种部署模式对比矩阵

伪分布式搭建实战

下面在一台 Linux 机器（或虚拟机）上完整搭建。前提：已装 JDK 8 或 11，已配置 ssh 免密登录本机（Hadoop 的启动脚本用 ssh 拉起各守护进程，哪怕目标就是本机）。

第一步，解压发行包并设环境变量：

tar -xzf hadoop-3.3.6.tar.gz -C /opt/
# 在 ~/.bashrc 追加：
export HADOOP_HOME=/opt/hadoop-3.3.6
export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin
​

第二步，写核心配置。伪分布式的配置哲学是"把每一对主从都指向 localhost"：

<!-- core-site.xml：文件系统入口指向本机 NameNode -->
<configuration>
  <property>
    <name>fs.defaultFS</name>
    <value>hdfs://localhost:9000</value>
  </property>
  <property>
    <name>hadoop.tmp.dir</name>
    <value>/opt/hadoop-3.3.6/data/tmp</value>
  </property>
</configuration>

<!-- hdfs-site.xml：单机也要存副本，因子降 1 避免警告 -->
<configuration>
  <property>
    <name>dfs.replication</name>
    <value>1</value>
  </property>
</configuration>

<!-- mapred-site.xml：计算框架交给 YARN 而非本地 -->
<configuration>
  <property>
    <name>mapreduce.framework.name</name>
    <value>yarn</value>
  </property>
</configuration>

<!-- yarn-site.xml：资源管理器同样指向本机 -->
<configuration>
  <property>
    <name>yarn.resourcemanager.hostname</name>
    <value>localhost</value>
  </property>
  <property>
    <name>yarn.nodemanager.aux-services</name>
    <value>mapreduce_shuffle</value>
  </property>
</configuration>
​

第三步，格式化并启动：

hdfs namenode -format     # 仅首次执行！重复格式化会改变集群ID导致DataNode注册失败
start-dfs.sh              # 拉起 NameNode 与 DataNode
start-yarn.sh             # 拉起 ResourceManager 与 NodeManager
jps                       # 验证进程
# 期望输出：
# 24801 NameNode
# 24952 DataNode
# 25310 ResourceManager
# 25431 NodeManager
# 25520 Jps
​

第四步，端到端验证——用 1.2 节的五条命令跑一遍：

hdfs dfs -mkdir -p /data/logs
hdfs dfs -put /var/log/syslog /data/logs/
hdfs fsck /data/logs/syslog -files -blocks
# Total blocks: 1  ✓ 说明切块与副本真实发生
yarn node -list
# Total Nodes: 1  ✓ 容器执行层就绪
​

到这一步，旅程七站在你机器上全部通车。

部署模式背后的取舍

三种模式不只是方便程度递增，各有正反两面。单机模式快得飞起，但它验证不了任何分布式行为——在它上面"通过测试"的 Shuffle 优化上线后翻车是常见事故。伪分布式覆盖 90% 的机制学习，但它掩盖了所有时序问题：本机回环网络几乎无延迟，心跳永不抖动，而在生产上，一次机架交换机抖动就能让一批 DataNode 心跳超时触发副本风暴。完全分布式是唯一诚实的舞台，代价是搭建与运维成本——这也是为什么第 6 章会专门讲集群规划。

还有一条实践建议：学习期尽量在伪分布式上做破坏实验。kill 掉 DataNode 再看 fsck 输出、把副本因子调到 2 再观察 HDFS 如何重新平衡——这些实验在生产集群上你永远不敢做，而它们恰恰是建立"容错直觉"的最短路径。

⚠️ 常见坑：重复执行 namenode -format。每次格式化都会生成新的集群 ID，DataNode 还带着旧 ID 的版本文件，导致注册失败、Web 界面显示 Live Nodes 为 0。修复办法是清空 NameNode 与 DataNode 的数据目录后重新格式化。

本节要点回顾

• 三种模式是角色分配方案：单机零守护进程、伪分布式一人分饰多角、全分布式标准配置；
• 数据路径完整度递增：伪分布式已能看到切块、副本、容器，全分布才能看到机架与网络行为；
• 伪分布式配置哲学：所有主从地址指向 localhost，副本因子降为 1；
• 格式化只做一次：重复格式化导致集群 ID 不一致、DataNode 失联；
• 破坏实验在伪分布式上做：kill 进程、观察 fsck，是建立容错直觉的最短路径。

地图有了、角色认了、舞台搭了。下一章进入旅程第一站的深水区：HDFS 存储层。