HDFS 与 MapReduce 详解：存储架构、高可用与 YARN 运行流程

导语

在大数据技术栈中，Hadoop 是绕不开的基石，而 HDFS（分布式存储）和 MapReduce（分布式计算）则是其核心支柱，YARN 作为资源调度系统负责协调两者的运行。本文将按照「HDFS 1.0 基础架构 → HDFS 2.0 高可用优化 → MapReduce on YARN 运行机制」的逻辑，系统讲解这套分布式计算体系的核心原理，帮助你从架构设计到实际流程建立完整认知。

一、HDFS 1.0 架构：从单节点到多副本存储

HDFS（Hadoop Distributed File System）的核心目标是解决海量数据的存储与访问问题。它通过将大文件切分成固定大小的块（默认 128MB），并将这些块分散存储在多个 DataNode 上，实现了高容错性和高吞吐量。

1.1 核心角色与职责

HDFS 1.0 由四个关键角色构成，它们分工协作保障数据存储的可靠性：

角色	核心职责
Client（客户端）	通过 `DistributedFileSystem` 与 HDFS 交互，实现文件的上传/下载/查看等操作。
ActiveNameNode（主节点）	内存中维护元数据（文件与块的映射关系、块与 DataNode 的对应关系），通过 `edits`（编辑日志）和 `fsimage`（镜像文件）持久化元数据。
SecondaryNameNode（辅助节点）	定时拉取 NameNode 元数据，合并 `edits` 和 `fsimage` 并推回，缓解 NameNode 合并压力。
DataNode（数据节点）	存储实际数据块，定期向 NameNode 汇报心跳和数据块状态。

1.2 数据写入流程（Pipeline 机制）

当客户端上传文件时，数据会通过以下步骤完成写入：

客户端请求：通过 FSDataOutputStream 向 NameNode 申请写入文件，并获取 DataNode 列表。
Pipeline 传输：数据以 64KB 为单位（Packet），按 DataNode 顺序建立传输通道（如 Node1 → Node2 → Node3），每个节点接收后立即返回 ACK 确认。
副本机制：默认 3 副本策略，确保数据在不同 DataNode 上冗余存储，避免单点故障。
元数据更新：NameNode 记录文件与块的映射关系，并通过 edits 日志持久化元数据变更。

1.3 数据读取流程

读取时，客户端通过 NameNode 获取文件的块位置信息，然后直接从对应 DataNode 拉取数据：

元数据查询：NameNode 返回文件块的 DataNode 列表（按距离客户端近优先）。
并行读取：客户端与多个 DataNode 建立连接，并行下载不同块的数据。
本地合并：块数据在客户端合并为完整文件（无需副本校验，因 HDFS 已保证数据完整性）。

1.4 元数据持久化与 SecondaryNameNode 的作用

HDFS 1.0 中，NameNode 的元数据仅存于内存，依赖 edits 和 fsimage 持久化：

fsimage：NameNode 启动时加载的元数据快照（如当前文件结构）。
edits：记录元数据变更（如文件创建、块复制）的日志。

SecondaryNameNode 的关键作用是缓解 NameNode 合并压力：

每小时或 edits 日志达到 64MB 时，从 NameNode 拉取 fsimage 和 edits。
在本地合并为新的 fsimage，并通过 HTTP 推回 NameNode（避免 NameNode 因频繁合并导致性能下降）。

二、HDFS 2.0：解决单点故障的高可用架构

HDFS 1.0 存在 NameNode 单点故障 风险（若 ActiveNameNode 宕机，集群无法写入）。HDFS 2.0 通过 HA（High Availability） 方案彻底解决此问题，核心优化点如下：

2.1 HA 核心机制

2.1.1 双 NameNode 与 ZKFC 主备切换

Active/Standby 双机热备：两个 NameNode 同时运行，一个对外提供服务（Active），一个同步元数据（Standby）。
ZKFC（ZooKeeper Failover Controller）：每个 NameNode 旁部署 ZKFC，通过 ZooKeeper 监控 NameNode 状态：
- 若 ActiveNameNode 宕机，ZKFC 会尝试重启，失败则通过 ZooKeeper 选举新的 ActiveNameNode。
- 避免脑裂问题（双 NameNode 同时写元数据），确保元数据一致性。

2.1.2 QJM（Quorum Journal Manager）元数据同步

JournalNode 集群：3 个或 5 个 JournalNode 组成集群，存储 edits 日志。
同步过程：ActiveNameNode 将 edits 同时写入多数 JournalNode，StandbyNameNode 从 JournalNode 读取并应用到自身，实现元数据实时同步。

2.1.3 联邦机制（HDFS Federation）

多 NameNode 管理不同命名空间：通过独立的 NameNode 管理不同目录树（如 /user 和 /data），避免单个 NameNode 因元数据过大导致 OOM（内存溢出）。
数据块分散存储：不同命名空间的块由不同 NameNode 管理，提升集群整体吞吐量。

三、MapReduce on YARN：分布式计算的资源调度与执行

MapReduce 是 Hadoop 的分布式计算框架，而 YARN 是其底层资源调度平台。YARN 解决了 MapReduce 1.0 中 JobTracker 单点调度的问题，实现了资源与计算分离。

3.1 YARN 核心组件

组件	职责
ResourceManager（RM）	全局资源管理器，管理所有 NodeManager 和应用的资源分配。
NodeManager（NM）	单节点资源管理器，管理本地 Container 生命周期，汇报节点资源状态。
ApplicationMaster（AM）	单个作业的管理者，向 RM 申请资源，协调 MapTask/ReduceTask 执行。
Container	资源抽象（CPU、内存、磁盘），作为 Map/Reduce 任务的运行容器。

3.2 MapReduce 运行流程

以 WordCount 为例，完整流程如下：

客户端提交作业：
- 上传 JAR 包、配置文件到 HDFS，通过 JobClient 向 RM 提交作业。
- RM 为作业分配 ApplicationMaster（AM）。
AM 申请资源：
- AM 向 RM 申请 MapTask 和 ReduceTask 所需的 Container 资源。
- RM 分配 Container 后，AM 与 NM 通信，启动 MapTask/ReduceTask。
MapTask 执行：
- 读取 HDFS 数据块，按 MapperClass 处理（如分词、计数）。
- 输出中间结果（KV 对，如 (word, 1)），写入本地磁盘。
Shuffle 阶段：
- 分区：MapTask 按 ReduceTask 数量分区（默认 hash 分区）。
- 排序与合并：ReduceTask 从所有 MapTask 拉取对应分区数据，按 key 排序并合并（如 (word, [1,1,1])）。
ReduceTask 执行：
- 按 key 分组，执行 ReducerClass（如求和），输出最终结果。
结果输出：
- AM 收集所有 ReduceTask 结果，上传到 HDFS，作业完成。

3.3 Shuffle 核心机制

Shuffle 是 MapReduce 的灵魂，决定了中间数据如何从 Map 传输到 Reduce：

环形缓冲区：MapTask 输出先写入内存缓冲区（默认 100MB），达到 80% 时溢写为磁盘文件（每次溢写生成一个小文件）。
归并排序：多个溢写文件通过归并排序合并为最终结果（如 (word, [1,1,1]) → (word, 3)）。
数据本地化：ReduceTask 优先从本地节点拉取数据，减少网络传输。

四、MapReduce 形象理解：从「作战计划」到「任务执行」

用「战争」比喻 MapReduce 流程，更容易理解核心角色：

战略部署（客户端）：将军（AM）接到任务，向 RM 申请兵力（Container）。
Map 阶段（分散兵力）：
- MapTask（前线士兵）：将全国（大文件）拆分为多个区域（数据块），每个士兵（MapTask）负责一个区域，按规则（如分词）处理数据，生成中间结果（如“子弹”和“弹药”）。
- 分区（战场划分）：按 ReduceTask 数量将“弹药”分类（如按省份分区）。
Reduce 阶段（汇总战利品）：
- ReduceTask（后勤官）：收集所有士兵的“弹药”，按 key 合并（如“子弹”汇总到同一仓库），最终统计结果（如总弹药数）。
- 结果返回：AM 将最终结果（总弹药数）上报给将军，任务完成。