Hadoop

![image-20250927181204835](https://oss.maolin101.com/image-20250927181204835.png-101.webp)

Hadoop是Apache基金会开发的一款分布式系统基础架构。Hadoop是在大数据背景下产生的，用于解决海量数据的存储、计算和分析问题。Hadoop可以同时驾驭成千上万台机器为用户提供数据存储和计算服务，其因具有诸多优势而受到大数据工作者的喜爱。

官网地址：https://hadoop.apache.org/

## 历史

Hadoop 的核心思想直接源自 Google 在 2003-20046年发表的三篇里程碑式论文，这三篇论文奠定了分布式存储与计算的理论基础：

- GFS（Google File System）：2003 年发表，提出分布式文件系统的设计理念，解决海量数据的分布式存储问题（对应 Hadoop 的 HDFS）。
- MapReduce：2004 年发表，提出分布式计算模型，将复杂任务拆分为 “Map（映射）” 和 “Reduce（归约）” 两步，实现并行计算（对应 Hadoop 的 MapReduce）。
- BigTable：2006 年发表，提出分布式 NoSQL 数据库模型，支持海量结构化数据的实时读写（对应 Hadoop 生态的 HBase）。

2004 年，Apache 开源项目 Nutch（一个开源搜索引擎）的开发者 Doug Cutting（Hadoop 之父），尝试将 GFS 和 MapReduce 的思想应用到 Nutch 中，以解决搜索引擎的海量数据处理问题。

2006 年，Doug Cutting 将 Nutch 中的分布式存储和计算模块独立出来，命名为 Hadoop（名字源自他儿子的玩具大象），并捐赠给 Apache 基金会，正式成为 Apache 顶级开源项目。

2008 年，Hadoop 迎来关键转折点：Yahoo! 构建了包含 4000 个节点的 Hadoop 集群，用于搜索业务；同年，Apache Hadoop 1.0 版本发布，标志着其技术体系初步成熟。

## 组成

Hadoop目前发行了三个大版本，1.x、2.x和3.x。

Hadoop 1.x时，Hadoop主要由两部分组成，HDFS和MapReduce。HDFS用于数据的存储，MapReduce用于数据的计算和资源调度。

在Hadoop 2.x时，Hadoop对MapReduce进行了拆分，将资源调度的任务拆分出来形成了YARN。

![image-20250927144139827](https://oss.maolin101.com/image-20250927144139827.png-101.webp)

## 生态

Hadoop发展到现在已经形成了庞大的生态圈。甚至在广义上讲，Hadoop已经不单单指Hadoop本体，还包括Hadoop的周边生态产品。

Hadoop生态产品众多，功能多样。比如：Sqoop用于数据传递，Flume用于日志收集，Hive做数据仓库，Zookeeper用于平台配置和管理，kafka做消息队列，Azkaban用于任务调度，Storm用于实时流处理等等。

![image-20250927144201968](https://oss.maolin101.com/image-20250927144201968.png-101.webp)

## 核心组件

Hadoop 2.x 及以上版本的核心架构由三大组件构成，三者各司其职、协同工作，形成 “存储 - 调度 - 计算” 的完整闭环：

| 组件名称  | 核心功能           | 定位                |
| --------- | ------------------ | ------------------- |
| HDFS      | 分布式文件存储     | 数据 “仓库”         |
| YARN      | 资源调度与任务管理 | 资源 “管家”         |
| MapReduce | 分布式批处理计算   | 计算 “引擎”（传统） |

### HDFS

![image-20250927144325099](https://oss.maolin101.com/image-20250927144325099.png-101.webp)

在大数据的背景下，如何存储TB、PB级的海量数据一直是一个有待解决的问题。如此巨量的数据一台机器显然是无能为力的，但如果用多台机器进行存储，数据的维护和管理又会变得非常麻烦，解决上述问题的方法正是能够横跨多个节点进行数据存储和管理的分布式文件系统。

HDFS（Hadoop Distributed File System）是 Hadoop 的分布式存储基石，专为海量数据（大文件，通常 GB/TB 级）的存储设计，其将数据存储到Hadoop集群的众多节点上，并以目录树的形式对外呈现。HDFS参考自Google的GFS进行设计实现，现在是Apache Hadoop Core项目的一部分。

> 架构

HDFS 的架构设计：主从（Master/Slave）模式，HDFS 由两类节点组成，角色分工明确。

NameNode（主节点）：集群的 “大脑”，负责管理整个文件系统的元数据（Metadata），包括：

- 文件的路径、文件名、权限、大小。
- 文件块（Block）与 DataNode 的映射关系（即 “哪个块存在哪个节点上”）。
- 不存储实际数据，仅存储元数据（元数据体积小，通常可在内存中加载，查询速度快）。

注意：Hadoop 1.x 中 NameNode 是单点，存在 “单点故障” 风险；Hadoop 2.x 引入 HA（High Availability，高可用） 机制，通过 “Active NameNode” 和 “Standby NameNode” 双节点部署，避免单点故障。

DataNode（从节点）：集群的 “存储节点”，负责存储实际的文件数据，具体工作包括：

- 将文件分割为固定大小的 “块（Block）” 存储（Hadoop 2.x 默认 128MB / 块，3.x 可配置更大，如 256MB）。
- 为保证可靠性，每个 Block 会被复制多份（默认 3 副本），存储在不同的 DataNode 上（通常跨机架，避免机架故障导致数据丢失）。
- 接收 NameNode 的指令（如创建、删除、复制 Block），并定期向 NameNode 汇报自身存储的 Block 信息（心跳机制）。

Secondary NameNode（辅助节点）：并非 NameNode 的备用节点（备用节点是 Standby NameNode），其核心作用是：

- 定期合并 NameNode 的 “编辑日志（EditLog）” 和 “镜像文件（FSImage）”，生成新的 FSImage。
- 减轻 NameNode 的负担（若 EditLog 过大，NameNode 启动时加载会很慢），但无法直接替代 Active NameNode（故障时需手动恢复，不支持自动切换）。

![image-20250927184643282](https://oss.maolin101.com/image-20250927184643282.png-101.webp)

> HDFS写数据流程

1、客户端向NameNode发送请求，表示想要上传文件。

2、NameNode收到请求后会根据请求信息做一系列验证，比如检查用户是否有上传权限、文件是否已经存在等等。如果判断不能上传，NameNode会给客户端返回异常信息，否则给客户端回应同意上传。

3、客户端向NameNode查询数据块上传到哪个DataNode中。

4、NameNode为数据块选择存储的DataNode后返回，因为数据块默认有三个副本，所以NameNode要选择三个DataNode。

5、客户端明确了目标DataNode后会向其中一个发送建立通道的请求，DataNode1收到请求后会向DataNode2发送请求，DataNode2再向DataNode3发送请求，建立起一个完整的数据传输通道。

6、各DataNode回应请求。

7、正式传输数据，客户端传给DataNode1，DataNode1再传送给DataNode2，DataNode2再传送给DataNode3。

8、每个数据块都需要经历3-7步，当所有数据块传输完成后文件传输完毕。

![image-20250927184833463](https://oss.maolin101.com/image-20250927184833463.png-101.webp)

> HDFS读数据流程

1、客户端请求下载文件。

2、NameNode通过查看元数据，找到文件的数据块在哪些DataNode中，并返回。

3、请求读取数据块1。因为数据块存在多个副本，所以客户端在请求前需要先选择好从哪个DataNode读数据。客户端选择DataNode的规则是就近原则，具体来说就是优先同一个节点（客户端和DataNode在同一个节点），其次同一个机架，再次同一个数据中心，最后不同数据中心。如果多个副本的存储距离相同，则随机选取。

4、返回数据。

5、数据块1读取完成后，客户端使用同样的方式选择数据块2的最佳DataNode，然后读取。

![image-20250927184954580](https://oss.maolin101.com/image-20250927184954580.png-101.webp)

### YARN

![image-20250927185015946](https://oss.maolin101.com/image-20250927185015946.png-101.webp)

YARN 是 Hadoop 2.x 引入的核心资源调度组件，解决了 1.x 中 MapReduce 耦合资源调度的问题，实现了 “资源与计算分离”，支持多种计算框架（MapReduce、Spark、Flink、Tez 等）共享集群资源。

> 架构设计

![image-20250927185053733](https://oss.maolin101.com/image-20250927185053733.png-101.webp)

YARN 同样采用主从模式，由三类角色组成：

Resource Manager（RM，主节点）：全局资源调度器，负责管理整个集群的 CPU、内存等资源，以及接收客户端的任务提交请求。

核心功能：资源分配（按队列、用户分配资源）、任务启动授权、监控 NodeManager。

NodeManager（NM，从节点）：每个节点的资源管理器，负责管理当前节点的硬件资源（CPU 核数、内存大小），并执行具体的任务。

核心功能：向 ResourceManager 汇报节点资源使用情况（心跳）、接收 RM 指令启动 / 停止任务、监控任务的资源使用（如内存溢出时杀死任务）。

ApplicationMaster（AM，应用级角色）：每个任务（如一个 MapReduce 作业、一个 Spark 应用）的 “管家”，由 ResourceManager 为任务分配第一个容器（Container）启动。

核心功能：向 ResourceManager 申请任务所需的资源（Container）、与 NodeManager 通信启动任务、监控任务执行状态（如任务失败时重试）。

Container是一组计算的资源的抽象，比如内存、CPU、磁盘、网络等。YARN创建的Container会被用来执行具体的计算任务。

ApplicationMaster负责管理在集群中运行的应用程序，一个应用程序会有一个AM。AM的职责包括为应用程序申请资源、监控程序运行等。

> YARN工作流程

1、客户端向RM发送应用提交信息，并在RM应答后将应用资源上传到HDFS。

2、RM为应用程序分配一个Container，并通知NM准备好Container并在其中启动AM。RM中会保留AM的注册信息，以便用户能够通过RM查询程序的运行情况。

3、AM启动后会向RM申请程序运行资源。AM采用轮询方式并基于RPC协议申请和获取所需的资源。RM收到请求后基于一定的调度策略为应用任务分配Container。

4、AM通知Container所在的NM启动Task。

5、Task会基于RPC协议向AM汇报自己的进度和状态信息，以便让AM能够掌握任务的运行情况，并在任务运行出错时重启任务。

6、在所有任务完成后，AM会向RM发送消息注销自己。

![image-20250927185429268](https://oss.maolin101.com/image-20250927185429268.png-101.webp)

### MapReduce

![image-20250927185532320](https://oss.maolin101.com/image-20250927185532320.png-101.webp)

MapReduce：分布式批处理计算引擎，MapReduce 是 Hadoop 最早的分布式计算引擎，基于 “分而治之” 的思想，将复杂的计算任务拆分为 “Map 阶段” 和 “Reduce 阶段”，适合处理海量离线数据（批处理）。

MapReduce程序可以运行在廉价的机器之上，因为Hadoop为MapReduce程序提供了很高的容错能力。如果MapReduce程序中某个任务运行出现错误，Hadoop可以为这个任务重新分配节点并运行，这个过程不需要管理员的干预，而是Hadoop自动完成的。

> 核心思想

MapReduce将一个分布式程序分为两个阶段执行，Map阶段和Reduce阶段。

Map阶段用于数据的预处理，Reduce阶段用于数据聚合输出最后的结果。Map和Reduce阶段的输入输出都是以键值对<key,value>的形式存在。

原数据输入Map，经过Map的处理后输出，Map的输出会作为Reduce的输入，最后Reduce再次对数据进行处理，生成最后的结果。

值得注意的是，在一些特殊需求下，一个MapReudce程序可以没有Reduce阶段而只进行Map阶段。

Shuffle 阶段（洗牌，中间过程）：“数据分区、排序、合并”，将所有 Map 任务输出的 Key-Value 按 Key 分区（相同单词的 Key 分到同一分区）。

![image-20250927185944080](https://oss.maolin101.com/image-20250927185944080.png-101.webp)

> 局限性

尽管 MapReduce 是批处理的经典实现，但随着大数据场景的丰富，其缺陷逐渐凸显：

- 实时性差：基于磁盘计算（中间结果写入磁盘），处理延迟高（适合小时 / 天级批处理，不适合秒 / 分钟级实时计算）。
- 计算模型单一：仅支持 Map-Reduce 两步计算，复杂任务需拆分为多个 MapReduce 作业串联，效率低。
- 资源利用率低：任务启动和 Shuffle 阶段（数据传输）消耗大量资源，尤其是小文件场景。

因此，目前 MapReduce 已逐渐被 Spark（基于内存计算，实时性更高）、Flink（流批一体）等计算框架替代，但 MapReduce 的思想仍是分布式计算的基础。

## 生态

Hadoop 核心组件（HDFS、YARN）是 “骨架”，而围绕它构建的生态工具则是 “血肉”，共同覆盖 “数据采集 - 存储 - 计算 - 分析 - 可视化” 的全流程。常见的 Hadoop 生态工具如下：

| 工具名称  | 核心功能                                  | 解决的问题                                                 | 与 Hadoop 核心的关系                                   |
| --------- | ----------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------ |
| Hive      | 基于 SQL 的数据仓库工具                   | 非技术人员（如分析师）无法写 MapReduce，需 SQL 接口        | 存储依赖 HDFS，计算依赖 YARN（可调用 MapReduce/Spark） |
| HBase     | 分布式 NoSQL 数据库（列存储）             | HDFS 不支持随机写入和实时查询，需实时读写海量结构化数据    | 存储依赖 HDFS，协调依赖 ZooKeeper                      |
| Spark     | 基于内存的分布式计算引擎（批处理 + 实时） | MapReduce 实时性差，需更快的计算引擎                       | 资源调度依赖 YARN，存储可依赖 HDFS                     |
| Flink     | 流批一体的分布式计算引擎（实时优先）      | 需处理实时数据流（如实时日志分析）                         | 资源调度依赖 YARN，存储可依赖 HDFS                     |
| ZooKeeper | 分布式协调服务                            | 分布式系统中节点的一致性管理（如 HDFS HA、HBase 主从选举） | 为 Hadoop 生态所有组件提供协调支持                     |
| Flume     | 分布式日志采集工具                        | 需从多台服务器采集日志到 HDFS/HBase                        | 数据最终写入 HDFS/HBase                                |
| Sqoop     | 数据导入导出工具                          | 需在关系型数据库（如 MySQL）与 HDFS 之间同步数据           | 连接关系型数据库和 HDFS                                |
| Impala    | 实时 SQL 查询引擎                         | Hive 查询延迟高，需秒级 SQL 查询                           | 直接读取 HDFS 中的数据（不经过 MapReduce）             |

## 特性

Hadoop 之所以成为大数据生态的基石，源于其独特的特性，完美适配海量数据场景：

高可靠性：

- HDFS 通过 “多副本存储”（默认 3 副本）保证数据不丢失 —— 即使一个 DataNode 故障，其他节点仍有副本。
- YARN 和 MapReduce 通过 “任务重试机制” 保证计算不中断 —— 某个任务失败时，ApplicationMaster 会重新申请资源执行任务。

高扩展性：

- 横向扩展（Scale-Out）：无需更换高端硬件，只需增加普通服务器（DataNode/NodeManager）即可扩展集群的存储和计算能力。
- 理论上支持无限节点扩展（Google、Yahoo! 的 Hadoop 集群已达数万台节点）。

低成本：

- 基于 “commodity hardware（普通硬件）” 构建集群，无需专用高端服务器（如小型机），大幅降低硬件成本。
- 开源免费，无需支付商业软件许可费用（如 Oracle 数据库）。

高容错性：

- 自动检测故障并恢复：NameNode 通过 HA 机制避免单点故障，DataNode 故障时 NameNode 会调度其他副本继续提供服务。
- 任务级容错：某个任务失败时，YARN 会自动重试，无需人工干预。

适合批处理：

- 专为海量离线数据设计，可高效处理 TB/PB 级数据的批处理任务（如每日用户行为分析、月度报表生成）。